@fizze wrote:
I’d like to switch to sqlite3 somewhen anyway, but as my DB has some nice use statistics I dont want to lose it. But migrating sqlite2->sqlite3 is something I worry about when they’re stable 🙂
sqlite /path/to/songs.db .dump | sqlite3 /path/to/songs3.db
should do it.
Is there something like a session timeout in mt-daapd? Or can I really spawn unlimited mt-daapd instances with every new query from the same client, if they time out client-wise?
The underlying issue is that you can only have one db access going on at a time. Two threads can’t access the db simultaneously. Somewhere I’m either grabbing a lock too late or forgetting to grab a lock and two threads are accessing the db at once.
Ticks me off, because I added a ton of logging and printed out the source and pored over it one weekend day. Didn’t find squat. I’m probably missing something obvious, but there you go.
In retrospect, I probably should have added code to dump thread backtraces when I get a sqlite threading violation, but didn’t really think of it.
Ah well. It will almost certainly fall out when the new db stuff is in.. the database access is going to be *much* simpler.
— Ron