I was wondering if slim's database was versioned, and if that version was increased when changes are made to the schema?
I've noticed after installing various nightlies, even after doing a full rescan, bogus artist, album, track, etc. information is presented. I just ditch the Cache folder and rebuild, but perhaps a more automated, reliable mechanism would result in fewer problems and support requests.
Would it be possible for slim upon start to examine the on-disk database version, compare it with its concept of what the current database should be (similar to linux's symbols for loadable modules), and delete/rebuild a new one if the versions were inconsistent?
Results 1 to 4 of 4
Thread: Is Slim's DB versioned?
-
2005-09-15, 14:13 #1Senior Member
- Join Date
- May 2005
- Location
- In a house
- Posts
- 1,629
Is Slim's DB versioned?
-
2005-09-15, 14:35 #2
Is Slim's DB versioned?
Quoting MrC <MrC.1vf5f2 (AT) no-mx (DOT) forums.slimdevices.com>:
>
> I was wondering if slim's database was versioned, and if that version
> was increased when changes are made to the schema?
it is versioned, and yes it does get incremented. See the SQL directory for the
files involved. On startup, if your DB version does not match what slimserver
expects, the tables are wiped and the sql macros create new tables and start
scanning.
-k
-
2005-09-15, 14:40 #3Senior Member
- Join Date
- Apr 2005
- Location
- Colorado
- Posts
- 10,073
Yes, it is versioned. There's a table named 'metainformation' that contains a 'version' column. Currently it's at version 15 for rev 4303 in the 6.2 trunk.
Originally Posted by MrC
If you're doing a 'clear library', this should be unnecessary. A 'clear library' handles pretty much any problem I've seen, although completely deleting the database might sometimes necessary for severe corruption.I've noticed after installing various nightlies, even after doing a full rescan, bogus artist, album, track, etc. information is presented. I just ditch the Cache folder and rebuild, but perhaps a more automated, reliable mechanism would result in fewer problems and support requests.
One thing I wish somebody would do, though... update the Rescan Music Library scheduler plugin so that it would give the same options as the built-in interactive rescan. Then you'd have the option of doing a 'clear library' when you do your nightly scheduled rescan.
I think it already does this - whenever the schema changes and the version is updated, SlimServer does a rescan upon startup (actually, this is kind of a PITA if you keep up with the nightlies or SVN updates, since the server is pretty much unusable until it completes the rescan).Would it be possible for slim upon start to examine the on-disk database version, compare it with its concept of what the current database should be (similar to linux's symbols for loadable modules), and delete/rebuild a new one if the versions were inconsistent?
-
2005-09-15, 14:53 #4Senior Member
- Join Date
- May 2005
- Location
- In a house
- Posts
- 1,629
Thanks for the replies, all. I figured versioning must be in there. So I'm wondering why, for example, when I installed latest night's nightly (9/15, upgrading from 9/12), many albums had seemingly random artists associated with the band. For example, in Artist View, Coldplay was listed as including artist Horace Silver. I checked all the tags the album, and there was no Horace Silver to be found.
I did see slim rescan the library upon startup. So it seems reasonable to assume either the clear and rebuild did not work as expected, or the logic to cull out artist information and display has trouble. However, after I removed the Cache directory and rescanned again, all artist information was correct. Does that leave us with the conclusion that "stuff", including the DB in the Cache directory is not fully deleted and rebuilt?
I'm not sure what the answer is, but there are certainly signs that something isn't working as expected.

Reply With Quote
