XBMC

[Anonymous]

Not that I want XBMC support to go back down in priority, I think you might have me confused with someone else. I haven’t posted on here for a while because my copy of FireFly has been humming along without problems. 😀

Andy

[rpedde]

@ajayre wrote:

Not that I want XBMC support to go back down in priority, I think you might have me confused with someone else. I haven’t posted on here for a while because my copy of FireFly has been humming along without problems. 😀

Andy

ha! you are right — I was thinking of andyg. Oh well.. I already have my xbox booted up. 🙂

[barnseyboy]

happy to help if theres anything i can do on the testing side – i have debianslug nslu2/latest xbmc etc

regards

[eddieb]

@morglum wrote:

I was wondering about something. There’s only 2 of us having issues with XBMC. IS it because there’s only 2 of us trying, or is it working for everyone else?

No ! I am also still having the same problems .. Even in XBMC2 .. I can see mt-daap, I can see all the playlists I created (and the work in iTunes). BUT, all is empty, no songs to see, nothing to listen too.
I am running svn-1372 on both YDL4 and OSX server 10.4.8 (both PPC)

[barnseyboy]

rpedde: i have been diggin through the xbmc code to see if i could spot why mt-daapd playlists have stopped working.

the body of the xbmc mt-daapd code is located in XBMCdocslibXDAAPlibXDAAP.c

the method Priv_DAAP_ClientHost_GetDatabaseItems is the routine for getting the details of individual items. in the code are a few ‘telling’ comments about support for mt-daapd including which xml nodes tend not to be populated by mt-daapd.

i went through all the items returned by mt-daapd and found that sometimes it doesnt return xml nodes for things which i guess are empty id3 tags.

e.g. one of the more empty items i could find in my music library..

- 

112

1077

mp3

04-re-akshon_(remix).mp3

44100

3237049

225044

so my hypothesis (without being able to step through the xbmc code atm) is that its borking on some of the missing tags.

can you remember if the old (working) code for mt-daapd with xbmc saent back empty tags? is adding in empty tags for some of the key elements something you would consider? do you consider this a bug with xmbc not mt-daapd?

ive included the fragment from the xbmc code here, as you see the comments seem to indicate that certain values it expects mt-daapd not to provide have been commented out, but other items which mt-daapd does not always provide are left in.

for (i = 0; i < items.returnedcount; i++)

{

dmapGenericContainer *item = &(items.listitems);

DMAP_INT32 buf32;

/*DMAP_INT16 buf16;

DMAP_INT8 buf8;*/

DMAP_STRING buf;



if (dmapGeneric_LookupContainerItem_INT32(item, dmap_l("itemid"), &buf32) !=

DMAP_DATATYPE_INT32)

continue;



if (dmapGeneric_LookupContainerItem_STRING(item, dmap_l("itemname"), &buf) !=

DMAP_DATATYPE_STRING)

continue;

sizereq += strlen(buf) + 1;



if (dmapGeneric_LookupContainerItem_STRING(item, daap_l("songalbum"), &buf) ==

DMAP_DATATYPE_STRING)

sizereq += strlen(buf) + 1;



if (dmapGeneric_LookupContainerItem_STRING(item, daap_l("songartist"), &buf) ==

DMAP_DATATYPE_STRING)

sizereq += strlen(buf) + 1;



/*

* OPTIONAL - had to comment this out because mt-daapd doesn't provide all of these

* all of the time.

*

if (dmapGeneric_LookupContainerItem_INT16(item, daap_l("songbeatsperminute"), &buf16) !=

DMAP_DATATYPE_INT16)

continue;



if (dmapGeneric_LookupContainerItem_INT16(item, daap_l("songbitrate"), &buf16) !=

DMAP_DATATYPE_INT16)

continue;



if (dmapGeneric_LookupContainerItem_INT16(item, daap_l("songdisccount"), &buf16) !=

DMAP_DATATYPE_INT16)

continue;



if (dmapGeneric_LookupContainerItem_INT16(item, daap_l("songdiscnumber"), &buf16) !=

DMAP_DATATYPE_INT16)

continue;

*/



if (dmapGeneric_LookupContainerItem_STRING(item, daap_l("songgenre"), &buf) ==

DMAP_DATATYPE_STRING)

sizereq += strlen(buf) + 1;



if (dmapGeneric_LookupContainerItem_INT32(item, daap_l("songsamplerate"), &buf32) !=

DMAP_DATATYPE_INT32)

continue;



if (dmapGeneric_LookupContainerItem_INT32(item, daap_l("songsize"), &buf32) !=

DMAP_DATATYPE_INT32)

continue;



if (dmapGeneric_LookupContainerItem_INT32(item, daap_l("songtime"), &buf32) !=

DMAP_DATATYPE_INT32)

continue;



/* optional, see above re mt-daapd

if (dmapGeneric_LookupContainerItem_INT16(item, daap_l("songtrackcount"), &buf16) !=

DMAP_DATATYPE_INT16)

continue;



if (dmapGeneric_LookupContainerItem_INT16(item, daap_l("songtracknumber"), &buf16) !=

DMAP_DATATYPE_INT16)

continue;



if (dmapGeneric_LookupContainerItem_INT8(item, daap_l("songuserrating"), &buf8) !=

DMAP_DATATYPE_INT8)

continue;



if (dmapGeneric_LookupContainerItem_INT16(item, daap_l("songyear"), &buf16) !=

DMAP_DATATYPE_INT16)

continue;

*/



if (dmapGeneric_LookupContainerItem_STRING(item, daap_l("songformat"), &buf) !=

DMAP_DATATYPE_STRING)

continue;

sizereq += strlen(buf) + 1;

}

