After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 163351 - Rhythmbox/Gstreamer stops playing, starts using 100% CPU, and needs to be killed, on some OGG and Flac files.
Rhythmbox/Gstreamer stops playing, starts using 100% CPU, and needs to be kil...
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: dont know
0.8.7
Other All
: High critical
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-01-08 17:45 UTC by Joseph Farmer
Modified: 2005-11-30 10:56 UTC
See Also:
GNOME target: ---
GNOME version: 2.7/2.8



Description Joseph Farmer 2005-01-08 17:45:49 UTC
Steps to reproduce:
1. Wait until Rhythmbox hits one of the Oggs and that's all she wrote.
2. 
3. 


Stack trace:
Don't have.

Other information:
I don't know if this is Rhythmbox or GStreamer related.  I've got about 600 CDs
ripped to FLAC and OGG Vorbis.  I use the Vorbis files in Rhythmbox.  A couple
times of day, the music stops playing and one of two cases will be true:
Case 1.  Processor (P4 HT) will be at 50% (probably due to HT that it isn't
100%) and no music will be playing.  Selecting "Next" in Rhythmbox moves to next
song and all is fine.
Case 2.  This one is almost the same, but with a difference.  Again, music stops
playing.  In this case, CPU is at 100% and Rhythmbox will not respond at all.  I
then kill it and restart it.

I can find which Oggs are doing #1 above pretty easily but case #2 is harder as
the Rhythmbox window will not "repaint" so I can see which song is locked.  I
guess I could leave it running all night with it in the foreground if you'd
like.  I'm perfectly willing to provide an Ogg that causes the problem but you
may not care for the song. ;)
Comment 1 Ronald Bultje 2005-01-08 18:22:28 UTC
Please provide one such ogg and one such flac file for testing. We can arrange
FTP for you if required (ask on IRC).
Comment 2 Joseph Farmer 2005-01-10 01:28:30 UTC
My bad, I sent an email to Ronald with a link to a couple of stack traces and an
ogg vorbis song that is a problem.  The ogg file is too big for bugzilla to
accept as an attachment.  I've got DSL and my address can change, but until it does:
http://216.170.205.75/undun.ogg
Is a file that causes 50% cpu and no play.  The music stops, the rhythmbox time
slider keeps going.  A stack trace of rhythmbox right after it stops playing and
eating CPU is:
http://216.170.205.75/strace.txt
Trace at end of song:
http://216.170.205.75/strace_end.txt

In this particular case, once the song ends, it will keep eating 50% CPU
perpetually.  Putting mouse over the musical note in the panel shows the song is
at 29 minutes of a 3 minute song.  It will keep going until I stop it.

Previous versions of GStreamer/Rhythmbox used to pop up a "lost synch" message
when they hit these songs.

Again, sorry for the noise.  Ronald has screen shots and stack traces and that ogg.

I'll update the bug when it hits one of the song that triggers the other case
(100% CPU).  With stack trace.
Comment 3 Joseph Farmer 2005-01-10 01:30:31 UTC
Added the above as Stephane LOEUILLET changed bug status from UNCONFIRMED to
NEEDINFO.
Comment 4 Ronald Bultje 2005-01-10 09:27:24 UTC
Sorry, forgot to add remark here. I tried the song in Totem and cannot reproduce
anything. Now, this might be related to something Christophe showed me
yesterday... Christophe, could the EOS problem you showed me be related to this,
or doesn't Rhythmbox use that yet?
Comment 5 Ronald Bultje 2005-02-08 17:43:51 UTC
joseph, the songs you gave me do not reproduce the issue. Can you give me
another collection of songs (2-3) that reproduce the issue when those are
together in a playlist? Also, with those songs, does the problem exist only in
rhythmbox or also in other apps (totem)?
Comment 6 Joseph Farmer 2005-06-11 02:24:58 UTC
This was occurring on two different machines.  Both machines have completely
different hardware so it wasn't machine related.  Both machines are on Fedora
Core 3.  About 3 weeks ago the problem changed for the better.  Previously two
situations could occur: 50% CPU but hitting "next" in Rhythmbox would move to
the next song and things would be fine.  In other cases 100% CPU would be seen
and Rhythmbox would be unresponsive and it would have to be killed.  Both
machines do "autoupdate" via YUM and something changed.  Now there is only one
situation:  100% CPU but hitting "next" moves to the next song and CPU goes back
to normal.  This is perfectly acceptable behaviour for flaky oggs and flacs. 
Some of the CDs were scratched and I've noticed it's generally oggs and flacs
from them CDs.  Not having to "kill" Rhythmbox is much better.  It's likely that
the change from from 50% to 100% cpu is because the machine started in non-smp
mode (Hyperthreading).  I'll boot to smp this weekend and see if that is the
case.  The machine has not locked up Rhythmbox in 3 weeks now.  That is a big
change as it would lock up Rhythmbox daily before.

As it currently exists it's no longer a bug to me.  Having to kill Rhythmbox
when it hit bad Oggs was a bug.  Just having to "next" past them if fine.

Cheers. 
Comment 7 Joseph Farmer 2005-11-26 18:50:35 UTC
It's back.  With an interesting data point.  The problem completely disappeared
and I thought maybe an update fixed it.  On that I was correct but it wasn't an
update to either GStreamer or Rhythmbox.  I had the machine running an SMP
kernel (it has hyperthreading).  When it automatically downloaded a new kernel
it set priority to booting the non-SMP kernel.  I've been running non-SMP for
some months and not had any problems.  I switched grub to boot SMP yesterday and
the problem came back.  So the problem only exists when one is running the smp
kernels.

For now I've switched back to non-SMP.
Comment 8 Andy Wingo 2005-11-30 10:56:53 UTC
Very interesting. Well I would suggest that GStreamer 0.8 has known threading
issues, and that all kinds of issues could cause the timings to work out so that
it sucks, especially if the pipeline errored out very quickly after going to
PLAYING.

GStreamer 0.10 (to be released in... 5 days!) does a *lot* better with
threading. I'm closing this bug as obsolete, because there's really nothing we
can do to fix this problem on 0.8, but on 0.10 it should work fine.