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): rhythmbox-0.8.5-0.1.fc2.fr How reproducible: 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! :) Actual results: rythmbox crashed Expected results: 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.