[rpedde]

@barnseyboy wrote:

can you remember if the old (working) code for mt-daapd with xbmc saent back empty tags? is adding in empty tags for some of the key elements something you would consider? do you consider this a bug with xmbc not mt-daapd?

Nope, I never did, I don’t think. I wouldn’t say it’s a bug either way… the spec is totally unknown, and iTunes accepts either. I don’t have a problem returning empty fields, but that doesn’t seem to be the secret. I dummied up the code to always return all fields, but that didn’t seem to fix it.

So it seems to be something else.

Let me dig up my patch to fully populate all fields, and I’ll let you try it.

— Ron

[barnseyboy]

great thanks.

my other idea at debugging this was to get the old version of mt-daapd (without sqlite etc) that worked for me with xbmc and compare the data returned.

although i seem to remember that i couldnt manually get at the xml using the old version from apt (on debianslug) as xml support was only in the nightlies.

if there are any other ideas you’ve got on debugging this, i’d be happy to put some time into it.

bb

[rpedde]

@barnseyboy wrote:

great thanks.

my other idea at debugging this was to get the old version of mt-daapd (without sqlite etc) that worked for me with xbmc and compare the data returned.

although i seem to remember that i couldnt manually get at the xml using the old version from apt (on debianslug) as xml support was only in the nightlies.

if there are any other ideas you’ve got on debugging this, i’d be happy to put some time into it.

bb

If you could get a capture of xbmc versus iTunes with one song that works, and then a mt-daapd with one song that *doesn’t*, that would be a good starting place.

— Ron

[barnseyboy]

ok i’ll work on doing that. i presume that captured traffic will be in binary daapd format and will be difficult for me to scrutinise and compare differences without having some daapd tool/app to inspect the data.

[rpedde]

@barnseyboy wrote:

ok i’ll work on doing that. i presume that captured traffic will be in binary daapd format and will be difficult for me to scrutinise and compare differences without having some daapd tool/app to inspect the data.

I have a tool that I use to do that… It’s in svn in the /tools directory, called decodeflow.c.

It’s not a very nice tool, but it works something like this:

get a dump of traffic you want to see. use tcpflow to slice it into flows:

tcpflow -r raw.cap

This will drop a bunch of tcp streams. The one you will be interested in is the one from 3689 (or whatever port you are using).

Run the decodeflow utility on the flow, and it should dump out a bunch of files, the ones you’ll be interested in are “decoded.0 – decoded.x”. They are the iTunes responses, parsed and output in a easy (for me) to read tree format.

The file has a hard-coded dep on /sw/bin/zcat (iTunes uses gzip content encoding). You can change that on line 478 to your path to zcat.

— Ron

[Author]

Posts