You are here: Home » Topic » sub folders ?

sub folders ?

This topic contains 20 replies, has 4 voices, and was last updated by  velociped 13 years, 11 months ago.

Viewing 15 posts - 1 through 15 (of 21 total)
  • Author
    Posts
  • #106

    eddieb
    Participant

    In iTunes it is possible to make subfolders in the playlists …
    It would be nice if I could do so in mt-daapd.playlist …

    #3675

    CCRDude
    Participant

    I think that there already have been topics about this 🙂

    And I think if this will be implemented, it won’t be in mt-daapd.playlist, which is an old format of the stables, but in the sqlite database used by newer versions.

    #3676

    rpedde
    Participant

    I’m not even sure if iTunes does this. Anyone have enough machines to test it?

    #3677

    CCRDude
    Participant

    I don’t think this is about grouping servers/machines in groups (for testing that, we would have enough machines, but I doubt iTunes would support it as you said), but about grouping playlists in groups.

    This is something iTunes allows since 5.x I think. Folders can even be recursive, and shown over the network. Oh, and each folder shows the contents of all contained playlists.

    There has been another topic here, but your question remained unanswered:
    http://mt-daapd.org/index.php?option=com_simpleboard&Itemid=40&func=view&id=1894&catid=7

    Regarding that question: yes, folders are not only shown locally, but over the network, and are recursive (otherwise I would have suggested simply adding a folder VARCHAR(64) or similar to the playlists table 😉 , but that way, we would need either a separate table for the folder structure, or a full path in the playlists table. Not sure which one would work easier in your code).

    #3678

    eddieb
    Participant

    If I share my iTunes library with subfolders, that subfolders are shown over the network. So, indeed it would be nice if mt-daapd would support something like that.

    #3679

    velociped
    Participant

    Now, I am confused…

    Are you asking whether mt-daapd supports the nested playlists introduced in iTunes 5.x or whether it is able to parse multiple subfolders within the library directory tree?

    –Herman

    #3680

    eddieb
    Participant

    velociped wrote:

    Now, I am confused…

    Are you asking whether mt-daapd supports the nested playlists introduced in iTunes 5.x or whether it is able to parse multiple subfolders within the library directory tree?

    –Herman

    I would like to see the 1st…

    Parsing multiple subfolders allready works …

    #3681

    rpedde
    Participant

    k. If iTunes can do it, mt-daapd can do it.

    How to configure that, though? Any ideas?

    #3682

    eddieb
    Participant

    as iTunes does it in creating a “folder” in the playlist, doing something like that in the mt-daapd.playlist should do.

    like

    MySubFolder {

    MyArtist1 {
    path contains …
    }

    MyArtist2 {
    path contains ….
    }

    }

    Post edited by: eddieb, at: 2005/10/28 07:01

    #3683

    CCRDude
    Participant

    But the playlist file is outdated 😉
    It’s now in a sqlite database…

    I could think of two ways:

    1. A new field “folder VARCHAR(255)” in the “playlists” table, with values like:
    “My Folder”
    “My FolderMy Subfolder”

    or

    2. A new table “folders” with “id UNSIGNED INT(10)”, “folder VARCHAR(255)”, “parentid UNSIGNED INT(10)”, and a field “folderid UNSIGNED INT(10)” inside the “playlists table”.

    Which way to go would depend on the way iTunes does receive this information from the server. Since I don’t know this, I’ve started writing a mini-daap-client (only browsing) for myself, but I didn’t get the validation to work with the original iTunes yet (no problem with mt-daapd 😉 ), and I can’t run Ethereal since I have no x64 WinPCap yet, so from the little things I’ve seen in the documentation only, I can guess it’s hidden somewhere in /databases/[num]/containers. Someone doing some packet sniffing on iTunes 5.x+ connecting should be able to get the necessary information…

    #3684

    velociped
    Participant

    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

    #3685

    eddieb
    Participant

    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

    #3686

    eddieb
    Participant

    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

    #3687

    CCRDude
    Participant

    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 😉

    #3688

    eddieb
    Participant

    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.

Viewing 15 posts - 1 through 15 (of 21 total)

The forum ‘Feature Requests’ is closed to new topics and replies.