Bugzilla – Bug 3417
Option to skip CUE sheet parsing
Last modified: 2008-09-15 14:39:24 UTC
I store CUE sheets referencing individual tracks in my music folders, to be used to duplicate the cd if I desire in the future. These reference WAV files, but the music is stored as Flac. My server log file is filled with error messages as the CUE sheets are parsed, but the files not found. (Why is it logged three times?) --------------- 2006-05-14 13:48:50.4177 ERROR: parseCUE: Couldn't find referenced FILE: [\\bob\music\flac\Miles Davis\Sketches of Spain\08 Concierto De Aranjuez (Part Two Ending).wav] on disk! Skipping! 2006-05-14 13:48:50.4362 ERROR: parseCUE: Couldn't find referenced FILE: [\\bob\music\flac\Miles Davis\Sketches of Spain\08 Concierto De Aranjuez (Part Two Ending).wav] on disk! Skipping! 2006-05-14 13:48:50.4544 ERROR: parseCUE: Couldn't find referenced FILE: [\\bob\music\flac\Miles Davis\Sketches of Spain\08 Concierto De Aranjuez (Part Two Ending).wav] on disk! Skipping! --------------- How about a preference to just skip CUE sheets so that the scanner doesn't waste all that time looking for the files and then logging these errors?
I just remembered something... I have a "custom-types.conf" file that goes way back to an earlier version of SlimServer being unable to deal with these CUE sheets in the music directory. IIRC, the earlier problem was duplicate tracks showing up in the database (even though the files weren't found then either). I believe the following custom types directive was intended to render these .cue files benign. ------------- cue cue text/plain - ------------- So maybe this is actually a bug if this is being ignored. In any case, a pref would be easier for most people than keeping a custom types file.
not everything needs to be exposed to the web ui, especially when there are just as many users who already complain about having too many prefs to deal with. consider conf files as advanced pref facilities. not sure why the cue is still being parsed when it is being overridden by a custom type. might be useful to check if the custom file is properly overwriting the default file, whether removing the cue line from the default file has any effect
Like I said, perhaps it's a bug. If the custom-types file is supposed to work like this, then yes, there'd be no overriding need for a pref. I imagine the average person isn't going to care if SlimServer scans these CUE sheets pointing nowhere and probably won't be logging errors, so they won't see the three log entries per attempt. Still, it's got to eat up CPU cycles doing essentially nothing. My 6.5 installation is stuck at about r7500, so I'll look at it again in a couple weeks when 6.5 has again become usable. It may not even be an issue with the new scanner.
Feature added in change 8171 Under the File Types settings page.