Version: 2.3.3 (using KDE 3.1.92 (CVS >= 20031007), compiled sources) Compiler: gcc version 3.3.2 20030908 (Debian prerelease) OS: Linux (i686) release 2.4.21-xfs While playing mp3s from noatun, any other disk/cpu-intensive process will not only interrupt playback (which may be regarded natural if it's beyond the capability of OS to switch back in time), but it will also halt the playback completely, say "cannot connect to arts server" etc. etc., usually followed by noatun crashing or exiting silently. Which I find highly annoying. Has anybody else has seen this behavior? It shouldn't be this difficult to play an mp3.
Artsd crashing has little to do with noatun. Also I'm pretty sure your artsd is badly configured (yes, it's a bitch to make it run well) or your compiler optimizations break artsd. Also with so little information I doubt anybody can find the cause for this, maybe try attaching gdb to artsd processes and optionally to noatun as well in case it crashes.
Subject: Re: New: arts usage is highly unreliable and causes crashes in noatun I encounter part of this "bug" every time I compile and listen to music the same time. Its because the system (hardware) is to slow or the cpu has to do a lot of work from the ide-controller (the case on most laptops - its the disadvantage of all-in-one-chips). I never encountered crashes of arts due to this and unless you can provide a backtrace leading to faults in arts, I would blame an unstable system for this. Last but not least: If noatun uses arts and is uncapable of handling a crash of arts, its a bug in noatun. As this is a very unspecific bug entry (if it is a bug at all) I would like to close it... Arnold
increasing buffersize inside mpeglib code (for mp3 playback), chrooting artswrapper and thus allowing artsd realtime-priority improves the skipping A LOT! About the bug itself: I need a backtrace of noatun crashing (including debugsymbols), maybe I can fix it then, Charles prolly can't fix it right now.
okay, the crashes I saw may have been due to some other failure. the problem is probably about communication of arts server and application programs. for the experiment, i am not setting artswrapper as SUID. i launch a normal, plain, innocent mp3 file with kaboodle. then after playback starts i switch around the desktops which needs some cpu/disk time. kaboodle exits silently in the middle of the playback. with noatun, i select split playlist (mostly believed to be bug-free). I jump around the desktops, playback stops. i would expect that the playback didn't stop. normally many media players continue playback in such cases. maybe, if it wasn't possible to play back for 10 seconds, a player could show an info box and paused the playback. that's the bug. thanks for your comments.
I neglected to say that exactly the same behavior can be observed when the arts is *set* SUID. In fact, I was using arts like that when I had reported the bug. I set realtime priority and a buffersize of 139 milliseconds which I find extremely long. Again the silent stop/exit behavior is observed
Even with artswrapper set SUID, realtime priority set, and the buffersize set to the maximum, I still can reproduce this problem on my P4/1Gb RAM, most easily by typing 'make install' for some application.
Doesn't happen for me though. BUT: I can trigger an artsd crash if I use noatun and at the same time two messages arrive in Kopete resulting in yet another two sounds at the same time. Also artsplay used in my xchat can trigger the same crash. If I have enough time and don't forget about it you might see a backtrace being attached to this bugreport :)
Hello there, Sorry for not being able to provide a BT of crashes right now. I hope metz will get you some. This bug seems to involve both client and server code so it might be quite involved. My point would be that silent exit/stop/crash should not happen even when artswrapper is not set. Remember, the rival media player applications are not set SUID. It's illogical to require something as simple as a component of a media player to have such requirement to work reasonably (if not perfectly) at alll. Thanks a lot for your attention. Regards,
I have a problem with artsd: 0x4059ea86 in waitpid () from /lib/i686/libpthread.so.0 #0 0x4059ea86 in waitpid () from /lib/i686/libpthread.so.0 #1 0x080625c8 in Arts::CrashHandler::defaultCrashHandler(int) () #2 0x4059d96c in __pthread_sighandler () from /lib/i686/libpthread.so.0 #3 <signal handler called>
amarock player are crashing , but i m'ot playing mp3 files, i'm playing ogg files. thank you for your answer.
Arts is no longer developed and has been unmaintained for quite some time - more than 2 years. With phonon as the replacement for arts in KDE4, we're closing out all the arts bugs in Bugzilla since there is no chance of them being fixed. Thanks