You are here: Home » Topic » svn-1303 – thinks it is a new database on startup?

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

FireFly Media Server (formerly mt-daapd) Firefly Media Server Forums Firefly Media Server Nightlies Feedback svn-1303 – thinks it is a new database on startup?

This topic contains 4 replies, has 3 voices, and was last updated by  rpedde 11 years, 3 months ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #433

    Ted Harper
    Participant

    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.

    #5517

    rpedde
    Participant

    @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.

    #5518

    fizze
    Participant

    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.

    #5519

    rpedde
    Participant

    @fizze wrote:

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

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

    #5520

    rpedde
    Participant

    @fizze wrote:

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

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

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.