svn-1696 crashed on nslu2

Viewing 10 posts - 1 through 10 (of 12 total)
  • Author
    Posts
  • #1980
    fizze
    Participant

    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.

    #14676
    rpedde
    Participant

    @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

    #14677
    fizze
    Participant

    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.
    #14678
    rpedde
    Participant

    @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

    #14679
    fizze
    Participant

    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. πŸ™‚

    #14680
    rpedde
    Participant

    @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. πŸ™‚

    #14681
    fizze
    Participant

    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?

    #14682
    rpedde
    Participant

    @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?

    #14683
    fizze
    Participant

    time_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 πŸ™‚ πŸ˜†

    #14684
    sonichouse
    Participant

    @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 πŸ™„

Viewing 10 posts - 1 through 10 (of 12 total)
  • The forum ‘Nightlies Feedback’ is closed to new topics and replies.