Bugzilla – Bug 3617
Browse by artwork crash - data too long
Last modified: 2008-09-15 14:39:24 UTC
2006-06-21 00:52:12.5263 find: $VAR1 = {}; 2006-06-21 00:52:12.5267 running resultset on: album 2006-06-21 00:52:17.7656 DBD::mysql::st execute failed: Data too long for column 'thumb' at row 1 at P:\Music\SlimServer\trunk\server\CPAN/DBIx/Class/Storage/DBI.pm line 525. DBIx::Class::InflateColumn::update(): Error executing 'UPDATE tracks SET thumb = ? WHERE ( id = ? )' (`M:\Music\Phil's Music\Electronic Music\Fanger & Sch�nw�lder\Analog Overdose 4\folder.jpg', `2761'): DBD::mysql::st execute failed: Data too long for column 'thumb' at row 1 at P:\Music\SlimServer\trunk\server\CPAN/DBIx/Class/Storage/DBI.pm line 525.
and if you remove the non-latin chars form the pathname?
I renamed the folder, rescanned, and browsed artwork. Fell over on another folder with unicode chars. Good spot.
perhaps this is one of those cases where the field needs to be "text" type instead of "varchar(255)"?
Fix in change 8081 You'll need to wipe & rescan.
I updated, did a complete rescan, and still see the same error. I believe that I am now seeing less album artwork, and the trace has many new warnings in it, like: Use of uninitialized value in string eq at P:\Music\SlimServer\trunk\server/Slim/Schema.pm line 1616, <GEN78> line 6. I'm seeing the above for <GEN78> and <GEN80>, with lots of different reported line numbers.
Phil - can you try changing those text columns I changed to blob instead?
I think I misunderstood your previous post. I did a "Clear library and rescan everything", which apparently didn't cause the table changes to be applied. I assumed it would drop all slimserver-created tables and recreate them and then do a full rescan. I checked in MySQL - the table still had varchar types, so I manually dropped the database and recreated it manually following the wiki MySQL instructions. I noticed that there was a note that I had previously ignored about needing to set the character encoding. As my paths aren't 255 chars long, I don't think the change to text or blob is the crucial thing (more likely the character encoding caused the problem). I tried to set the DB to use UTF-16 (mp3tag app is configured to write id3 v2.3 tags in unicode utf-16), however, MYSQL doesn't seem to support UTF-16, so I used UTF-8. It would be nice if slimserver could create the DB if it doesn't exist. Is that the intention (Nb. I installed my own MySQL instance)? If so, what character encoding would it get created with? I *still* get the same crash though. I will try converting those columns to blob.
Phil - SlimServer will create the tables if they don't exist, but you need to create the DB itself if you are running your own MySQL instance (db permissions would stop us from creating the DB) The DB should be using UTF-8 - see the MySQL/my.tt file for an example. Don't worry about the UTF-16 encoded data, it's converted to UTF-8 at scan time.
MySQL/my.tt - does slimserver use this file, or am I supposed to do something to MySQL manually to use those settings? I tried again with blobs instead of text, and I managed to get the first page of browse artwork to work. I moved to "B" alpha page link, which was okay, and then jumped to "Y". Whilst loading the thumbnails, I had a perl interpreter crash: Faulting application perl.exe, version 5.8.8.817, faulting module ntdll.dll, version 5.1.2600.2180, fault address 0x00001095.
SlimServer uses that file if you let it use the internal MySQL. What was the reason for setting up your own MySQL instance? We can better support you if you use the internal one.
I wanted a bit more control over the MySQL installation, when it gets upgraded, etc, as I may put additional databases into it. I haven't had any problems, although I understand that I may have to apply optimisation settings manually. How would I switch slimserver such that it uses an internal instance?
If you remove the dbsource line from the prefs file, it will use the defaults, and start a MySQL instance.
I tried changing the text columns to blob, and it's now working fine (still using my instance of MySQL).
Fixed in change 8175