Bug 172517

Summary: rhythmbox skipping with large disk I/O
Product: [Fedora] Fedora Reporter: Hal Canary <halcanary>
Component: rhythmboxAssignee: Alexander Larsson <alexl>
Status: CLOSED INSUFFICIENT_DATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: brian, felix.schwarz
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-01-23 11:05:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Hal Canary 2005-11-05 20:31:37 UTC 
Background:

$ cat /proc/version
Linux version 2.6.13-1.1532_FC4 (bhcompile.redhat.com) (gcc version
4.0.1 20050727 (Red Hat 4.0.1-5)) #1 Thu Oct 20 01:30:08 EDT 2005
$ cat /proc/cpuinfo | grep name
model name      : AMD Athlon(tm) XP 2200+
$ rpm -q rhythmbox
rhythmbox-0.8.8-2

Description of problem:

If I'm doing a large about of disk I/O (e.g. copying files from CD-ROM to the
HDD) while playing mp3s under rhythmbox, rhythmbox will begin skipping.  Other
programs, such as mplayer, don't have this problem.

How reproducible:

Most of the time.
Comment 1 Felix Schwarz 2005-11-06 19:56:26 UTC 
I can see this problem, too. Additionally rhythmbox will hang after it skipped
through the whole song - the application does not react on any events (mouse
clicks for example) any more.

I can reproduce this behavior if I force Linux to swap (e.g. using VMware with
the guest OS using much RAM).

fs
Comment 2 Brian Fahrlander 2005-11-22 04:08:31 UTC 
Same problem here.  This is new as of the last couple of kernel versions- never
saw it before.  I'll bet it's something in the underlying gstreamer code...and
could it be a matter of scheduler preferences?

I've not looked at the code, but my instincts tell me it might be the
culprit...unless we're using the same schedulers by default as we always have. 
I also have 3-second lockups while doing UnrealTournament, Quake, etc- that
seems to coincide with disk I/O, but I have no proof.

I'm open to provide a test system (mine); I can't help much in terms of
programming, though, sorry.  :(
Comment 3 Hal Canary 2006-06-25 16:42:05 UTC 
I have not had this problem for a while.  Either:

1) I have not been using my system in such a way as to trigger the bug

or

2) Something has been fixed in a patch.
Comment 4 Felix Schwarz 2006-08-08 19:41:27 UTC 
Still seeing this problem although not as often as it used to be.
Comment 5 Christian Iseli 2007-01-22 10:38:25 UTC 
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.
Comment 6 Brian Fahrlander 2007-01-23 02:02:09 UTC 
Nope, just close it.  Redhat's "business decision" to let OpenLdap rot on the
vine because they were working on a huge beast to replace it, clinched it for
me. I've been running Ubuntu Dapper for over a year now, and am converting all
the business machines that way, too.  'Cause that's my business decision; sorry.
Comment 7 Brian Fahrlander 2007-01-23 02:17:44 UTC 
Nope, just close it.  Redhat's "business decision" to let OpenLdap rot on the
vine because they were working on a huge beast to replace it, clinched it for
me. I've been running Ubuntu Dapper for over a year now, and am converting all
the business machines that way, too.  'Cause that's my business decision; sorry.