Bugzilla – Bug 1864
playlist scans do not follow symlinks to non-.m3u files in 6.1.1
Last modified: 2011-03-16 04:35:06 UTC
After an upgrade from 6.1b2 to 6.1.1, slimserver no longer seems symlinked playlists. Here is the playlist; lrwxr-xr-x 1 root slimserv 23 Jul 12 23:05 all songs.m3u@ -> /home/dump/playlist.txt And debug of a playlist scan on that directory; 2005-07-23 11:33:28.3649 Scan::addToList: /var/db/slimserver/playlists 2005-07-23 11:33:28.3743 numitems: 0 2005-07-23 11:33:28.3746 index: -1 2005-07-23 11:33:28.3749 Scan::readList gonna read file:///var/db/slimserver/playlists 2005-07-23 11:33:28.3755 Gonna try to open playlist file:///var/db/slimserver/playlists 2005-07-23 11:33:28.3789 *** didn't find file:///var/db/slimserver/playlists in playlist cache *** 2005-07-23 11:33:28.3790 Treating directory like a playlist 2005-07-23 11:33:28.3802 directory entry: file:///var/db/slimserver/playlists/ShoutcastBrowser_Recently_Played 2005-07-23 11:33:28.3833 adding 1 to playlist cache: file:///var/db/slimserver/playlists 2005-07-23 11:33:28.3861 Descending into file:///var/db/slimserver/playlists, contains 1 items 2005-07-23 11:33:28.4521 numitems: 0 2005-07-23 11:33:28.4528 index: 0 2005-07-23 11:33:28.4548 itempath: file:///var/db/slimserver/playlists/ShoutcastBrowser_Recently_Played and file:///var/db/slimserver/playlists made file:///var/db/sli mserver/playlists/ShoutcastBrowser_Recently_Played 2005-07-23 11:33:28.4552 isList(file:///var/db/slimserver/playlists/ShoutcastBrowser_Recently_Played) == dir 2005-07-23 11:33:28.4566 numitems: 0 2005-07-23 11:33:28.4568 index: -1 2005-07-23 11:33:28.4571 Scan::readList gonna read file:///var/db/slimserver/playlists/ShoutcastBrowser_Recently_Played 2005-07-23 11:33:28.4577 Gonna try to open playlist file:///var/db/slimserver/playlists/ShoutcastBrowser_Recently_Played 2005-07-23 11:33:28.4646 *** didn't find file:///var/db/slimserver/playlists/ShoutcastBrowser_Recently_Played in playlist cache *** 2005-07-23 11:33:28.4648 Treating directory like a playlist 2005-07-23 11:33:28.4716 Descending into file:///var/db/slimserver/playlists/ShoutcastBrowser_Recently_Played, contains 0 items 2005-07-23 11:33:28.4736 numitems: 0 2005-07-23 11:33:28.4744 index: 0 2005-07-23 11:33:28.4750 Got to end of dir, ascending... 2005-07-23 11:33:28.4764 numitems: 0 2005-07-23 11:33:28.4770 index: 1 2005-07-23 11:33:28.4778 Got to end of dir, done! 2005-07-23 11:33:28.4784 addToList_done. returning 0 items Now, I copied the file over and named it playlist.m3u; -rw-r--r-- 1 root slimserv 27662 Jul 23 11:38 playlist.m3u And a rescan now sees it; 2005-07-23 11:39:17.1244 itempath: file:///var/db/slimserver/playlists/playlist.m3u and file:///var/db/slimserver/playlists made file:///var/db/slimserver/playlists/pl aylist.m3u 2005-07-23 11:39:17.1291 isList(file:///var/db/slimserver/playlists/playlist.m3u) == m3u 2005-07-23 11:39:17.1309 numitems: 0 2005-07-23 11:39:17.1316 index: -1 2005-07-23 11:39:17.1324 Scan::readList gonna read file:///var/db/slimserver/playlists/playlist.m3u 2005-07-23 11:39:17.1338 Gonna try to open playlist file:///var/db/slimserver/playlists/playlist.m3u 2005-07-23 11:39:17.1416 gonna scan file:///var/db/slimserver/playlists/playlist.m3u, with path file:///var/db/slimserver/playlists/playlist.m3u, for base: file:///var /db/slimserver/playlists 2005-07-23 11:39:17.1419 Scan::readList loading file:///var/db/slimserver/playlists/playlist.m3u with base file:///var/db/slimserver/playlists 2005-07-23 11:39:48.1556 Scan::readList loaded playlist with 741 items 2005-07-23 11:39:48.1660 Descending into file:///var/db/slimserver/playlists/playlist.m3u, contains 741 items 2005-07-23 11:39:48.2075 numitems: 0 2005-07-23 11:39:48.2080 index: 0 etc.. Let me know if more information is needed.
how about linking to m3u instead of txt
That does seem to work. I can use that as a workaround for now. I'll change the bug to read that it won't follow symlinks to files that aren't .m3u.
I tend to think that respecting the content type of the far-end of the link is actually the right thing to do, but I don't know of any official rules to say that's true or not. I suppose Dan will know.
Content type isn't defined by file extension in Unix, why is it followed at all (read the anti-Windows bias there? =p)? Things within the playlist directory should just be assumed to be playlists regardless of file extensions IMO.
cross-platform is a cornerstone of the design. As such, some compromises will always exist.
No, I understand. I guess the point was, a list of files could be .txt for a Windows user as well. Assuming what file extension someone is going to use is unneeded since there is an entirely separate hierarchy for it. Maybe playlists that exist within the music directory root have to be .m3u, but things within the playlist root should be free format extensions IMO. My setup is unique I'm sure, but in terms of one less thing for novice users to mess up, not letting them hang themselves with invalid file formats can be a good thing. I don't know how that logic would co-exist with symlinking as I haven't looked at the code, but it seems logical to me that the symlink itself should be the file name used since it was purposely placed in that given directory with that name. If you guys disagree, that's fine, I'll work around it.
Mike - I'm inclined not to fix this. Bug 1810, is the opposite of what you want, and is the more common case. (I think). As much as I would like to rely on a content-type, either way a m3u file is text of some sort, and magic tests can't tell otherwise, except for the extension.