Bugzilla – Bug 2323
playlist files still causing scanning issues
Last modified: 2008-09-15 14:39:24 UTC
I'm still seeing problems when playlist files (CUE + m3u) are present in the audio directory. For example, I have a two-disc album and the cue file causes an extra album to be added to the database with just one track (the last track in the cue file). I am currently working round this by chmod'ing all my cue and m3u files as 000 so slimserver can't see them!
Robin - can you bundle up a zip or .tar.gz file and attach it to this bug with the directory layout and truncated audio files (to just include the metadata headers)
Created attachment 926 [details] Example of the sort of files that cause the problem The archive contains te two-disc set with playlist (CUE,m3u) files that cause slimserver to add rogue entries in the DB.
Robin - the m3u file doesn't come into play. The cue file will of course get scanned, as that's how many people deal with their music.. You should make sure that the title in the FLAC files matches up with the title in the cue sheet.
So, why do folk use the CUE file? I mean, if your files are all tagged correctly there's no point, is there?
people are just crazy sometimes :) Some don't want to tag their files, since they feel the CUE sheet is enough. As for why, probably just personal preference just as you prefer to consider CUE sheets as something to ignore.
Fixed! Change 4722
Not so fast Mr. Bond^WSully... The code still adds an empty album from the cue file even if none of the tracks within the cue file exist.
I'm seeing some possibly related behavior with mp3+cue files. Upon an initial scan, the metadata as pulled from the cue file is correct when checked with the web interface. However, when I play a m3u playlist containing entries from one of those mp3+cues (in file:///...mp3#xxx-yyy notation), they won't play. If I check the metadata again in the web interface, the album titles have been blanked out. If I try to play an album, the tracks show up with artist (from file name) - album (from file name) - artist (from cue file). Instead of TITLE - ARTIST - ALBUM. So something in the m3u parsing routine seems to be zapping the metadata read from the cues - which was initially correct.
Jason - I believe that is a different bug, and should be fixed now. Could both of you sync up to HEAD on svn? There have been a few small fixes. Thanks.
Created attachment 933 [details] Joe Jackson - Summer In The City OK, I'm still having minor problems with CUE file processing. I've attached a tarball of an album I've tested that exhibits the problem. Basically, when I re-scan my music directory I see two albums from this one directory: Summer in the City by Joe Jackson Summer In The City (Live In New York) (2000) by Joe Jackson The second entry is correct and shows all 13 tracks. The first entry is incorrect and shows just the last two tracks from the album. Now, I would understand if it showed *all* tracks from the album - in that case I would just hide my .cue files. But, as it's only showing 2/13 files I would say that there's still a bug hiding in here somewhere.
Thanks Dan - my issue is fixed in latest SVN. Sorry for the unintentional bug-hijack!
poking around at this myself. seems to be all ok until track 13 is present. Even with just track 13, the other album shows. It seems that the cue is being parsed somehow. I just haven't nailed it down yet. It then seems to show 13 files of the same name, with wrong index anchors until the last song, which has #0-214. Should the INDEX key in the cue files all be the same time index? I wonder if those were corrected if the CUE would parse as a proper whole album. Getting it to not parse is another matter :) I'll keep looking at it.
Created attachment 994 [details] flac with simulated, non-matching times for index corecting the CUE file for the flacs to have different times for the INDEX, the CUE parses cleanly. Of course, since the title line in the cue uses "Summer In The City" this results in a second album, but now it has all entries showing cleanly. I would assume the files would also play correctly from this. Odd that this cue file came out without time indeces. is this normal? Maybe a sanity check would help to avoid confusing parsing with files such as this?
This will be fixed in the scanner branch.
*** Bug 2669 has been marked as a duplicate of this bug. ***
*** Bug 3364 has been marked as a duplicate of this bug. ***
Robin - is this still an issue with 6.5? Thanks
(In reply to comment #17) > Robin - is this still an issue with 6.5? I seem to remember it is. I'll try a rescan and do some tests. R.
I did the following: find /home/slimserver/music/library/ \( -iname "*.cue" -o -iname "*.m3u" \) -exec chmod o+r \{\} \; /opt/slimserver/trunk/server/scanner.pl --wipe --progress --prefsfile=/var/opt/slimserver/lib/trunk/slimserver.conf I've had a look at the albums that had a problem previously and all seems well. I've marked this bug as fixed.