svn-1303 – thinks it is a new database on startup?

[Ted Harper]

I just updated my NSLU2 from svn-1281 to svn-1303, and I noticed on startup that it incorrectly(?) logged that it was starting a new database, because it couldn’t get the database version viz:

2006-07-13 19:19:01 (00000400): Starting with debuglevel 2

2006-07-13 19:19:01 (00000400): Starting rendezvous daemon

2006-07-13 19:19:01 (00000400): Starting signal handler

2006-07-13 19:19:01 (00000402): Signal handler started

2006-07-13 19:19:01 (00000400): Can't get db version. New database?

2006-07-13 19:19:01 (00000400): Initializing database

2006-07-13 19:19:43 (00000400): Starting web server from /opt/share/mt-daapd/admin-root on port 3689

2006-07-13 19:19:43 (00000400): Registering rendezvous names

2006-07-13 19:19:43 (00000400): Serving 5666 songs.  Startup complete in 42 seconds

As you can see, the startup completed – showing the correct number of files – very quickly, so it definitely didn’t start a new database. The library appears to be available and able to be served correctly to my Soundbridge, but I am a bit puzzled by that startup message.

As I said, it was running svn-1281 previously and working fine, and I kept the same config file (answered N to the prompt during the ipkg install), and it definitely seems to be happy, just hopefully a cosmetic issue on startup? Any ideas Ron? Any other NSLU2 people seeing this after the same nightly version update?

ted.h.

[rpedde]

@Ted Harper wrote:

As I said, it was running svn-1281 previously and working fine, and I kept the same config file (answered N to the prompt during the ipkg install), and it definitely seems to be happy, just hopefully a cosmetic issue on startup? Any ideas Ron? Any other NSLU2 people seeing this after the same nightly version update?

yeah, I noticed that too… a bug in the upgrade from db version 9 to db version 10.

You can manually fix it by doing something like:

sqlite /path/to/db

sqlite> insert into config values ('version','','10')

sqlite> .quit

On the next nightly I’ll put defensive code in there for that, didn’t get around to it this version. Probably if there is no version marker it should probably force a full rescan & table creation.

[fizze]

hm I just peeked at db-sql.c in the trunk.

Looks like you handled that thing in
db_sql_open()

still looking weird to me though, being used to PL/SQL and plain C 😉

anyway, I suggest you put a NVL() around

select value from config where term='version'

in
f.i. db_sqlite3_open()
so it would read:

select nvl(value, 0) from config where term='version'

where it would return 0 if the value is null, missing, ^NIL 😉

that would be a proper approach, from the DB side, at least.

[rpedde]

@fizze wrote:

select nvl(value, 0) from config where term='version'

Does sqlite support that? That should be the same as “ifnull”, though, right?

[rpedde]

@fizze wrote:

select nvl(value, 0) from config where term='version'

Does sqlite support that? That should be the same as “ifnull”, though, right?

[Author]

Posts