FC3, MySQL 5.0.24, perl 5.8.8, slimserver 6.3.1

[RichardG]

First off, I realize that MySQL is unsupported for slimserver 6.3.1. I'm hoping that someone has had a chance to try this type of setup and can give me some advice without taking too much of their time.

I have an FC3 installation (installed as server with console only). I upgraded with gcc rpms to allow compiling. I downloaded and compiled perl 5.8.8. Same for MySQL 5.0.24. Followed advice on the wiki for MySQL. Everything looks good. I can start slimserver and the database is working. However, when I try and do a rescan, I am getting an error (or perhaps a warning) message in the Ima:BI helper class for each track in the audio directory. These messages resemble:

2006-08-17 11:24:35.4679 prepare_cached(SELECT id, name, namesort, moodlogic_id, moodlogic_mixable, musicmagic_mixable
FROM genres
WHERE namesort = ?
) statement handle DBIx::ContextualFetch::st=HASH(0xa848380) still Active at /usr/local/slimserver/CPAN/Ima/DBI.pm line 391

Is there something I can do to stop these messages? I tried updating Ima:BI to version .34 from version .33 (and renaming Ima under slimserver/CPAN to Ima_orig), but this had no result, and the problem appears to be in the Datastore management routines.

If I can't stop these message by correcting my installation, can I comment out the source of these messages and expect the server to operate normally?

Thanks for any help,

Richard

[RichardG]

Looks like there's a bug on this already.. downgrade or go hunting. I'll hunt for a few hours.

http://bugs.slimdevices.com/show_bug.cgi?id=3792

Richard

[RichardG]

Best I could do was a hack to Ima:BI (the latest version) at around line 381:

<< ? $dbh->prepare_cached($sql)
>> $dbh->prepare_cached($sql, undef, 3)

Install > 1.40 DBI (not Class:BI since Slim:ataStores:BI:ataModel is written against Class:BI in Slim/CPAN, and new versions result in a failure to locate object method "use_object_index"). The value of 3 tells the database to leave active handles alone, but drop them from the cache. This prevents inner/outer fetch collisions at the expense of CPU cycles. No warnings are issued.

Richard