Bugzilla – Bug 9359
Scanner aborts when finding files with 'id' tag
Last modified: 2009-07-31 10:28:44 UTC
Created attachment 3921 [details] Fix for FLAC metadata mapping Currently, the Squeezecenter scanner will never scan my collection, as it aborts during the scan. The relevant parts of my scanner.log file are up at: http://ozlabs.org/~jk/tmp/squeezecenter/scanner.log One of the files that will cause this abort has the following tags: ALBUM=Amphetamine 12" ARTIST=Drax DESCRIPTION= GENRE= ID=ACA9826R-12 TITLE=Amphetamine (Gecko Remix) TRACKNUMBER=2 From the logs, it looks like squeezecenter is trying to populate the 'ID' column (ie, the integer primary key) of the track table with the ID= value of the tag, so the insert fails. The insert command: [08-09-01 20:56:55.9120] Slim::Schema::Debug::query_start (26) INSERT INTO tracks (audio, audio_offset, audio_size, bitrate, channels, content_type, drm, filesize, id, lossless, remote, samplerate, secs, timestamp, title, titlesearch, titlesort, tracknum, url, vbr_scale, year) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?): '1', '0', '47436132', '921880.552676116', '2', 'flc', '0', '47436132', 'ACA9826R-12', '1', '0', '44100', '411.602721088435', '1141561255', 'Amphetamine (Gecko Remix)', 'AMPHETAMINE GECKO REMIX', 'AMPHETAMINE GECKO REMIX', '2', 'file:///home/jk/music/Drax%20Ltd%20II/ACA9826R-12/Amphetamine%20(Gecko%20Remix).flac', '1', '0' The attached patch fixes the problem for me, but seems to be a bit of a "paper-over" solution. Is there a way to globally disallow 'id' tags from being used as the 'id' column?
Andy: can you take a look at the attached patch (and bug) then comment please.
I assume you meant for this to be a 7.2 bug? Patch looks simple enough, will test and apply soon.
> I assume you meant for this to be a 7.2 bug? Not sure about squeezecenter versioning - the bug appears on my installed squeezecenter (7.2), but the patch is still required for the current svn. > Patch looks simple enough, will test and apply soon. Are you sure this is the right way to fix the problem? shouldn't we stop the IDs from getting to the SQL query in the first place? (eg, removing them in Slim::Schema::_preCheckAttributes?)
Fixed in 7.2.1 change 23260.
So if a tag happens to have the same name as a column in the tracks table, and isn't handled otherwise, SqueezeCenter just tries to store it in the tracks table with no further data validation? There's something not right about that.
Verified with SqueezeCenter Version: 7.2.1 - 23565. I added the keyword new_schema in order to consider a better solution in the future.
This bug has been fixed in the 7.3.0 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Reduce number of active targets for SC