svn-1696 crashed on nslu2

@fizze wrote:

I updated very recently to 1696, and tried to access it thru the soundbridge for the first time just now.
I am copying some files over to the slug, but have been able to access firefly through the SB after a few attempts, normally.
I have nice’d all mt-daaps to -5.

Well I’ve tried maybe for 15 times now to browse artists, and it always timed out. Finally mt-daapd crashed.

As im on standard debuglevel, this is all thats in the logs:

Nov 25 11:03:52 mt-daapd[6799]: Rendezvous socket closed (daap server crashed?) Aborting.

I guess I can reproduce this with -d9, if necessary.

I think again this is the db stuff. There are some issues there. I was going to blow off trying to find this race as most of the db stuff is in the process of being re-written.

I have the db all refactored right now. Most of it is still stubbed out, but it’s refactored in the way I want it to be. It even compiles and runs, although the db enumeration and add/delete functions are stubbed out. I figure I still have 20-30 hours to get the db running again. 10 more to get persistent file-based playlists working, and another 20 or so for a gdbm backend.

Then it’s bug squashing for a stable.

— Ron

@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

@fizze wrote:

Yeah DB-Threading can be messy. Be glad you don’t have to deal with distributed transactions 😉

Ah, thanks for the sqlite3 hint. Now I can switch back and forth between DB backends and crunch some numbers. 🙂

threadsafe db would make it a lot easier. 🙂

@fizze wrote:

Ok I am just giving up on 1696 with sqlite2.
It crashes on every rescan, which is just horrible.
Plus the log doesn’t give any hints.

I think I get a glimpse of your work, Ron. 😕

I hope sqlite3 is more stable. 🙄

edit:
Hm the sqlite .dump worked like a charm. Sqlite3 seems a lot snappier on the slug 🙂

I got a minor thing though:
I just ripped and placed a new album on the slug. It is in the db since today and I c an play it just fine. However, I have a smart playlist thats like this

time_added after 2 weeks before today

and it does have a few other recently added songs, but not this particuliar album.

What’s the catch?

Should go. :/

What does sqlite say the time_added is for those songs in the db?

@fizze wrote:

Oh and if anyone’s ever complaining to me about Oracle and date / time formatting, I will graciously show them sqlite’s date functions 🙂 😆

Tell me about it 🙄