Phil Meyer;206437 Wrote: > I'm having trouble with the Custom Scan - MixedTag scanning module. > I've rescanned the library okay, but when I do a MixedTag scan, I get a > few occurances of the following: > > 2007-06-03 01:31:27.8906 CustomScan: Failed to scan SlimServer tags: > DBD::mysql::st execute failed: Data too long for column 'url' at row > 2875 at > P:\Music\SlimServer\trunk\server/Plugins/CustomScan/Modules/MixedTag.pm > line 269. > > I tried turning on customscan debug messages, but don't see anything > else useful in the log. > > Phil Custom Scan can't currently handle url's longer than 255 characters, there is bug where this isn't checked in the Mixed Tag module. The problem is that the fix would be to ignore scanning tracks with urls longer than 255 characters.
But skipping tracks would also mean that they aren't browsable using the new "Dynamic Tag" menu type or any of the old custom tag based menu types. The reason Custom Scan can't handle long urls it that MySQL can't handle joining two tables which contains binary values. The CPU will start to use 100% CPU in a large collection and completely lock the computer, the only solution to get back the control when this happens is to use power switch. I had this problem with TrackStat a year ago. The current solution in TrackStat and Custom Scan for this is defining the column as varchar(255) instead. TrackStat skips tracks with longer urls, Custom Scan currently doesn't handle it correct which results in the error message you saw. So I can see a number of solutions myself: 1. Skip tracks with longer urls than 255 characters, which results in that these are excluded from Custom Scan based browse menus. This is the current solution, but there is a bug that causes an error message and probably aborts the scanning. 2. Define the column as "text" instead of "varchar(255)", making it deadlock the whole computer in a large collection. 3. Define the column as "text" instead of "varchar(255)" but don't synchronize the Custom Scan tables with the standard SlimServer tables. That is, avoid the situation where the 100% CPU problem could occur. The result of this is that you will get into problem if you move a file and don't perform a scan with Custom Scan. However, this might not be a big problem since Custom Scan is launched automatically after a SlimServer rescan and if you have moved some files you are probably going to perform a SlimServer rescan. It still might be problematic for those using iTunes or MusicMagic integration, because I don't think Custom Scan will run automatically after the the iTunes/Music Magic plugin has performed a scanning. I personally think solution 3 is the best, so unless anyone else have some other idea I will look at that. LastFM data and Amazon data will still not have to be rescanned since they use the artist name or album title as key and not the url. If anyone is interested in the MySQL 100% CPU problem, this is the thread I started related to this in the MySQL forums: http://forums.mysql.com/read.php?10,87609,87609#msg-87609 -- erland Erland Isaksson 'My homepage' (http://erland.homeip.net) 'My download page' (http://erland.homeip.net/download) (Developer of 'TrackStat, SQLPlayList, DynamicPlayList, Custom Browse, Custom Scan, Custom Skip, Multi Library and RandomPlayList plugins' (http://wiki.erland.homeip.net/index.php/Category:SlimServer)) ------------------------------------------------------------------------ erland's Profile: http://forums.slimdevices.com/member.php?userid=3124 View this thread: http://forums.slimdevices.com/showthread.php?t=35815 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/plugins
