Bug 78124

Check the CPU time with top and see if it's the "juk" process or the "artsd" process taking up more CPU time.  Also check to see if you're experiencing the same with other KDE players (i.e. Kaboodle).

If you compiled with particularly aggressive optimization flags, you should try a non-optimized compile as well.  Also if you're using a 3rd party widget style those often cause problems, so try things using one of the default styles.

Sorry I am late in responding..I have tried other players..I will try kaboodle when I get back home...It's not a cpu issue..it's fine, everything works well until it plays a corrupt mp3 then it locks up system. The skipping happens randomly even on known perfect mp3s. I am using a widget style that came with kde..I don't remember the name of it. 

I tried to kill artsd and let it respawn itself and it was a little bit better yet it still did it. Don't know if that helps.
Thanks,
Jim Porter
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>       
> http://bugs.kde.org/show_bug.cgi?id=78124      
> wheeler kde org changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>            Severity|crash                       |normal
> 
> 
> 
> ------- Additional Comments From wheeler kde org  2004-03-21 05:19 -------
> Check the CPU time with top and see if it's the "juk" process or the "artsd" 
> process taking up more CPU time.  Also check to see if you're experiencing the 
> same with other KDE players (i.e. Kaboodle).
> 
> If you compiled with particularly aggressive optimization flags, you should try 
> a non-optimized compile as well.  Also if you're using a 3rd party widget style 
> those often cause problems, so try things using one of the default styles.

Any update on this?

sorry.. I have been on vacation and very busy otherwise. 

Portage had a new xmms so i compiled and installed it and tried the update alsa driver it had. It did similar to what juk and artsd was doing, I re-recompiled alsa. I gave it a defenite hardware address in xmms and now it seems to work fine in xmms using the alsa driver and not the esound driver. I will try kde out here in a few minutes and see if it has been resolved now with the new release of alsa. I wonder what in the world esound is, and who makes it....it is the only thing that has worked through all this..thank goodness...I hate being without music!
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>       
> http://bugs.kde.org/show_bug.cgi?id=78124      
> 
> 
> 
> 
> ------- Additional Comments From wheeler kde org  2004-04-04 19:01 -------
> Any update on this?

I have alsa working perfectly now. In xmms, juk kaboodle, etc. the only thing is that when I play that same corrupt mp3 it still locks system completely up. 

Error handling? I don't know if it is my system or that mp3...it doesnt lock system up under other wm's it just freezes xmms.

I think arts might be causing it...I have nforce2 board/sound. Does arts catch all exceptions? anything i can do to try to help debug? As far as I can tell it is nothing in my logs.

Ok, well, at least it's clear at this point that this isn't something JuK specific.  I must say that I'm somewhat tempted to close this as it sounds like a kernel issue, but we'll give it a little longer.  :-)

Can you see if there's any odd process behavior when you're having problems?  Lots of CPU or RAM usage, etc.?

I am almost definite now that this was a kernel/alsa-driver issue. The only thing remaining would be what is causing juk to lock system up. Don't know if it is the song or juk's exception handling...I don't know.. I will look at the process running and crash it again when I get home.

thanks a lot!
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>       
> http://bugs.kde.org/show_bug.cgi?id=78124      
> wheeler kde org changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>          AssignedTo|wheeler kde org             |kde-multimedia kde org
>             Product|juk                         |arts
>             Version|2.0.1                       |unspecified
> 
> 
> 
> ------- Additional Comments From wheeler kde org  2004-04-06 10:05 -------
> Ok, well, at least it's clear at this point that this isn't something JuK 
> specific.  I must say that I'm somewhat tempted to close this as it sounds like 
> a kernel issue, but we'll give it a little longer.  :-)
> 
> Can you see if there's any odd process behavior when you're having problems?  
> Lots of CPU or RAM usage, etc.?

Well, that's the thing -- there's nothing in JuK or Kaboodle or anything else that should be able to freeze the OS.  UNIX just doesn't work that way.  If the application crashes that's one thing, but if the OS crashes, it's an OS issue.

The only real "gray area" is in the case of an application using excessive resources and this causing problems for the OS.  There are ways in the OS of controlling this, but most default desktop system don't use them.

(Also please don't quote the entire bug mail in every reply -- it leads to bug reports with everything repeated several times.)

You a probably using OSS-emulation. The default OSS-driver in aRts doesnt work very well in OSS-emulation. Either use native ALSA or TOSS (Threaded-OSS) drivers in aRts. Since aRts sometimes runs in realtime mode, it has the power to lock up the system if using 100% CPU.

Sorry my e-mail client automagically appends the original message. I have a preempt kernel...I will try it when I get home and watch the resource monitor under gnome or xfce and make xmms crash..see if that will produce anything...the clock colon that normally blinks even stops blinking....It doesnt make any sense. I am pretty sure arts is using the alsa driver..I will double check that as well...I know that xmms is using the alsa output plugin. In fact it is a fresh plugin...that was the only way xmms would use alsa was with the new plugin...before that I had to use esound because the old alsa plugin didnt work.

I don't want to un neccesarily keep the bug open, but while in kde is the only time it completely locks up like that...in other wm's it will just freeze xmms. I will also try that song in another player in the other wm's. 

Like I said if there is anything I can do that would help you all...I have a 2.6.4 kernel and an asus nforce2 board...my sound works perfect in windoze..it works perfect under the other wm's as well with the alsa plugin.

I just compiled and installed linux-2.6.5-gentoo , and it seems to have resolved the problem. I will try it out with juk and let you know. I think this may have been an nforce2 prob that just drove arts up the wall.

Reported as working by the user.

Preempt kernel => Probably running arts (and other sound apps) as RT process (for arts - arts_wrapper as suid root + options in sound system config) => arts going wild on bad data => lockup...

I have a rt_monitor that can detect and reduce priority on offencive processes.
(It does also have a RSS check... Arts uses lots of space for caching - good??)

Yeah that describes my problem... I think that preempt is doing it...I don't think That I have sleep-inside spin locking...or whatever it is called...I will see if that will prevent it. 

I don't know why or how buy when playing media kde will randomly lock system up. The light on the caps lock won't even change. Roger Larsson, what mobo, proc do you have?

I was reading the change log for the 2.6.6 kernel and there is a fix for the nforce2. This is what is in the changelog...I don't know what this means but it very well could be my problem. The only thing that doesnt make sense to me is that only kde causes it to hang. 

<B.Zolnierkiewicz@elka.pw.edu.pl>
	[PATCH] fixup for C1 Halt Disconnect problem on nForce2 chipsets
	
	Based on information provided by "Allen Martin" <AMartin@nvidia.com>:
	
	A hang is caused when the CPU generates a very fast CONNECT/HALT cycle
	sequence.  Workaround is to set the SYSTEM_IDLE_TIMEOUT to 80 ns.
	This allows the state-machine and timer to return to a proper state within
	80 ns of the CONNECT and probe appearing together.  Since the CPU will not
	issue another HALT within 80 ns of the initial HALT, the failure condition
	is avoided.