- This topic has 5 replies, 2 voices, and was last updated 15 years, 10 months ago by
.
-
Posts
-
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
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 8Also 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
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.Thanks for the response.
Sqlite2 ?? I’m note quite sure where you saw that but this is what LDD sees:
ldd `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-daapdfile /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
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 runningWhat 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.5I 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
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.
- The forum ‘Nightlies Feedback’ is closed to new topics and replies.