- This topic has 20 replies, 4 voices, and was last updated 18 years, 11 months ago by
.
-
Posts
-
I have not had the opportunity to do much research on this topic, yet, but it is something for which I have an interest.
Patrick seems to be on the correct track. Looking at the iTunes Music Library.xml file, nested playlists have only one additional parameter; that being a “Parent Persistent ID” variable of type string. The latter, of course, containing the “Playlist Persistent ID” of the enclosing playlist.
An enclosing playlist appears to simply be a standard playlist with the addition of a “Folder” boolean. One would assume that iTunes simply parses the data provided by the DAAP share and if it sees the “Folder” boolean displays it at such in the library/playlist pane.
Solution one seems more in keeping with the paradigm implemented by Apple. Adding new fields for folder (as boolean), and parentID (as string) to the playlist table should cover the additional parameters needed by the client to properly feed these settings to the client. It seems unnecessary to create a whole new table just to accommodate these simple descriptors.
–Herman
CCRDude wrote:
But the playlist file is outdated 😉
It’s now in a sqlite database…But …
Since there is no release of the nighties yet …
And the sqlite part is not really documented …Both my servers still run 0.23
starting the nighties build for the 1st time crashes on permissions of /var/cache/mt-daap … It would be nice if the error message on that would be more descriptive
CCRDude wrote:
But the playlist file is outdated 😉
It’s now in a sqlite database…But …
Since there is no release of the nighties yet …
And the sqlite part is not really documented …Both my servers still run 0.23
starting the nighties build for the 1st time crashes on permissions of /var/cache/mt-daap … It would be nice if the error message on that would be more descriptive
The XML… I never even though about that 😉
Good idea… from the XML, there’s one folder-key and children have a persistent ID of the parent listed. So on protocol level, there’s imho just two more fields, one flagging it as a folder, and one on the children naming the parents persistent ID.But from what I could see with the help of my protocol debugger, mt-daapd does not yet support persistent IDs. You would need a dmap.persistentid (mper) with each container, and that should really be persistent. So I guess on /server-info, you should also a dmap.supportspersistentids and set it to true (btw why are dmap.supportsindex and dmap.supportsbrowse set to false?).
But maybe if dmap.supportspersistentids is false, it will work with normal IDs (seems you go well without persistent IDs so far)… well, from a /content-codes dump I found dmap.parentcontainerid (mpco) which probably is the field on the children to transmit. And the field to transmit whether it’a folder or not could be dmap.haschildcontainers (f??ch)… not sure why my dump has a special char on second position there, I don’t even see this field in my iTunes 6.0.1 dump, but it’s the only one I could thing of… so we need to find it!
Well now that there’s enough confusion on the protocol side, back to the mt-daapd db/user side. The playlists database probably needs a flag “isfolder” and an integer field pointing to the parent playlist or root (same as what velociped said, just that an integer pointing to the parent ID is more safe than a string pointing to its name which could change). On the user interface, this would be two things, one checkbox, and pulldown showing the folder structure (to allow the user to select the root). And, since I’ve seen in the XML that the items are stored along with the folder as well, if you want it very comfortable you could add another boolean allowing the admin to set up whether a folder should show the contents of all contained playlists (in that case just OR bracketed sql statements I guess) or not. Maybe contrary to the original, folders could also have their own playlists, but that’s something that can only be tried.
@eddieb: but writing the same code for both the old stable and the nightles would 1. make the stable unstable/nightly, and cost double the time with half of it discarded soo after 😉of course it is not a good thing to change code in 2 different tress, except for bug fixing maybe …
In the mean time I am running the latest nightie on my PPC linux machine …
I noticed the “lost iTunes XML” file in the mp3 tree caused playlists in mt-daap …But …
Man, this is SLOOOOOW …
opening the share in iTunes on a different machine took very long !!!
Much longer than in the 0.23 version anyway …No idea why
E.
Making it nest really isn’t too much problem, it’s how to represent it configuration-wise.
And yeah, that won’t ever come to 0.2.3, just to nightlies.
As far as speed, I think it’s related to playlists… I’m going to change the playlist stuff and see if I can’t speed it back up. It used to be pretty much on part with 0.2.3 on slow machines, and much faster than 0.2.3 on fast machines.
It’s a work in progress.
— Ron
There isn’t a playlist file anymore, the playlists are driven by sql queries, or from the database.
As far as progress, it’s still to do, but I’ve got the database backend well and truly broken, and I don’t want to commit anything to cvs until it compiles again.
But I’ve been working on making Christmas gifts and whatnot, so the last couple weeks have been slow.
Just to add my belated $0.02…
At present, the publication of nested playlists is not supported by DAAP…and by extension iTunes. So, unless and until Apple adds this capability to DAAP, it will need to be something which is added to mt-daapd as a feature entension. Thus, I would imagine such would move it further down the list of implementation priorities…if it is even possible.
–Herman
Publication of nested playlists are not supported by DAAP or iTunes?
Why do you think that?
Imho I’ve seen this a few times around our network here, and I’ve already described that the DAAP protocol supports it, see my topic about dmap.parentcontainerid (mpco) and dmap.haschildcontainers (f??ch).
I guess I need to finish writing my debugging iTunes client… does anyone have the modified MD5 algorithm as Pascal source? That’s the only thing I’m still missing and I’m too lazy to translate it from C (somehow just changing that one bit didn’t do it, there’s something about bigger and lower endian as well)… oh and I’m not sure which part(s) of the request exactly do need to be hashed that way, if someone should know…
first pass at the db is done…. it compiles now, anyway. Seems to sort-of work, although there are still some problems with it. Next couple days I’ll probably have sqlite3 added, and at least have taken a look at mysql.
So I’m closer to taking a look at this.
For debugging, I use ethereal + tcpflow + a home-grown dmap-dumper. I have the source if you want it. I may just add the tools I use into cvs just so they are there for anyone else that wants to look at them. I find the flowdecoder to be particularly useful for being able to observe daap conversations.
- The forum ‘Feature Requests’ is closed to new topics and replies.