SVN-1450 nslu2 cant open DB

[fizze]

<25>Dec 15 18:00:48 mt-daapd[24522]: Firefly Version svn-1450: Starting with debuglevel 2

<25>Dec 15 18:00:48 mt-daapd[24522]: Starting rendezvous daemon

<25>Dec 15 18:00:48 mt-daapd[24524]: Starting signal handler

<25>Dec 15 18:00:48 mt-daapd[24524]: db_sqlite2_open: unable to open database: /share/hdd/data/.mt-daapd/songs.db (/share/hdd/data/.mt-daapd/songs.db)

<25>Dec 15 18:00:48 mt-daapd[24524]: Error opening db: Misc SQL Error: unable to open database: /share/hdd/data/.mt-daapd/songs.db

<25>Dec 15 18:00:48 mt-daapd[24524]: Stopping signal handler

this is what I get.

Ok, here’S what happened:
I had svn-1400 running for like 44 days on my slug without any incidents.
as I had some problems with tags not updating in a few new tunes, I triggered a full rescan in the webinterface.

It didnt seem to have any effect, so I hit the button again.
Then mt-daapd died gracefully.

Ok, I thought. If its down already I might as well update. So I went and got svn-1450. Installed, and started. It told me something about the DB version not being 13, and upgrading.
somewhen in that upgrade process it claimed that the DB was “full” and died. not gracefully.

My first guess was that the disk was full, but it wasnt. there were about 6MB free on the flash stick, where I unslung to.

I copied the DB to the harddrive, in another attempt to run 1450. 1450 just gives the log output pasted above and dies. also, ungracefully.

I can open the DB in SQLITE though.

sqlite> .databases

seq  name             file

---



0    main             /share/hdd/data/.mt-daapd/songs.db

1    temp             /var/tmp/sqlite_sYoZMNbi6TtSdwI

I guess the temp is some residue from the update process…?
If I were to clean that up, can I just drop it?
I dont wanna lose my DB and all smart playlists if I dont have to.

Anyway, while poking around the DB, you have an index on songs.idx but not on songs.id? hehe 😉

oh, and config.version still has 12, btw.

[rpedde]

@fizze wrote:

Ok, here’S what happened:
I had svn-1400 running for like 44 days on my slug without any incidents.
as I had some problems with tags not updating in a few new tunes, I triggered a full rescan in the webinterface.

It didnt seem to have any effect, so I hit the button again.
Then mt-daapd died gracefully.

I’ve heard this a couple times, but I don’t know where it’s coming from.. something isn’t working on one of the upgrade scripts, but I’m not sure what.

somewhen in that upgrade process it claimed that the DB was “full” and died. not gracefully.

Oops. That’s bad. It can also mean that /tmp doesn’t have enough space. So you need to check both the /tmp volume as well as the db folder.

I guess the temp is some residue from the update process…?
If I were to clean that up, can I just drop it?
I dont wanna lose my DB and all smart playlists if I dont have to.

I’d say yes. It copies the songs table to a tempdb, then changes format, then selects the temp table back in. That’s probably the temp table, so you can whack that, and it should come back with an empty songs table.

You can also start the server with “-r”, and that should drop the tables and erase all playlists (except smart playlists) and build everything from scratch.

Anyway, while poking around the DB, you have an index on songs.idx but not on songs.id? hehe 😉

Primary key integer fields are implemented in the underlying b-tree as the tree key, so they don’t need an index — lookups are already log2(n). It’s a free index. 🙂

Any chance you have logs from the botched upgrade?

[fizze]

hm, not more than the syslog…..

<25>Dec 15 17:39:51 mt-daapd[1998]: Rescanning database

