Bugzilla – Bug 2496
Slimserver no longer plays .m3u playlist files outside playlist folder
Last modified: 2011-11-06 23:23:28 UTC
On 6.0.2 I can do "playlist play /path/to/somefile.m3u", either from within the web interface or by talking to the CLI directly, and the songs in that playlist file will then be played. On 6.2.0 (and 6.5b1) this simply does not work anymore. In the web interface I can browse through the folders to exactly the same playlist files that work on 6.0.2, but I cannot even add them to the current squeezebox playlist, let alone play them. Ditto for the direct CLI interface: exactly the same command that works in 6.0.2 no longer does in 6.2 and higher. On the Slimserver forums I found a few other people who seem to be having exactly the same problem -- I was not able to find a solution, hence this bug report.
playlist in the playlist folder play fine via browse playlists. the playlist play command has problems (also mentioned in another bug, but I can't find it right now so I wont mark it as a dupe)
This seems to be as a result of bug 1701, and 2408: # Bug 2048 - Don't add playlist files from the audiodir, # unless they are cue sheets. without adding it to the scan, the playlist (when not in the playlist folder) is not parsed and will not play.
I have looked at those other bug reports, and from them I think I understand the reasons for leaving out playlist files when doing a scan of a directory during building the global SlimServer database, or when doing from within the UIs an "add all" on a directory *containing* an .m3u file. However, is it that wrong of me to expect that when I *explicitly* click on, or in any way try to play a single *specific* .m3u file, no matter where it is located, that it ought to work, just as it did in 6.0.2, as long as the paths mentioned in it are correct? I don't want to come across as one of those people who thinks that just because they have a certain need the whole product should conform to it, but surely the two behaviours could co-exist and many other folks would be made happy as well? I am absolutely not interested in SlimServer's database or how it adds various types of files to it. But just as I am still able to play an arbitrarily located music file by saying "playlist play /absolute/path/to/file.mp3", I'd really, *really* would like to be able to continue to do the same thing for .m3u files...
This is not a debate. I was placing information here for reference. This is a developer tool and I am sharing developer info. if you wish to debate, please take it to the forum.
Leo has a point, if you can see it when browsing you should be able to play it. Bug 1701 is about not adding playlists when recursively playing directories when browsing music folder. That's right. And bug 2048 is about not recursing into playlist files when scanning the music folder. That's right too. But it's not unreasonable to allow people to browse and play a playlist in the music folder, just don't enter them recursively during scan or play from a higher level. Until we fix it, the recommended place for playlists is in the playlist folder.
This may be a similar bug. I am running MacOS 10.3.9 and SS 6.2.2 I also notice that the playlist does not show up when expected. The left part of the screen is normal in appearance and function. If I close slimserver then reopen it from the preference pane it loads normally. I also notice that the web site connection is slow and also requires me to reload it .
Leo - in 6.5, you can specify an explit playlist in the CLI. I'll take a look at the player / web UI versions.
Pushing this off past 6.5, when we can have a look at a UI for this.
Dean notes that you can see the playlists in the music folder but can't play them, so we need to make it work or hide them.
Created attachment 2309 [details] A Python script that can be used as a workaround for this bug.
Well, since it's now been almost two years since I reported this bug, and it has just been 'unassigned' again, I am kinda guessing that we're not going to see a solution very soon... So just in case anybody else is reading this who would like a workaround, I am attaching to this comment a Python script that I wrote last year, which basically copies and converts all my 'in-tree' playlists to a location where the Slimserver *can* find them (and of course the relative paths in the playlists need to be changed to absolute ones, but the script does that as well). The script is called 'squeezify.py', and I schedule it (via Unix crontab) to be run every morning at half past six: 35 6 * * * $HOME/bin/squeezify.py In order to adapt the script for your situation, you have to set the two parameters 'sourcedir' and 'targetdir' at the bottom of the script.
We're just changing the way we're organizing bugs. Nothing has really changed with the status of this bug. There's another bug as well about being able to navigate through a directories of playlists. It's a problem that's still on our mind.
Unassigned bugs cannot have a priority.