Wow, those time estimates are looking promising.
I think I know what I wish for Christmas 😉
Yeah, Im still running on sqlite2, and in the earlier builds this was always stable, even with multiple timeouts. It took a few tries until the niceity kicked in, along with some buffering from sqlite.
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 🙂
Btw I’ve found a couple of mt-daapd processes on the slug, so I think I can see where that race is going.
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?
edit:
you might already have tackled this one..
svn-1691 just crashed nastily once again. I let it do a rescan thru the webinterface whilst browsing to some other artist thru the soundbridge.
Then I was tagging some mp3s, and wanted to do the same thing again. As soon as I hit the “Browse Artists” on the SB again, mt-daapd bailed.
Here’s the last of the log output:
Nov 27 19:32:47 mt-daapd[20591]: Write error: Broken pipe
Nov 27 19:36:31 mt-daapd[17724]: Rescanning database
Nov 27 19:37:00 mt-daapd[20596]: Write error: Broken pipe
Nov 27 19:37:18 mt-daapd[20619]: Write error: Broken pipe
Nov 27 19:37:21 mt-daapd[17723]: Rendezvous socket closed (daap server crashed?) Aborting.