>Damn, good catch! I guess I'll work up an RC3 later tonight. :( > Ah, I just came to the same conclusion, having witnessed a much increased scan time (30mins = 50% extra). I went looking at the DB content.
On one hand it should be quicker to create track records when scanning, but not if the scanner reads back tracks to calculate other stuff from. It looks like there may be too many indexes - e.g. in the albums table, there's an index on disc count (discc column) and another on artwork column. Are there really any queries that fetch a set of albums filtered or ordered by total number of discs on the album? Or a query to find album record(s) that has a unique artwork cache name??? Also, I'm not sure about the benefit of an index on compilation flag, which is only ever 1 or NULL. And yet there's no index on albums.contributor, which would sound beneficial. I would have thought that some specific indexes tailored to the queries run would make a big difference. i.e. instead of an index for each foreign key, have an index containing several keys (eg. album _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
