FireFly Media Server › Firefly Media Server Forums › Firefly Media Server › Nightlies Feedback › svn-1696 crashed on nslu2
- This topic has 11 replies, 3 voices, and was last updated 16 years, 10 months ago by rpedde.
-
AuthorPosts
-
25/11/2007 at 10:09 AM #1980fizzeParticipant
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:
<25>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.
26/11/2007 at 3:50 AM #14676rpeddeParticipant@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
26/11/2007 at 3:51 PM #14677fizzeParticipantWow, 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.
28/11/2007 at 5:09 AM #14678rpeddeParticipant@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
28/11/2007 at 8:04 AM #14679fizzeParticipantYeah 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. π
30/11/2007 at 4:54 AM #14680rpeddeParticipant@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. π
02/12/2007 at 10:07 AM #14681fizzeParticipantOk 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 thistime_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?
02/12/2007 at 11:05 PM #14682rpeddeParticipant@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 thistime_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?
03/12/2007 at 8:51 PM #14683fizzeParticipanttime_added holds the creation time of those files. Now I remember this being present in some earlier versions, but I thought that behaviour fixed?
I see that the db_timestamp holds what I am actually looking for. Am I right?
edit:
Ok, now that smart playlist is more like it π
I wonder why I didn’t notice this earlier. I guess for podcasts the time_added == db_timestamp, more or less.edit2:
Oh and if anyone’s ever complaining to me about Oracle and date / time formatting, I will graciously show them sqlite’s date functions π π04/12/2007 at 2:07 PM #14684sonichouseParticipant@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 π
-
AuthorPosts
- The forum ‘Nightlies Feedback’ is closed to new topics and replies.