Bug 172517 - rhythmbox skipping with large disk I/O
rhythmbox skipping with large disk I/O
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: rhythmbox (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Alexander Larsson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-05 15:31 EST by Hal Canary
Modified: 2008-08-02 19:40 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-23 06:05:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hal Canary 2005-11-05 15:31:37 EST
Background:

$ cat /proc/version
Linux version 2.6.13-1.1532_FC4 (bhcompile@tweety.build.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 14:56:26 EST
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-21 23:08:31 EST
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 12:42:05 EDT
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 15:41:27 EDT
Still seeing this problem although not as often as it used to be.
Comment 5 Christian Iseli 2007-01-22 05:38:25 EST
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-22 21:02:09 EST
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-22 21:17:44 EST
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.

Note You need to log in before you can comment on or make changes to this bug.