>I think that when (or if) MySQL starts working reliably again it will
>be proven that SQLite is faster doing scans.  Since the new & changed
>scans have been moved internally instead of launching the external
>scanner they're insanely fast.  Just now, to do a new & changed scan on
>my 30k track library with two new albums took just 9 seconds.
>
But how can you tell that SQLite is the part that's getting that speed 
improvement?  I saw a large improvement in scanning through other things, such 
as compiled C++ scanner rewrite, optimised SQL queries, etc.

The longest part of scanning for me seems to be directory scanning and reading 
tags.  I don't see how the DB engine would improve that.

>Squeezebox Server's instance of MySQL Server won't have to be installed
>as a Windows service
No difference there between MySQL and SQLite.

Are there issues with SQLite being exclusively locked by SBS, eg. when scanning 
for new/changed files, can you still play music uninterrupted?

To be honest, I'm not all that bothered by scanner performance - it's one of 
those things that I expect to take a bit of time, and a new/changed scan has 
never really caused problems for me (can do all sorts of things whilst it is 
scanning).  I'm more interested in seeing speed improvements for browsing the 
music library, which for certain operations is becoming quite slow for me now, 
as my library is only ever going to grow.

I'm sure in general SQLite is faster all round (provided the DB fits into 
memory and doesn't cause swapping), but really I wouldn't expect for this type 
of application for the DB to make significant difference to overall scan - if 
so, it's probably due to inefficient DB access for later stages of scanning, 
such as merging various artists, etc.  I came up with a single SQL statement to 
update all rows for this stage, as an alternative for the 7.5 SBS perl 
application code method, which would have been significant, for example.
_______________________________________________
beta mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/beta

Reply via email to