Bugzilla – Bug 885
ending time missing for files referenced by external cuesheet
Last modified: 2008-09-15 14:37:04 UTC
when using an external cuesheet to reference parts of a multi-track audio file, the last track referenced is missing an ending time, resulting in an invalid anchor. some transcoding methods, (Flac for one) don't deal well with an ending time (0:00 in this case) that is less than the starting time. an example (using --d_source)... 2005-02-28 22:40:28.2145 Found command: [flac] -dcs --skip=$START$ --until=$END$ $FILE$ | [lame] --resample 44100 --silent -q$QUALITY$ -b$BITRATE$ - - 2005-02-28 22:40:28.2164 Matched Format: mp3 Type: flc Command: [flac] -dcs --skip=$START$ --until=$END$ $FILE$ | [lame] --resample 44100 --silent -q$QUALITY$ -b$BITRATE$ - - 2005-02-28 22:40:28.2165 openSong: this is an flc file: file:///var/audio/cue-test/external/withtags/Tori%20Amos%20-%20Winter.flac#983.24-0 2005-02-28 22:40:28.2165 file type: flc format: mp3 inrate: 775.284219205071 maxRate: 320 2005-02-28 22:40:28.2166 command: [flac] -dcs --skip=$START$ --until=$END$ $FILE$ | [lame] --resample 44100 --silent -q$QUALITY$ -b$BITRATE$ - - Use of uninitialized value in substitution (s///) at /usr/src/slim/trunk/server/Slim/Player/Source.pm line 1336. 2005-02-28 22:40:28.2176 Using command for conversion: "/usr/src/slim/trunk/server/Bin/i386-linux-thread-multi/flac" -dcs --skip=16:23.24 --until=0:00.00 "/var/audio/cue-test/external/withtags/Tori Amos - Winter.flac" | "/usr/bin/lame" --resample 44100 --silent -q -b320 - - & | 2005-02-28 22:40:28.2257 Streaming with format: mp3 Tori Amos - Winter.flac: ERROR, --until value is before --skip point Assuming raw pcm input file
*** Bug 904 has been marked as a duplicate of this bug. ***
Created attachment 287 [details] read an ending time for the last track here's one way to grab the info we're missing.
Fixed in subversion change 2273.
updating to this, the server crashes. ->updateOrCreate is called without $attributeHash so DBIStore::_preCheckAtributes crashes at line 1010. log: 2005-03-01 21:23:15.8419 Parsing cue: FileHandle=GLOB(0x9a1a0f8) 2005-03-01 21:23:15.8435 parseCUE: cuedir: [file:///mnt/mp3/Alternate/FLAC/CUE] secs: [0] noUTF8: [1] 2005-03-01 21:23:15.8561 Merging entry for file:///mnt/mp3/Alternate/FLAC/CUE/U2_How_To_Dismantle_An_Atomic_Bomb.flac 2005-03-01 21:23:15.8569 Backtrace: frame 0: Slim::DataStores::DBI::DBIStore::_preCheckAttributes (/usr/local/slimserver/trunk/Slim/DataStores/DBI/DBIStore.pm line 473) frame 1: Slim::DataStores::DBI::DBIStore::updateOrCreate (/usr/local/slimserver/trunk/Slim/Formats/Parse.pm line 278) frame 2: Slim::Formats::Parse::parseCUE (/usr/local/slimserver/trunk/Slim/Formats/Parse.pm line 414) frame 3: Slim::Formats::Parse::readCUE (/usr/local/slimserver/trunk/Slim/Formats/Parse.pm line 52) frame 4: Slim::Formats::Parse::parseList (/usr/local/slimserver/trunk/Slim/Utils/Scan.pm line 583) frame 5: Slim::Utils::Scan::readList (/usr/local/slimserver/trunk/Slim/Utils/Scan.pm line 204) frame 6: Slim::Utils::Scan::addToList_run (/usr/local/slimserver/trunk/Slim/Utils/Scheduler.pm line 95) frame 7: Slim::Utils::Scheduler::run_tasks (./slimserver.pl line 549) frame 8: main::idle (./slimserver.pl line 512) frame 9: main::main (./slimserver.pl line 1053) Can't use an undefined value as a HASH reference at /usr/local/slimserver/trunk/Slim/DataStores/DBI/DBIStore.pm line 1010, <GEN44> line 67.
I'm also curious of the effects when considering svnr2265, where the patch in that case specifically says not to readTags on a file referenced by a cue sheet. could this then retrigger the duplicate entries?
The recent patch from bug 717 should prevent any duplication resulting from readTags. The file referenced by the cuesheet will exist in the db, but marked as a non-audio type, so it shouldn't show in the music listings. I don't know of a better way to get the ending time of the referenced file, that works across all content types that could be referenced.
ok, I think i understand the intent. however, updateOrCreate seems to barf if called without any 'attributes' arg. we need to find a safe way to get around that while grabbing the needed info. would this work if we supplied a hardcoded CT just to have at least one of the attributes filled?
Created attachment 289 [details] improved version of determining ending time of last track This seems to survive anything I can throw at it.
Ok - I've applied the second patch now. Thanks.
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006. I am setting them to targets of 6.2.1 to keep them from showing up in my queries.