volpone;639876 Wrote: 
> Hi Erland,
> I'm interested in your opinion about logged error and also on other
> users experiences with quite big libraries,mixed tags menus and
> multilibrary (perf and squeezebox-persistent.db size).
> 
I've heard other users complaining about large squeezebox-persistent.db
file but in my own tests the MySQL database from 7.5 has been larger
than the corresponding squeezebox.db/squeezebox-persistent.db files in
7.6.

Do you know or can you check how large the MySQL 7.5 database were ?
It should be in the "MySQL" directory inside SBS cache directory, you
can find the location of the cache directory through SBS
Settings/Information tab.

Do you know how big the squeezebox-persistent.db was before you started
the first rescan ?

In my mind I suspect the space is taken by the TrackStat history table
because this table gets larger over time as you play stuff, but this
shouldn't be affected during a rescan. I'll probably add some clean-up
option in a future TrackStat release to handle this so you can tell it
to discard history older than a xx months or something similar.

Regarding performance in big libraries with 7.6 and SQLite I suspect
there is still optimization potential. The analyze requests at the end
of the Custom Scan rescan operation in Custom Scan 2.8.3363 did magic
in my own small library regarding the "Tags" or "Dynamic Tags" menu, it
went from completely unusable to instantaneous response.

At the moment I've trouble testing the plugins with large databases as
my main library is rather small, I think I'll need to figure out a way
to generate a large database even though I don't have the real music
files for it.

Regarding the errors in server.log:

Code:
--------------------
    
  [11-07-09 11:17:11.4950] Slim::Schema::Storage::throw_exception (100) Error: 
DBI Exception: DBD::SQLite::db do failed: database disk image is malformed
  
--------------------

This is bad, something similar happen to me the other day when I had
killed SBS during scanning and I was forced to manually delete both
squeezebox.db and squeezebox-persistent.db files.

When deleting the *.db files it's important to have a TrackStat backup
file because if you don't you obviously loose all TrackStat data. You
have to restore the TrackStat backup file after you have scanned the
library to get it back.

Killing the scanner process is bad for the database, SQLite seems to be
a lot more sensitive than MySQL regarding this based on my own
experience so far. So keeping external backups of TrackStat data which
you don't want to loose is very important.


Code:
--------------------
    
  [11-07-09 11:17:41.6033] Slim::Schema::Storage::throw_exception (119) Error: 
DBI Exception: DBD::SQLite::db do failed: database is locked
  
--------------------

This worries me but hopefully it's caused by the malformed database
file. But I suspect things like this could happen if SBS starts to scan
while Custom Scan is still scanning from a previous scan.

But it seems like you got this also after the last restart and at that
time it looks like no scanning was in progress when I look at the log.
Let me know if you keep get this message after you've got the system to
work correctly.

Code:
--------------------
    
  [11-07-09 12:24:30.9443] Slim::Schema::Storage::throw_exception (119) Error: 
DBI Exception: DBD::SQLite::db prepare failed: no such table: 
multilibrary_libraries
  
--------------------

I think this could be a bug, let me know if you always get this after a
server restart after you have performed a full rescan.

It seems like the tables are only created at plugin startup and I think
that's wrong in 7.6, I think I need to create them also after a rescan
because SBS will drop the complete squeezebox.db file where these
tables are stored.

How are the different "Rescan" related parameters configured in "Multi
Library" plugin, do you have them all set to "Yes" ?


Code:
--------------------
    
  [11-07-09 12:24:30.9461] Slim::Schema::Storage::throw_exception (119) Error: 
DBI Exception: DBD::SQLite::db prepare failed: no such table: track_statistics
  
--------------------

This means all your TrackStat data is lost, so hopefully you have a
TrackStat backup. TrackStat data is stored in squeezebox-persistent.db
and it should survive rescans. 

It could maybe somehow be caused by the corrupt database. But let me
know if you see this again.

To sum it up, none of the errors should come in a working setup so if
you continue to get any of these it means something isn't working
correctly, probably mostly because bugs in my code.


-- 
erland

Erland Isaksson ('My homepage' (http://erland.isaksson.info))
(Developer of 'many plugins/applets'
(http://wiki.slimdevices.com/index.php/User:Erland). If my answer
helped you and you like to encourage future presence on this forum
and/or third party plugin/applet development, 'donations are always
appreciated' (http://erland.isaksson.info/donate))
------------------------------------------------------------------------
erland's Profile: http://forums.slimdevices.com/member.php?userid=3124
View this thread: http://forums.slimdevices.com/showthread.php?t=88627

_______________________________________________
beta mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/beta

Reply via email to