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?