Bugzilla – Bug 1360
cue sheets show up funny when browsing music folder
Last modified: 2009-09-08 09:22:28 UTC
trunk r2948 when you browse music folder to a cue sheet+file, instead of showing the titles for the songs it shows you the filename of the album repeatedly.
Created attachment 416 [details] sample cue sheet submitted by a customer
what do you have set for Server Setting -> Behaviour -> Sort By File Name ?
what the hell? it was set to sort by filename, not tag. i *never* changed this option, it's defaulting to it now. that's really dumb.
in trunk r2957 it defaults to sorting by filename... but when using cue...ugh, this is wacky. it also doesn't list them properly (they're listed in proper order in the cue sheet, but listed way out of order when browsing music folder after setting it to sort by song information)
i can't even figure out what order it's sorting it in: All Subfolders Play Add to playlist 11. The Long Way Home from Feels like home by Norah Jones Play Add to playlist 10. Above Ground from Feels like home by Norah Jones Play Add to playlist 6. Be Here to Love Me from Feels like home by Norah Jones Play Add to playlist 3. Those Sweet Words from Feels like home by Norah Jones Play Add to playlist 8. Toes from Feels like home by Norah Jones Play Add to playlist 1. Sunrise from Feels like home by Norah Jones Play Add to playlist 12. The Prettiest Thing from Feels like home by Norah Jones Play Add to playlist 9. Humble Me from Feels like home by Norah Jones Play Add to playlist 5. In the Morning from Feels like home by Norah Jones Play Add to playlist 4. Carnival Town from Feels like home by Norah Jones Play Add to playlist 7. Creepin' In from Feels like home by Norah Jones Play Add to playlist 2. What Am I to you from Feels like home by Norah Jones Play Add to playlist
Yeah, sorting by filename is of fairly limited use once you get inside a cuesheet. It's not pretty, but it does make sense why it's like that for that particular setting. As for the sorting when it does get set to tags... That is weird. I'm not sure why it's doing that. I'll dig into it a bit tonight and see what I can figure out.
Is this only in 6.1 or is it in 6.0.2 also?
It seems to be fine in 6.0.2, so apparently this is only an issue for 6.1
Michael: Are you looking into this for 6.1?
*** Bug 720 has been marked as a duplicate of this bug. ***
How is this looking now with the new BMF code?
ok I just took a look at the current state of this issue, and it's significantly different than it used to be (as documented above). I would say that we're actually much worse off than we used to be. Here's the current (revision 3582) behaviour as far as I can tell... External cuesheets and "sort by song information" -the cuesheet itself is visible. drilling down into the cuesheet shows the correct tracks with the correct info and in the correct order. the server thinks it's a playlist (which is how it's always been treated internally) and so it shows the "rename this playlist" box at the top (along with edit, delete, etc.). this is probably not what we want, as "renaming the playlist" will delete the cue file and generate a m3u that won't necessarily be able to capture all the metadata from the original cuesheet. -the file referenced by the cuesheet is also visible (we used to keep it hidden , as the relevent data for browsing purposes is all in the cuesheet). drilling down into this file predictably shows a song info page suggesting a "no artist / no ablbum" track (not accurate, and yet another reason to hide this file from browsing). External cuesheets, and "sort by file name" -the cuesheet itself is visible. drilling down into it shows the "rename this playlist" options, but no tracks are listed as being part of this "playlist". -the referenced file is visible as above. drilling down into it shows the "no artist / no ablum" page as above, except that it also produces a backtrace from the server complaining about an undefined string. Internal cuesheets (flac only at the moment), using "sort by song information" -the flac file itself is visible. drilling down into it gives a page with the "rename this playlist" options but again no actual listing of the contained tracks. Internal cuesheets (flac only at the moment), using "sort by file name" -same as above.
Michael, any chance you will have time to work on these issues in the next couple of weeks (the 6.1 final timeframe)? If not, reassign to Dan and we'll try to get to it on our side.
I'll poke at it and see what I come up with. So far I'm still catching up on the changes to Browse Music Folder and playlist management.
I've checked in a fix for these as subversion change 3682. As far as I can tell, the filesort preference isn't really needed anymore.. Vidur?
so this is what I see as of change 3682 ... External cuesheets -the cuesheet itself is visible. drilling down into it shows no tracks listed (just a blank page) -the referenced file is not visible Internal cuesheets (flac) -the file is not visible at all On the plus side, you won't trash your external cuesheets with the edit playlist option anymore. and I'm all in favor of ditching the filesort preference. so that part is better, but I suspect that flac files with internal cuesheets should at least be visible. and it would probably be ideal to be able to see the tracks inside a cuesheet (internal or external).
as an update to the above assessment, I tried this on another machine (running the same revision) and the external cuesheet worked properly. (Internal ones are still invisible.) I'm still trying to track down what is different between the two installations to cause the divergent behaviour.
change 3690 reveals flac files with internal cuesheets (and other container formats) when browsing the music folder. Drilling down into a flac that has an internal cuesheet behaves the same as drilling down into an external cuesheet (like a playlist without the edit option).
For external cuesheets the key element here seems to be: Server Settings -> Playlists Folder If you have a directory specified, then cuesheets get a duplicate entry in the db in the form playlist:///foo.cue (in addition to the file:///foo.cue which exists either way). This situation causes browsing music folder into the playlist to appear as an empty list (the blank page mentioned above). It also makes the cuesheet show up under "Browse Playlists" complete with file destroying edit/rename options we avoided in "Browse Music Folder" with change 3682. If you don't specify a playlists folder, then everything seems to work resonably. cuesheets don't appear in "Browse Playlists" and thus can't be destroyed with the edit/rename options, and "Browse Music Folder" shows the tracks in the cuesheet when you navigate into it. Of course you can't save actual playlists (that survive a rescan) with this option. On the other hand, flac files with internal cuesheets don't show up in playlist_track either way. So they don't show in "Browse Playlists" but also don't show tracks when you navigate into them via "Browse Music Folder". I'm not sure how anyone else feels, but I'd think the intended behaviour would be that cuesheets don't show up in "Browse Playlists" (and of course do show tracks when pulled up in "Browse Music Folder"). If this works for everyone, the trick seems to be 1) to avoid playlist:///foo.cue entries for external cuesheets regardless of the "Playlists Folder" setting, and 2) ensure entries into playlist_track for files with internal cuesheets.
change 3702 implements the behaviour mentioned in the previous comment. The only remaining issue I see is that there is still one way to get the file-eating edit/rename playlist widget to apply to cuesheets. (browse into the cuesheet via Browse Music Folder, then click on the cuesheet name in the Home / Browse Playlists / foo breadcrumbs.)
Michael: are you going to take a crack at this or should I reassign the bug?
I have a preliminary start on this. If someone doesn't tackle it first, I'll poke at this more in the next week and see what I can come up with.
What is left to tackle on this one exactly? Summary should probably change to fit.
Michael? Are you on this or should we reassign?
Hello? Michael? Are you out there? :)
Michael? Should we assign this bug away? Are you looking at it? Sorry to be a pest, but we're trying to get things nailed down for the 6.2 release.
just took another look at this, and the status seems to be the same as it was in july. most of the original problem is fixed, but slimserver will still eat your cue sheet files off of your hard drive as mentioned above. I'll take a look at this and see what I can find.
Dan's going to look at this.
Final bit fixed in subversion change 4608