After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 657115 - In Rhythmbox, 10 second gap in playback when unpausing a song on a CIFS share
In Rhythmbox, 10 second gap in playback when unpausing a song on a CIFS share
Status: RESOLVED DUPLICATE of bug 679708
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.x
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-08-22 21:02 UTC by Adam Williamson
Modified: 2012-09-28 16:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Adam Williamson 2011-08-22 21:02:15 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?)
Comment 1 David Schleef 2011-08-27 07:01:01 UTC
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.
Comment 2 Adam Williamson 2011-08-30 00:09:07 UTC
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.
Comment 3 Tim-Philipp Müller 2012-09-28 09:53:15 UTC
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 ***
Comment 4 Adam Williamson 2012-09-28 16:47:30 UTC
Yeah, very likely to be the same thing I think.