GNOME Bugzilla – Bug 330410
disable seek bar when player can't seek
Last modified: 2018-05-24 11:22:39 UTC
Looks like seeking in a track from a RB DAAP share using an iTunes client is not working. The iTunes seek bar changes position but the track just starts again from the beginning.
I have a similar problem, I run a mt-daapd server on a computer that shares all music in my home. In Windows on iTunes I can seek in a song and it starts playing wherever I want it to. In rhythmbox it just jumps back to where it was and nothing happens, maybe the sound skips some but nothing else. I want to be able to seek in songs in rhythmbox too. Please tell me if I should split this in a separate bug.. Using Rhythmbox 0.9.3.1 (Ubuntu Dapper)
Looks like this isn't limited to iTunes clients.
http://mail.gnome.org/archives/rhythmbox-devel/2006-February/msg00181.html
Best I can tell on the RB client side we seem to be requesting the seek on the server properly: Range: bytes=307200- http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35
Well it also looks like the server is responding with the correct offset: Content-Range: bytes 307200-3151196/3151196
Created attachment 68817 [details] [review] fix daap client seeking This removes the evil seeking hacks (with gstreamer 0.10, not 0.8). I haven't tested it with an itunes server, but it works nicely with rhythmbox. With this patch, vorbis seeking doesn't work at all. I'd almost consider this an improvement. MP3 seeking works pretty well. The code in rb_daap_src_getcaps apparently didn't work with 0.8 and isn't necessary with 0.10, so we might as well remove it. Since this removes all the DAAP bits from rb-player-gst.c, with this we could make DAAP a plugin for gstreamer 0.10 builds.
With this patch when I try to play (using RB client) a song on an OS X iTunes server it says: (rhythmbox:6124): Rhythmbox-WARNING **: eos_cb: Unhandled error: Unknown playback error (11:27:03) [0x92adf90] [rb_shell_player_error] rb-shell-player.c:2505: playback error while playing: No URI handler implemented for "daap". (11:27:03) [0x92adf90] [error_cb] rb-shell-player.c:2544: exiting error hander When I try to seek (using OS X iTunes client) an MP3 file on a RB server it doesn't seek but starts the song over.
It seems that sometimes the daap source element doesn't get registered. I had a slight hack for this somewhere (calling rb_daap_src_get_type in the daap source constructor) that fixed it for me.
My itunes client (6.0.5 on OS X) is sending completely bogus range headers when I try seeking when playing from an RB DAAP share. The byte offsets it requests are ludicrously low (541 bytes when seeking to 2:25) so the song plays pretty much from the start. I've checked that we're sending bitrates correctly (and even if we didn't, itunes updates the song information the first time you try to play it). On a brighter note, this patch for RB client seeking works with the itunes daap server (again 6.0.5 on OS X).
Removing our use of chunked transfer encoding fixes the problem.
Created attachment 68989 [details] [review] fix itunes client seeking (mostly) This uses GMappedFile to send local files without chunked encoding so itunes clients can seek properly. Remote files are still sent chunked. Reading whole remote files into memory to support broken clients wastes memory and is probably going to be very slow, so I don't think we should do it.
Looks sane, and seems to work okay here. Using GMappedFile would require bumping our glib dependency up to 2.8.
Committed with some #ifdefs around the GMappedFile stuff.
I've committed the client-side seeking patch. We need to disable seeking when the player backend reports it cannot seek. To do this, the player needs to wait for state changes to finish before returning, so we can do a seeking query immediately afterwards. oggdemux also needs to be fixed to process seeking queries.
The oggdemux issue is bug 350655.
Created attachment 70594 [details] [review] UI patch Disables the seek bar if we won't be able to seek. This won't work reliably until the player backend waits for the pipeline to actually go into PLAYING state before returning from rb_player_gst_play(), since some elements won't have determined whether they can seek by the time we call rb_player_seekable.
Looks fine to me.
OK, committed.
Not sure if this is important, but I get some warnings at runtime with this new patch that's now in CVS: (rhythmbox:8507): Rhythmbox-CRITICAL **: rb_player_gst_seekable: assertion `mp->priv->playbin != NULL' failed (rhythmbox:8507): Rhythmbox-CRITICAL **: rb_player_gst_seekable: assertion `mp->priv->playbin != NULL' failed (rhythmbox:8507): Rhythmbox-CRITICAL **: rb_player_gst_seekable: assertion `mp->priv->playbin != NULL' failed
hmm, perhaps committing that wasn't such a good idea.. I've changed rb_player_gst_seekable to silently return FALSE if there's no playbin, and changed the call to rb_header_set_playing_entry to always pass in TRUE for seekable for now, since it appears to disable seeking for anything other than mp3.
There's code in Totem's GStreamer backend to do this sort of thing pretty reliably.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/144.