You are here: Home » Topic » 1696 on SuSE: Crash after ~45 min

1696 on SuSE: Crash after ~45 min

This topic contains 5 replies, has 2 voices, and was last updated by  fizze 9 years, 5 months ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #2465

    Anonymous

    Hi,

    Build my 1696 on SuSe 10.2 on a 32 bit AMD CPU.

    It starts up fine and runs great for ~45 min. It can serve multiple clients etc etc, but the dies.

    The Startup sequence gives this log:

    2008-05-28 15:28:54 (b7ddb6c0): Firefly Version svn-1696: Starting with debuglevel 6
    2008-05-28 15:28:54 (b7ddb6c0): Loaded plugin /usr/lib/mt-daapd/plugins/out-daap.so (daap/svn-1696)
    2008-05-28 15:28:54 (b7ddb6c0): Loaded plugin /usr/lib/mt-daapd/plugins/ssc-script.so (ssc-script/svn-1696)
    2008-05-28 15:28:54 (b7ddb6c0): Loaded plugin /usr/lib/mt-daapd/plugins/rsp.so (rsp/svn-1696)
    2008-05-28 15:28:54 (b7ddb6c0): Plugin loaded: rsp/svn-1696
    2008-05-28 15:28:54 (b7ddb6c0): Plugin loaded: ssc-script/svn-1696
    2008-05-28 15:28:54 (b7ddb6c0): Plugin loaded: daap/svn-1696
    2008-05-28 15:28:54 (b7ddb6c0): Starting rendezvous daemon
    2008-05-28 15:28:54 (b7ddb6c0): Starting signal handler
    2008-05-28 15:28:54 (b7ddb6c0): Initializing database
    2008-05-28 15:28:54 (b7ddb6c0): Starting web server from /usr/share/mt-daapd/admin-root on port 3689
    2008-05-28 15:28:54 (b7ddb6c0): Listening on port 3689
    2008-05-28 15:28:54 (b7ddb6c0): Starting server thread
    2008-05-28 15:28:54 (b7ddb6c0): Registering rendezvous names
    2008-05-28 15:28:54 (b7ddb6c0): Serving 1069 songs. Startup complete in 0 seconds
    2008-05-28 15:28:54 (b7ddb6c0): Rescanning database
    2008-05-28 15:28:54 (b7ddb6c0): Starting playlist scan
    2008-05-28 15:28:54 (b7ddb6c0): Updating playlists
    2008-05-28 15:28:55 (b7ddb6c0): Scanned 1069 songs (was 1069) in 1 seconds
    2008-05-28 15:28:58 (b7d70b90): Unknown meta code: daap.songalbumartist
    2008-05-28 15:28:58 (b7d70b90): Unknown meta code: com.apple.itunes.has-videodaap.songcategory
    2008-05-28 15:28:58 (b7d70b90): Unknown meta code: daap.songextradata
    2008-05-28 15:28:58 (b7d70b90): Unknown meta code: daap.songcontentdescription
    2008-05-28 15:28:58 (b7d70b90): Unknown meta code: daap.songlongcontentdescription
    2008-05-28 15:28:58 (b7d70b90): Unknown meta code: daap.songkeywords
    2008-05-28 15:28:58 (b7d70b90): Unknown meta code: com.apple.itunes.is-podcast
    2008-05-28 15:28:58 (b7d70b90): Unknown meta code: com.apple.itunes.mediakind
    2008-05-28 15:28:58 (b7d70b90): Unknown meta code: com.apple.itunes.series-name
    2008-05-28 15:28:58 (b7d70b90): Unknown meta code: com.apple.itunes.network-name
    2008-05-28 15:28:58 (b7d70b90): Unknown meta code: com.apple.itunes.episode-num-str
    2008-05-28 15:28:58 (b7d70b90): Unknown meta code: com.apple.itunes.episode-sort
    2008-05-28 15:28:58 (b7d70b90): Unknown meta code: com.apple.itunes.season-num
    2008-05-28 15:28:58 (b7d70b90): Unknown meta code: daap.songgapless
    2008-05-28 15:28:58 (b7d70b90): Unknown meta code: com.apple.itunes.gapless-enc-del
    2008-05-28 15:28:58 (b7d70b90): Unknown meta code: com.apple.itunes.gapless-heur
    2008-05-28 15:28:58 (b7d70b90): Unknown meta code: com.apple.itunes.gapless-enc-dr
    2008-05-28 15:28:58 (b7d70b90): Unknown meta code: com.apple.itunes.gapless-dur
    2008-05-28 15:28:58 (b7d70b90): Unknown meta code: com.apple.itunes.gapless-resy
    2008-05-28 15:28:58 (b7d70b90): Unknown meta code: com.apple.itunes.is-podcast-playlist
    2008-05-28 15:28:58 (b7d70b90): Unknown meta code: com.apple.itunes.special-playlist
    2008-05-28 15:29:08 (b6d6eb90): Session 0: Streaming file ’32 When Doves Cry.mp3′ to 192.168.0.209 (offset 0)

    And when it dies I get:

    2008-05-28 16:48:36 (b6d6eb90): Finished streaming file to remote: 4645512 bytes
    2008-05-28 16:48:46 (b6d6eb90): Session 0: Streaming file ’09 Too Much To Think About.m4a’ to 192.168.0.209 (offset 0)
    2008-05-28 16:49:34 (b7d70b90): Thread 1: could not read: unknown internal error
    2008-05-28 16:49:34 (b6d6eb90): Write error: Connection reset by peer
    2008-05-28 16:49:34 (b6d6eb90): Error copying file to remote…

    I have LOADS of

    2008-05-28 16:49:34 (b7d70b90): timeout in select

    in the log – they clearly provide a clue – but what is the interpretation of this clue ?

    Apologies in advance if this is a FAQ – I have not been able to find the solution to it there.

    /S

    #17082

    Anonymous

    I noted that the daemon is still running:

    nobody 4861 0.0 0.0 3128 808 pts/3 S May28 0:00 /usr/sbin/mt-daapd -c /etc/mt-daapd.conf -d 8
    nobody 4862 0.1 0.1 27952 1832 pts/3 Sl May28 0:43 /usr/sbin/mt-daapd -c /etc/mt-daapd.conf -d 8

    Also in the web interface the Bonjour service is indicated to be down. When I first installed Firefly I turned off my standard Suse mdns service.

    Could it be the fact that the Rendevouz is not running that causes this problem. Just seems like a VERY long timeout.

    /S

    #17083

    fizze
    Participant

    First of all I suggest you change your database to sqlite3, instead of sqlite2. There is a bug in svn1969 with locks and transactions in 1696 that manifests itself in sqlite2, but not in sqlite3.

    This may really be the case. About the rendezvous / avahi / mDNS stuff, just make sure you compiled firefly with the right options. (Or get the right RPM, that is)
    You can try to register it with the normal mDNS responder, and then disable the internal mDNS responder with a command line switch. Maybe that helps.

    #17084

    Anonymous

    Thanks for the response.

    Sqlite2 ?? I’m note quite sure where you saw that but this is what LDD sees:
    l

    dd `which mt-daapd`
    linux-gate.so.1 => (0xffffe000)
    libdl.so.2 => /lib/libdl.so.2 (0xb7f87000)
    libpthread.so.0 => /lib/libpthread.so.0 (0xb7f6f000)
    libid3tag.so.0 => /usr/local/lib/libid3tag.so.0 (0xb7f5e000)
    libz.so.1 => /lib/libz.so.1 (0xb7f4b000)
    libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0xb7ef0000)
    libc.so.6 => /lib/libc.so.6 (0xb7dc2000)
    /lib/ld-linux.so.2 (0xb7fbb000)

    grep db_ /etc/mt-daapd.conf
    # db_type (required)
    db_type = sqlite3
    # db_parms
    db_parms = /usr/var/cache/mt-daapd

    file /usr/var/cache/mt-daapd/*
    /usr/var/cache/mt-daapd/songs3.db: SQLite database (Version 3)

    I’m trying with Debug=9 to see what is happening to the system when the server dies.

    Any other suggestions ?

    /S

    #17085

    Anonymous

    Ran the test again but this time with debug=9. Very big file.

    Something seems interesting:

    2008-05-29 19:21:34 (b6d01b90): With thread 1 exiting, 1 are still running
    2008-05-29 19:25:57 (b6500b90): With thread 3 exiting, 2 are still running
    2008-05-29 19:25:57 (b6500b90): With thread 4 exiting, 2 are still running
    2008-05-29 19:25:57 (b6500b90): With thread 5 exiting, 2 are still running
    2008-05-29 19:25:57 (b6500b90): With thread 6 exiting, 2 are still running
    2008-05-29 19:25:57 (b6500b90): With thread 7 exiting, 2 are still running
    2008-05-29 19:25:57 (b6500b90): With thread 8 exiting, 2 are still running
    2008-05-29 19:25:57 (b6500b90): With thread 9 exiting, 2 are still running
    2008-05-29 19:25:57 (b6500b90): With thread 10 exiting, 2 are still running
    2008-05-29 19:25:57 (b6500b90): With thread 11 exiting, 3 are still running
    2008-05-29 19:25:57 (b5cffb90): With thread 12 exiting, 2 are still running
    2008-05-29 19:25:57 (b5cffb90): With thread 13 exiting, 2 are still running
    2008-05-29 19:26:01 (b5cffb90): With thread 14 exiting, 2 are still running
    2008-05-29 19:26:02 (b5cffb90): With thread 15 exiting, 2 are still running
    2008-05-29 19:26:02 (b5cffb90): With thread 16 exiting, 2 are still running
    2008-05-29 19:26:02 (b5cffb90): With thread 17 exiting, 2 are still running
    2008-05-29 19:26:02 (b5cffb90): With thread 18 exiting, 2 are still running
    2008-05-29 19:26:02 (b5cffb90): With thread 19 exiting, 2 are still running
    2008-05-29 19:26:02 (b5cffb90): With thread 20 exiting, 2 are still running
    2008-05-29 19:26:02 (b5cffb90): With thread 21 exiting, 2 are still running
    2008-05-29 19:26:02 (b5cffb90): With thread 22 exiting, 2 are still running
    2008-05-29 19:26:02 (b5cffb90): With thread 23 exiting, 2 are still running
    2008-05-29 19:26:02 (b5cffb90): With thread 24 exiting, 2 are still running
    2008-05-29 19:26:02 (b5cffb90): With thread 25 exiting, 2 are still running
    2008-05-29 19:26:02 (b5cffb90): With thread 26 exiting, 2 are still running
    2008-05-29 19:26:02 (b5cffb90): With thread 27 exiting, 2 are still running
    2008-05-29 19:26:02 (b5cffb90): With thread 28 exiting, 3 are still running
    2008-05-29 19:26:02 (b6500b90): With thread 29 exiting, 2 are still running
    2008-05-29 19:26:02 (b6500b90): With thread 30 exiting, 2 are still running
    2008-05-29 19:26:02 (b6500b90): With thread 31 exiting, 2 are still running
    2008-05-29 19:26:02 (b6500b90): With thread 32 exiting, 2 are still running
    2008-05-29 19:31:18 (b6d01b90): With thread 2 exiting, 1 are still running
    2008-05-29 19:31:25 (b6d01b90): With thread 33 exiting, 1 are still running
    2008-05-29 19:31:28 (b6d01b90): With thread 34 exiting, 1 are still running
    2008-05-29 19:33:25 (b6d01b90): With thread 35 exiting, 1 are still running
    2008-05-29 19:37:01 (b6d01b90): With thread 36 exiting, 1 are still running
    2008-05-29 19:40:43 (b6d01b90): With thread 37 exiting, 1 are still running
    2008-05-29 19:44:45 (b6d01b90): With thread 38 exiting, 1 are still running
    2008-05-29 19:48:19 (b6d01b90): With thread 39 exiting, 1 are still running
    2008-05-29 19:50:28 (b6d01b90): With thread 40 exiting, 1 are still running
    2008-05-29 19:54:02 (b6d01b90): With thread 41 exiting, 1 are still running
    2008-05-29 19:58:21 (b6d01b90): With thread 42 exiting, 1 are still running
    2008-05-29 20:00:54 (b6d01b90): With thread 43 exiting, 1 are still running
    2008-05-29 20:04:07 (b6d01b90): With thread 44 exiting, 1 are still running
    2008-05-29 20:08:10 (b6d01b90): With thread 45 exiting, 1 are still running
    2008-05-29 20:10:45 (b6d01b90): With thread 46 exiting, 1 are still running
    2008-05-29 20:13:51 (b6d01b90): With thread 47 exiting, 1 are still running
    2008-05-29 20:17:33 (b6d01b90): With thread 48 exiting, 1 are still running
    2008-05-29 20:19:56 (b6d01b90): With thread 49 exiting, 1 are still running
    2008-05-29 20:22:44 (b6d01b90): With thread 50 exiting, 1 are still running
    2008-05-29 20:26:34 (b6d01b90): With thread 51 exiting, 1 are still running
    2008-05-29 20:28:50 (b7d03b90): With thread 0 exiting, 1 are still running
    2008-05-29 20:28:51 (b6d01b90): With thread 52 exiting, 0 are still running

    What is happening in the treads that stops – in particular 0 and 2. And what is causing them to stop. Are we having the same treads compatibility problem that the Ascent server has.

    I’m using this ptreads library:

    getconf GNU_LIBPTHREAD_VERSION
    NPTL 2.5

    I noted that on some of my newer machines the pthreads library is 2.6.1. I’ll rebuild and move some content there to test on such a pthreads library.
    What library has worked for other users ?

    /S

    #17086

    fizze
    Participant

    Ah I can see you are a knowledgeable guy alright 😉
    With Sqlite3 you should eb on the safe side.

    On slower machines there have been problems noticed when running in debuglevel 9 with pthreads exiting.

    As your library consists of about 1000 songs, thats surely no problem. I’ve seen databases of 40K songs on embedded devices running smoothly. So you maybe right about suspecting the pthreads library.

    I don’t know which particuliar pthreads version I’m running on my slug though, since there’s no getconf available.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.