Red Hat Bugzilla – Bug 131710
Rythmbox don't handle it when things go wrong with NFS
Last modified: 2007-11-30 17:10:48 EST
Description of problem:
Personally i store all my music on my "big" computer - but
occessionally, i want to listen to it when i take my laptop with me
into the living room, and maybe connect it to the big stereo.
The problem is, that in order to do this, I share my home folder over
NFS, and then mount it on my laptop over the wireless network. (yes i
know it is a securitywise sucky solution. Dont tell me.)
But when i for some stupid reason managed to do an "ifdown eth1"
(which is my wlan card), whithout unmounting the nfs-drive OR stopping
rythmbox, rythmbox didn't like it.
What happened was that it played until the buffer was empty, and
then... continue to play (the bar continued forward and the secound
continued to tick). When i tried to press "pause" (in lack of a
"stop"), it didn't react. Only way it stopped was when gnome detected
that i had pushing the "upper rigth corner X", and that the app didn't
react, and asked me to kill it. I answered "yes".
Version-Release number of selected component (if applicable):
Haven't tried. My laptop crashed (full freeze) in the progress (hmm...
beta wlan driver is a bit buggy still) - so i wont try either. At
least not with the wlan card! :)
rythmbox detecting that "something" is wrong (no fs IO), giving an
error message, and if necessary shutting itself down cleanly.
*no* application handles things cleanly when NFS goes down. It's not
really possible to, since the kernel just blocks your app, the app has
no idea what's going on.
NFS just isn't designed for unreliable networks, it's not a Rhythmbox bug.
Yes, but what if (local) file system I/O is delayed due to heavy load
etc.? Rythmbox should somhow handle that the stream was interupted,
instead of just pretending it is still playing and hanging there. So
it is indeed a rythmbox (or maybe it is due to gstreamer?)
I will reopen the bug report, but if you chose to (once again) close
it, i will not reopen it again.
That's a totally different issue. We have a buffer internally that
should handle disk latency.
But it obiviously gives no sign when the buffer is empty....
I don't know what you mean. The buffer should be filled
automatically. You shouldn't have to know about it.