GNOME Bugzilla – Bug 657115
In Rhythmbox, 10 second gap in playback when unpausing a song on a CIFS share
Last modified: 2012-09-28 16:47:30 UTC
So, my music library is on a NAS - a DNS-323, to be precise - mounted on my desktop via CIFS (not NFS, due to a DNS-323 bug I won't go into). If I'm playing a song in Rhythmbox, then pause it for quite a long time, when I resume, I won't hear anything and the playback indicator won't move for about ten seconds - but then the song will kick in 10 seconds on from where it was when I paused. So two problems, really: there's a ten second delay in resuming, but that ten seconds is being played 'somewhere', so I don't just have to wait 10 seconds to pick where I left off, I actually lose 10 seconds of the song. Filing against gstreamer as it seems more likely to be in the gstreamer part of the equation than RB, but please move if necessary. Seems to happen whether the song is Vorbis or FLAC. Rhythmbox 2.90.1-11.git20110502.fc16, gstreamer-0.10.35-1.fc16 - current Fedora 16 packages. (yeah, that RB build does look a bit old, doesn't it?)
Does the NAS spin down the drives when it's not in use? That would explain why it takes about 10 seconds -- the drives need to spin up. As for why the audio disappears instead of being delayed, it's because files on disk are expected to be instantaneous, so there's no mechanism to say "there's been a delay", as there would be, say, with an HTTP source. Large delays in file access is pretty uncommon (in general, obviously it can be common in a particular case), and usually just annoying, and also relatively difficult to fix. I'm not certain it's worth it.
no, I turned that option off on the NAS as it tends to cause issues. but the mount is a systemd automount, and I think those get idled; anything I do that accesses the CIFS share tends to take 10 seconds to 'spin up' if I haven't used it for a while, so I think systemd unmounts it and then remounts it while you're not looking. I know it's very squishy to argue about whether something's worth fixing, but I'm sure I can't be the old one using dumb old-school ways to share music rather than shiny shiny new protocols like DAAP which just seem to be far more trouble than they're worth. but ultimately it's up to you whether it's worth the fix, sure.
I think this is very similar to bug #679708, so hope you don't mind if I mark it as duplicate. Basically we treat all local file access as instant, whereas this may not be the case when accessing a network share, then we really want some buffering IMHO. *** This bug has been marked as a duplicate of bug 679708 ***
Yeah, very likely to be the same thing I think.