Bugzilla – Bug 1740
Playlists can no longer be in folders
Last modified: 2011-03-16 04:19:49 UTC
Playlists were navigable by folders in 6.0.2 by creating sub-directories in the playlists folder. In 6.1b1 all playlists show in the same folder irrespective of any sub-directories. Songs that are in these playlist sub-directories also now scan without their title.
Not sure if it is the same bug, but having links in a playlist to tracks in a *parent* folder also no longer works. e.g. playlist containing the line ..\U2\Angel of Haarlem.mp3 would not work.
Mark: The playlist organization is a new "feature" of 6.1 where we flatten all playlists (in files, from itunes, etc...) into a single list. Is this a serious problem for you? The second issue (missing titles) is now fixed with bug 1736. Gary: That sounds like a separate bug. can you refile it?
Having playlists all at the same level isn't a disaster, though we have hundreds of playlists and being able to group them into several levels makes navigation far easier.
Mark, if you have a directory based organization of ~1500 playlists and now you made it flat on one level - it would be a disaster. I spend a lot of time to managed the directory based organization. v 6.0.2 worked great with it (direct via remote control direct from device too). And now v6.1.x mad a flat playlist and I have to spend again a lot of time for organization? Please NOT! Give the user a chance to make the old or the new playlist behavior. Regards, Jens
Additional playlist bug reported in comment #1 now filed as https://bugs-archive.lyrion.org/show_bug.cgi?id=1802
The bmf is now a no frills file system browser. What if you could link/shortcut the playlists dir to your audiodir? BMF might need a little work to allow descending playlists, but it would be an option to reverting the progress on browse playlists. You should then be able to use browse music folder to browse your playlists as a structured tree. All the features of slimserver that allow selection of playlist, would then still be able to list them fully from the flat listing.
The flat playlist display makes browsing for a non-specific playlist VERY difficult. There is no "Browse Playlist by Genre". (Nor do I want one, I handled it with subtrees...) Currently, I use a mirrored disk image for multiple MP3 players (Archos/Rockbox, Squeezebox), with the playlists and music files stored in separate, parallel trees, with other files on the disk. So far, I've been able to use the same usage model across all my MP3 players. With this, I now have two different ways to do the same thing, depending on which player I'm using. (That's not very pleasant to do.) The flat/subtree configuration switch is a good idea. The BMF option is awkward because it forces me to wade through other files that aren't music related to get between music and playlists.
Changing the Target Mileston to give this bug greater visibility.
*** Bug 2042 has been marked as a duplicate of this bug. ***
We need to address this, but it's not going to make it for 6.2.
Let me add another vote for hierarchies of playlists (in folders). I was about to file this exact same enhancement request....
I am certainly in favor of this request fo a return to folder in the palylist.
...the overwhelming majority of my playlists (~1500) are for Internet streams and not my local music. As a result, I just make sure my playlists folder is within my scanned music hierarchy and can get to them from the "Browse Music" function. However, as pointed out, the "Browse Playlists" feature is effectively useless given my playlist volume. As an aside, I wonder if there is any advantage to slim users to generating helpful comments within the playlists that the slimserver software could use for sorting purposes?
I found the following: If the playlist is read only (all of my playlists are read only) or the security is set only to Read (I have a special account to modify any of my playlists), Slimserver WILL create a tmp file. If there no read only attribute set, no tmp file will be created. Regards, Jens
pls. aware, my reported os is Windows XP, not Linux and the used version is SlimServer 6.2.2. Jens
I've got 905 Playlists all grouped and organized by folders, which worked great in previous versions. The flatlist in 6.2.1 is a daily problem since it pretty much makes finding these playlists a huge chore. I just ordered my second SqueezeBox so I'm hoping we'll get playlist folder support back in 6.5.
Recommend raising the priority of this bug for the following reasons: * bug open for 11 months * number of user comments indicate it is a common problem * bug inconveniences users enough to prevent upgrading to next version, inhibiting use of new features and/or finding new bugs Dan, what's the status of this feature?
6.5 is feature complete. I have some ideas for this, but they don't fit into the 6.5 schedule.
I agree with Matt about raising the priority of this bug. I will not be able to upgrade my softwre level until it's fixed.
Okay, two year anniversary for this bug, and no update. Recent changes are going to force me to update, and I cannot do that due to this bug. Start rolling this into the 7.0 plans now, please!
I'm not sure what Dan's ideas for this were, but he's no longer with the company. I'll target this for 7.0 because I agree it ought to be implemented.
so, I'll set the target. However, no promises. The reason it has not been done yet is that it will be a bugger of a thing to implement.
I couldn't ask for anything more!
Dean notes that it seems difficult to determine if you all are interested in just being able to scan for the playlists, or a UI to browse through the directory structure and playlists.
(In reply to comment #24) > Dean notes that it seems difficult to determine if you all are interested in > just being able to scan for the playlists, or a UI to browse through the > directory structure and playlists. I for one want to be able to browse the playlist directory structure and select a playlist from there, as we used to be able to in the old days. (As a longtime slimp3/squeezebox/slimserver user, I'm puzzled about how it became difficult to make this work the way it used to.) I have playlists organized in hierarchical directories, and the actual filenames are often cryptically named or named similarly (or identically) to those in other directories. I used to rely on the directory structure both to know what playlists I'm looking at and to keep related ones together. Now the playlist feature is completely useless to me.
Old versions of slimserver used a "virtual tree" for paths (ick). This left the server prone to duplicates, badly resolved paths, problems with relative paths, made it nearly impossible to consider having multiple music folders, and presented difficulties in handling remote files. Now the tracks and playlists are in the db, keyed by fileurl and drawn out by queries based on the metadata. In order to browse playlists with a folder tree ui, the db would need to construct a field of folder names for the entire tree, or break apart the fileurl to get path information. This then has to be maintained and referenced at each level if browsing. Certainly not something I wish to commit to as this is just a guess at how to even approach an implementation. Given that it's a long standing bug with no patch from anyone, I'd guess that most are feeling the same way.
(In reply to comment #26) > Old versions of slimserver used a "virtual tree" for paths (ick). This left > the server prone to duplicates, badly resolved paths, problems with relative > paths, made it nearly impossible to consider having multiple music folders, and > presented difficulties in handling remote files. Now the tracks and playlists > are in the db, keyed by fileurl and drawn out by queries based on the metadata. OK, I understand why the handling for tracks was changed, but why playlists? > In order to browse playlists with a folder tree ui, the db would need to > construct a field of folder names for the entire tree, or break apart the > fileurl to get path information. Why does it need to look at the database for that at all? Why not just look at the filesystem directly to browse playlists? (I know, I should look at the code for the first time in years....)
Playlists are part of the DB because without that, loading a large playlist could stall slimserver. Validating and checking every track delayed playback and rendering of the web ui would be delayed while each track was checked. Currently, anything playable must go through the db. Playlists are stored on the filesystem only as a backup or for potential use elsewhere. The rest of this really just goes back to an old debate, and I'm not really very interested in rehashing it, not to mention having to look it all up again. We're sorry that the feature is gone. It was, however, relatively short-lived and right now so much more has been gained with the current requirements. Hopefully at some point a way to make this feature work again becomes clear.
<rant> I've passed up slimserver upgrades with all the new, cool features (and continue to do so) because navigating five hundred non-associated playlists sequentially is a non-starter. It's not a </rant> My thoughts: The key feature missing here is the ability to navigate the playlists using a directory tree-like format. Caching the playlists in the DB is not antithetical to this: Users gave up live read and verification of the contents of a playlist when the playlists became part of the DB. A re-scan of the playlist directory is all that's needed to update changes to playlists contents, and users typically do that after adding new music to the database anyway. KDF's got it right: the technical challenge here isn't about syncing and verifying playlists, it's about how to store directory information (and navigate by it) in the database: > In order to browse playlists with a folder tree ui, the db would need to > construct a field of folder names for the entire tree, or break apart the > fileurl to get path information. I think that splitting the directory into folder names is the correct approach. KDF, what do you mean by "maintained"? Short of a playlist rescan, what other events would you see as requiring maintenance, and how would they differ from existing playlist/music modification issues?
by maintained, I mean that each level must have an absolute reference that we can then use for the crumblist (pwd_list_ at the top while browsing. The data for each folder level must be something we can track on the fly to deal with playlist path changes.
I'm a little naive with SQL, so bear with me as I explore the solution space: If we were to attach the pwd_list as items in the playlist DB entry, then we can sort the playlists based on each level of directory, pruning those that both do not match the current navigation directory (and do other good things like alphabetical sort). For the search, we need to track a virtual pwd_list for navigation. If a user were to alter or change the directory contents on disk, those changes can be ignored until the next rescan, since the playlist contents are cached in the DB. It's very similar to what happens when a user deletes or move a music track in the current implementation. Adding the pwd_list as items shouldn't be storage-expensive, but is the search described above computationally expensive?
Sorry for not responding. the idea seems reasonable, but it still needs someone willing to put in the time to implement and test. I'm already well into full time hours on SC (and that's all free time outside of an existing day job). I've been responding here in order to help explain and answer questions, but I have no motivation to add this to my personal todo list. Frankly, it's a huge headache and of no personal interest to me (I don't even have a playlist folder set up except when it's needed for testing). If you want to look at the code, Start with Slim/Web/Pages/BrowseDB.pm for web UI, Slim/Buttons/BrowseDB.pm for player UI, and Schema/Playlist.pm, Schema/PlaylistTrack.pm, Schema/ResultSet/Playlist.pm, Schema/PlaylistTrack.pm for the data handling. I know basically nothing when it comes to manipulating the DBI directly, so that's about as much as I can offer. If you'd like to take it on, please open up a discussion on the developer forum and see if you can get some others on board who may be able to get you further.
As a workaround, put your playlist folder inside your music folder (mine always has been there). Then you can navigate through playlist folders by browsing the music folder, though under 'playlists' they're all in a flat list.
voted for this. please schedule the return of former functionality.
To add incentive for providing this functionality: iTunes allows playlists in folders. Users familiar with iTunes who are new to slim/squeeze may expect similar behavior.