<25>Dec 15 17:40:11 mt-daapd[1997]: Rendezvous socket closed (daap server crash

<25>Dec 15 17:45:14 mt-daapd[24337]: Starting with debuglevel 2

<25>Dec 15 17:45:14 mt-daapd[24337]: Starting rendezvous daemon

<25>Dec 15 17:45:14 mt-daapd[24339]: Starting signal handler

<25>Dec 15 17:45:15 mt-daapd[24339]: Initializing database

<25>Dec 15 17:45:37 mt-daapd[24339]: Query: vacuum

<25>Dec 15 17:45:37 mt-daapd[24339]: Error: disk I/O error

<25>Dec 15 17:45:37 mt-daapd[24338]: Rendezvous socket closed (daap server cras

<25>Dec 15 17:47:17 mt-daapd[24375]: Firefly Version svn-1450: Starting with de

<25>Dec 15 17:47:17 mt-daapd[24375]: Starting rendezvous daemon

<25>Dec 15 17:47:17 mt-daapd[24377]: Starting signal handler

<25>Dec 15 17:47:18 mt-daapd[24377]: Old database version: 12, expecting 13

<25>Dec 15 17:47:18 mt-daapd[24377]: Upgrading db: 12 --> 13

<25>Dec 15 17:47:32 mt-daapd[24377]: Query: create temp table tempsongs as sele

<13>Dec 15 17:47:32   INTEGER DEFAULT 0,    disc            INTEGER DEFAULT 0,

<25>Dec 15 17:47:32 mt-daapd[24377]: Error: database is full

<25>Dec 15 17:47:32 mt-daapd[24377]: Error upgrading db: Misc SQL Error: databa

<25>Dec 15 17:47:32 mt-daapd[24377]: Error opening db: Misc SQL Error: database

I do only have about 4MB space left on my stick though. I desperatley want to unsling to the HD. Did I ever mention I need some vacation? 😉

Alrighty, I’ll try to play with that stuff later this weekend.

edit:
OK, I ran it with my conf file and -r and the output is the same:

<25>Dec 16 09:28:21 mt-daapd[24841]: Starting rendezvous daemon

<25>Dec 16 09:28:21 mt-daapd[24843]: Starting signal handler

<25>Dec 16 09:28:21 mt-daapd[24843]: db_sqlite2_open: unable to open database: /share/hdd/data/.mt-daapd/songs.db (/share/hdd/data/.mt-daapd/songs.db)

<25>Dec 16 09:28:21 mt-daapd[24843]: Error opening db: Misc SQL Error: unable to open database: /share/hdd/data/.mt-daapd/songs.db

<25>Dec 16 09:28:21 mt-daapd[24843]: Stopping signal handler

I’ll just remove the DB and start from scratch.
I dont quite get it because I can get in with sqlite. Prolly you dont properly check any return values from your SQLite routines?

edit:

<25>Dec 16 11:32:52 mt-daapd[24902]: Firefly Version svn-1450: Starting with debuglevel 2

<25>Dec 16 11:32:52 mt-daapd[24902]: Starting rendezvous daemon

<25>Dec 16 11:32:53 mt-daapd[24904]: Starting signal handler

<25>Dec 16 11:32:53 mt-daapd[24904]: Error: enum_begin failed (error 1): Misc SQL Error: no such table: config

<25>Dec 16 11:32:53 mt-daapd[24904]: Can't get db version. New database?

<25>Dec 16 11:32:53 mt-daapd[24904]: Initializing database

<25>Dec 16 11:32:53 mt-daapd[24904]: Error: enum_begin failed (error 1): ?

<25>Dec 16 11:32:53 mt-daapd[24904]: Error: enum_begin failed (error 1): ?

<25>Dec 16 11:32:53 mt-daapd[24904]: Full reload...

<25>Dec 16 11:32:53 mt-daapd[24904]: Starting mp3 scan

Alrighty, there seems to be a permission problem as well.
I had to 777 the DB dir. I had it chown’d to the user mt-daapd runs as first, and hat it set to 700. didnt work. weird.
Next I chown’d it to root:root and it didnt work either. Now with 777 it of course runs.
At what point does mt-daapd revoke its root:root rights and demonizes?
Or am i missing something here?

[rpedde]

@fizze wrote:

<25>Dec 15 17:45:37 mt-daapd[24339]: Query: vacuum
<25>Dec 15 17:45:37 mt-daapd[24339]: Error: disk I/O error

yeah, that’s gotta be out of disk space on the /tmp volume.

Alrighty, there seems to be a permission problem as well.
I had to 777 the DB dir. I had it chown’d to the user mt-daapd runs as first, and hat it set to 700. didnt work. weird.
Next I chown’d it to root:root and it didnt work either. Now with 777 it of course runs.
At what point does mt-daapd revoke its root:root rights and demonizes?
Or am i missing something here?

It does that after it initializes (and upgrades, if necessary) the database. I wonder if the vacuum is leaving a db owned by root and not the runas user. Maybe that’s what’s going on.

[Author]

Posts