Version: (using KDE KDE 3.3.0) Installed from: Gentoo Packages OS: Linux When loading a playlists (.pls) with remote content, from example shoutcast.com, artsd just hangs. Also the sound application hangs. When killing the arts daemon, the sound application does not hang anymore. I tested this with Amarok and Noatun. Try http://www.shoutcast.com/sbin/shoutcast-playlist.pls?rn=5793&file=filename.pls to test for yourself. This bug was introduced with KDE 3.3 RC2. When I play files locally there are no problems. Seems like a serious problem to me.
Sounds like a bug in akodelib. Try to run artsd from the konsole with "artsd -l0" and report what it writes prior to hanging. Also you can make a backtrace by running artsd in gdb and sending it a kill-signal with "killall artsd" when it hangs.
I have run artsd -l0 in gdb with: run exec-file artsd -l0 Loading the remote playlist. After doing a killall -9 artsd ( I had to do -9 ) I did a: (gdb) backtrace No stack. So this was not very helpfull. On the other hand, I have this, while while artsd was running: ---- (gdb) run exec-file artsd -l0 Starting program: /usr/kde/3.3/bin/artsd exec-file artsd -l0 warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. warning: shared library handler failed to enable breakpoint artsd version is 1.3.0 gsl: using Unix98 pthreads directly for mutexes and conditions [artsd: 23717] SoundServerStartup --> got lock autodetecting driver: - toss: 4 - esd: -1 - null: -1 - alsa: 15 - oss: 10 ... which means we'll default to alsa ALSA driver: default buffering: 7 fragments with 1024 bytes (audio latency is 40.6 ms) ALSA lib pcm_hw.c:549:(snd_pcm_hw_start) SNDRV_PCM_IOCTL_START failed: Broken pipe Closing ALSA-driver virtualize StereoVolumeControl ALSA driver: default buffering: 7 fragments with 1024 bytes (audio latency is 40.6 ms) ALSA lib pcm_hw.c:549:(snd_pcm_hw_start) SNDRV_PCM_IOCTL_START failed: Broken pipe audio format is 44100 Hz, 16 bits, 2 channels addDirectory(/usr/kde/3.3/lib/mcop,) addDirectory(/usr/kde/3.3/lib/mcop/Amarok,Amarok) addDirectory(/usr/kde/3.3/lib/mcop/Arts,Arts) addDirectory(/usr/kde/3.3/lib/mcop/Arts/Environment,Arts::Environment) addDirectory(/usr/kde/3.3/lib/mcop/Noatun,Noatun) addDirectory(/home/jeroen/.mcop/trader-cache,) Arts::MidiManager registered successfully. [artsd: 23717] SoundServerStartup <-- released lock UnixManager: got notifyIO socketconnection created, fd = 11 findPort(outleft) have 4 ports done result 74 connect port outleft to left findPort(outright) have 4 ports done result 74 connect port outright to right findPort(outvalue_l) have 6 ports done result 10 connect port outvalue_l to inleft findPort(outvalue_r) have 6 ports done result 10 connect port outvalue_r to inright search streamplayobject, mimetype = audio/x-mp3 creating akodeMPEGPlayObject to play file akode: opening input-stream creating packet receiver Program terminated with signal SIGKILL, Killed. The program no longer exists. ----
I have also run into this bug and can confirm that it exists in RC2.
It works fine here. I still need a better backtrace. The way to produce it is: killall artsd gdb artsd > set args -l0 > r Run the stream in kaboodle or noatun (amarok fucks it up arts on its own, so dont use it for debugging). Then after it locks up do a _normal_ killall artsd (not -9!). This will halt artsd when debugged even if a -9 is normally required. You can then check the different threads with: > info threads and change between them with > thread [number of thread] and generate a backtrace for each. > bt I cannot do anything more with this bug, before I know where to look.
*** This bug has been marked as a duplicate of 87241 ***
I did exactly what you for and again a normal killall artsd was NOT able to kill artsd. A killall -9 did, but with the result I could not make a backtrace :-( : Program terminated with signal SIGKILL, Killed. The program no longer exists. (gdb) (gdb) info threads No registers. (gdb) bt No stack. (gdb) So I reopen this bug, because as also stated by jstuart, it is in RC2 and I see no signs yet this has been resolved in 3.3 final. I also like to tell that this is a killerbug, because people are not able to play radiostreams in KDE. Cheers, Jeroen
It has been resolved in final. I just updated (using SuSE rpm binary) from rc2 to final, and I can confirm that streaming works.
This bug is fixed in the final 3.3. I just tested it and it works. Marking bug closed.