GNOME Bugzilla – Bug 537873
Itunes volume normalization comment field causes sql token exception
Last modified: 2010-02-19 09:20:43 UTC
When importing the following an mp3 file with the following id3v1 comment field: COMM (Comments): (iTunNORM)[eng]: 0000177A 00001A2D 0000510B 00005922 00007547 00007547 00008000 00008000 00007530 00007530 banshee 1.0.0 crashes with debug output: [Debug 16:47:47.329] Exception executing command: INSERT INTO CoreTracks (Rating,LastStreamError,PrimarySourceID,ArtistID,AlbumID,TagSetID,MusicBrainzID,MimeType,FileSize,Attributes,Title,TrackNumber,TrackCount,Disc,Duration,Year,Genre,Composer,Copyright,LicenseUri,Comment,PlayCount,SkipCount,LastPlayedStamp,LastSkippedStamp,DateAddedStamp,DateUpdatedStamp,Uri,UriType,TitleLowered) VALUES (0,0,1,205,320,0,NULL,'taglib/mp3',4104027,5,'Fight Test',7,0,0,256891,0,'',NULL,NULL,NULL,NULL,0,0,NULL,NULL,1213220867,1213220867,'file:///mnt/media/music/music-robby/Flaming%20Lips/Yoshimi%20Battles%20the%20Pink%20Robots/07%20Fight%20Test.mp3',2,'fight test') [Warn 16:47:47.332] Caught an exception - unrecognized token: "'" (in `Mono.Data.SqliteClient') at Mono.Data.SqliteClient.SqliteCommand.GetNextStatement (IntPtr pzStart, System.IntPtr& pzTail, System.IntPtr& pStmt) [0x00000] at Mono.Data.SqliteClient.SqliteCommand.ExecuteReader (CommandBehavior behavior, Boolean want_results, System.Int32& rows_affected) [0x00000] at Mono.Data.SqliteClient.SqliteCommand.ExecuteNonQuery () [0x00000] at Hyena.Data.Sqlite.HyenaSqliteCommand.Execute (Hyena.Data.Sqlite.HyenaSqliteConnection hconnection, Mono.Data.SqliteClient.SqliteConnection connection) [0x00093] in /tmp/buildd/banshee-1.0.0/src/Libraries/Hyena/Hyena.Data.Sqlite/HyenaSqliteCommand.cs:116 [Debug 16:47:47.333] type of key value: System.Int32 ------------------------- Removing the comment field prevents banshee from freezing/crashing
The comment tag you attach is from ID3v2, because iTunes stores normalization data in it. I have imported several tracks with that normalization data and I have had no problem. On importing the data is still in the file, although doesn't appear in the Track Editor. When saving in Track Editor, that data is cleared.
I have tested it with trunk version. When importing, the comment field in the DB is NULL. Should this data be kept?
> I have tested it with trunk version. When importing, the comment field in the > DB is NULL. Should this data be kept? I don't have any iTunes-made tracks available, but I suspect the change in behavior is due to the fix for bug 558123; perhaps the comment field is actually something like {\x00}0000177A [...]. Could you encode a small file, such as 5 seconds of whitespace or similar, with iTunes and then test it? If it exhibits the comment-stripping behavior, please upload it to the bug tracker so I can look at the ID3 tags directly.
Created attachment 131275 [details] Little audio file with normalization data
Some poking at TagLib reveals it will only provide comment information for comments without a description. That is, this will appear in Banshee: COMM description="" text="My comment here" but this won't: COMM description="iTunesNORM" text="00000000..." Happily, the special comment won't actually be removed from the file -- it just isn't displayed in the user interface. Editing the interface comment and saving metadata preserves the "hidden" comment as well. ---- I'm not able to reproduce the original bug/crash, though. Based on the error message, I suspect that Id3 2.4 comments were at some point in the past handled as a single text string, rather than (description, text) pair. That could have caused the original error. Alternatively, an old version of iTunes might have written invalid tags to the file.
Thanks for taking the time to report this bug. This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed. It should be solved in the next software version. You may want to check for a software upgrade. *** This bug has been marked as a duplicate of bug 599806 ***