Package: xmms-scrobbler
Severity: normal
Note that I am using xmms-scrobbler 0.3.8.1-4 backported to sarge
using apt-get --build source. Please forward this upstream if
appropriate.
I noticed that top showed "nfsd" taking resources when most systems
should be idle. I traced this down to NFS v2 GETATTR requests that
access /tmp/xmms_USERNAME.0. I straced the xmms binary and it seems
that one thread of xmms loops infinitely issuing the following
fragment of system calls (real username has been replaced with
USERNAME and song being played with OGGFILE):
connect(9, {sa_family=AF_FILE, path="/tmp/xmms_USERNAME.0"}, 110) = 0
write(9, "\1\0\7\0\0\0\0\0", 8) = 8
read(9, "\1\0\0\0\4\0\0\0", 8) = 8
read(9, "\6\0\0\0", 4) = 4
read(9, "\1\0\0\0\0\0\0\0", 8) = 8
close(9) = 0
socket(PF_FILE, SOCK_STREAM, 0) = 9
getuid32() = 500
geteuid32() = 500
setuid32(500) = 0
setreuid32(500, 500)
connect(9, {sa_family=AF_FILE, path="/tmp/xmms_USERNAME.0"}, 110) = 0
write(9, "\1\0\22\0\4\0\0\0", 8) = 8
write(9, "\6\0\0\0", 4) = 4
read(9, "\1\0\0\0M\0\0\0", 8) = 8
read(9, "/home/USERNAME/OGGFILE"..., 77) = 77
read(9, "\1\0\0\0\0\0\0\0", 8) = 8
close(9) = 0
socket(PF_FILE, SOCK_STREAM, 0) = 9
getuid32() = 500
geteuid32() = 500
setuid32(500) = 0
setreuid32(500, 500)
These system calls seem to come from xmms_connect_to_session. I set a
breakpoint to that function and got the following backtrace:
#0 0x400452c8 in xmms_connect_to_session () from /usr/lib/libxmms.so.1
#1 0x400450c7 in xmms_cfg_free () from /usr/lib/libxmms.so.1
#2 0x4004586a in xmms_remote_get_playlist_pos () from /usr/lib/libxmms.so.1
#3 0x408170d7 in ?? () from /usr/lib/xmms/General/libxmms_scrobbler.so
#4 0x00000000 in ?? ()
#5 0x40b00958 in ?? ()
#6 0x40b006d8 in ?? ()
#7 0x40b00010 in ?? ()
#8 0x401fef7e in __pthread_alt_unlock () from /lib/libpthread.so.0
#9 0x40817628 in ?? () from /usr/lib/xmms/General/libxmms_scrobbler.so
#10 0xbf5ffac4 in ?? ()
#11 0xbf5ffaac in ?? ()
#12 0x00000000 in ?? ()
#13 0x00000000 in ?? ()
#14 0x00000000 in ?? ()
#15 0x00000000 in ?? ()
#16 0x40b00668 in ?? ()
#17 0x0000012c in ?? ()
#18 0x00000000 in ?? ()
#19 0x00000000 in ?? ()
#20 0x00000000 in ?? ()
#21 0xbf5ffac4 in ?? ()
#22 0x00000000 in ?? ()
#23 0x00000000 in ?? ()
#24 0x00000000 in ?? ()
---Type <return> to continue, or q <return> to quit---
#25 0x00000000 in ?? ()
#26 0x00000000 in ?? ()
#27 0x00000001 in ?? ()
#28 0x00000000 in ?? ()
#29 0x03938700 in ?? ()
#30 0x00000000 in ?? ()
#31 0x03938700 in ?? ()
#32 0x401fdf9b in thread_self () from /lib/libpthread.so.0
#33 0x401fae51 in pthread_start_thread () from /lib/libpthread.so.0
#34 0x4045292a in lseek64 () from /lib/libc.so.6
In xmms-scrobler xmms_remote_get_playlist_pos is called from
get_song_status. The xs_thread function seems to call get_song_status
every 100ms perhaps this could be changed to configurable option so
that user could choose e.g. 2 second polling interval rather than
100ms polling interval?
Any idea if it is possible to poll xmms status info without generating
extra NFS traffic?
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.4.29sauna
Locale: LANG=C, LC_CTYPE=fi_FI (charmap=ISO-8859-1)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
