ERROR GStreamer error: gst-resource-error-quark: Server does not support seeking.

[ser]

With not very stable network, listening to radio gives often:

ERROR GStreamer error: gst-resource-error-quark: Server does not support seeking.

and player stops.

It is very likely it can be fixed with a patch similar to this:

https://github.com/ebruck/radiotray-ng/commit/6bdde39b6043cfe848c42e7f3e83de460a34e974

or this:

https://github.com/clementine-player/Clementine/pull/5923/commits/144ceea72f9257dfca4e98c41a0054b2561325ee

[adamcik]

I think we had a similar bug, or at least discussion as to if we should have "everything" live like the first patch you linked, or of each backend should be able to give hints to audio - so only the stream backend (and other backends that know they are asking for streams) would set it.

But if clemtine's version of recovering from the error is more generic and works without expanding the backend/audio APIs that might be nicer.

Thanks for the links to options for addressing this.

[adamcik]

This might also tie into backends that have short lived auth tokens, i.e. we can't reconnect to them with getting a new URI from the backends.

[kingosticks]

The error recovery there seems to be for quite a specific situation. Adding support for controllably setting is_live would address this issue (by preventing seeking) and also help with the buffering loops we can get into on slow connections. I think it's a case of addressing the problem vs a band-aid fix.

Edit : after thinking about this properly, since this is an error condition, and normally this stream is seekable (and hence isn't technically 'live' ) then the error handling does seem better.

[jodal]

We now have PlaybackProvider.is_live() in the backend API.

@adamcik Should we implement is_live() to always return True for Mopidy-Stream?

[fmarzocca]

This is really annoying, I can't listen to radio streams anymore. Twice a day I have this error:

Jul 1 15:57:03 pab mopidy[3323]: ERROR [MainThread] mopidy.audio.gst GStreamer error: Server does not support seeking.

Once I get this, I have to restart mopidy service. Can't stand anymore....

[ser]

I trashed mopidy in result

[adamcik]

@adamcik Should we implement is_live() to always return True for Mopidy-Stream?

Worth a shot, and if need be we could always add a some config knob for overriding. But better if we can avoid that.

[rkachowski]

This happens regularly for me, I have a pretty decent internet connection. Pausing and restarting the stream seems to work fine. The logs look like below

Jul 20 11:00:08 kitchenpi mopidy[27982]: DEBUG    2020-07-20 11:00:08,407 [27982:MainThread] mopidy.audio.gst
Jul 20 11:00:08 kitchenpi mopidy[27982]:   Got BUFFERING bus message: percent=0%
Jul 20 11:00:08 kitchenpi mopidy[27982]: DEBUG    2020-07-20 11:00:08,416 [27982:MainThread] mopidy.audio.gst
Jul 20 11:00:08 kitchenpi mopidy[27982]:   Got STATE_CHANGED bus message: old=GST_STATE_PLAYING new=GST_STATE_PAUSED pending=GST_STATE_VOID_PENDING
Jul 20 11:00:08 kitchenpi mopidy[27982]: DEBUG    2020-07-20 11:00:08,416 [27982:MainThread] mopidy.audio.actor
Jul 20 11:00:08 kitchenpi mopidy[27982]:   Audio event: state_changed(old_state=playing, new_state=paused, target_state=playing)
Jul 20 11:00:08 kitchenpi mopidy[27982]: DEBUG    2020-07-20 11:00:08,417 [27982:MainThread] mopidy.listener
Jul 20 11:00:08 kitchenpi mopidy[27982]:   Sending state_changed to AudioListener: {'old_state': 'playing', 'new_state': 'paused', 'target_state': 'playing'}
Jul 20 11:00:08 kitchenpi mopidy[27982]: DEBUG    2020-07-20 11:00:08,419 [27982:MainThread] mopidy.audio.gst
Jul 20 11:00:08 kitchenpi mopidy[27982]:   Got ASYNC_DONE bus message.
Jul 20 11:00:17 kitchenpi mopidy[27982]: ERROR    2020-07-20 11:00:17,304 [27982:MainThread] mopidy.audio.gst
Jul 20 11:00:17 kitchenpi mopidy[27982]:   GStreamer error: Server does not support seeking.
Jul 20 11:00:17 kitchenpi mopidy[27982]: DEBUG    2020-07-20 11:00:17,305 [27982:MainThread] mopidy.audio.gst
Jul 20 11:00:17 kitchenpi mopidy[27982]:   Got ERROR bus message: error=GLib.Error('Server does not support seeking.', 'gst-resource-error-quark', 11) debug='gstsouphttpsrc.c(1619): gst_soup_http_src_do_request (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin11/GstSoupHTTPSrc:source:\nServer does not accept Range HTTP header, URL: http://direct.fipradio.fr/live/fip-midfi.mp3?ID=76zqey582k, Redirect to: http://icecast.radiofrance.fr/fip-midfi.mp3?ID=76zqey582k'
Jul 20 11:00:17 kitchenpi mopidy[27982]: DEBUG    2020-07-20 11:00:17,321 [27982:MainThread] mopidy.audio.gst
Jul 20 11:00:17 kitchenpi mopidy[27982]:   Changing state to GST_STATE_NULL: result=GST_STATE_CHANGE_SUCCESS
Jul 20 11:00:36 kitchenpi mopidy[27982]: DEBUG    2020-07-20 11:00:36,616 [27982:HttpServer] mopidy.http.handlers
Jul 20 11:00:36 kitchenpi mopidy[27982]:   Received WebSocket message from 192.168.77.125: '{"method":"core.playback.get_time_position","jsonrpc":"2.0","id":132}'
Jul 20 11:00:36 kitchenpi mopidy[27982]: DEBUG    2020-07-20 11:00:36,621 [27982:Audio-2] mopidy.audio.actor
Jul 20 11:00:36 kitchenpi mopidy[27982]:   Position query failed
Jul 20 11:00:36 kitchenpi mopidy[27982]: DEBUG    2020-07-20 11:00:36,624 [27982:HttpServer] mopidy.http.handlers
Jul 20 11:00:36 kitchenpi mopidy[27982]:   Sent WebSocket message to 192.168.77.125: '{"jsonrpc": "2.0", "id": 132, "result": 0}'
Jul 20 11:00:37 kitchenpi mopidy[27982]: DEBUG    2020-07-20 11:00:37,648 [27982:HttpServer] mopidy.http.handlers
Jul 20 11:00:37 kitchenpi mopidy[27982]:   Received WebSocket message from 192.168.77.125: '{"method":"core.playback.get_time_position","jsonrpc":"2.0","id":133}'

edit: i've monkey patched an extension to set is_live to be true for the backend, and unfortunately the problem still seems to appear. there's some more logs here https://gist.github.com/rkachowski/d8c94182cec51004d6532ca9ee3c52d2

[kingosticks]

In your log that use is_live, at which point did the stream stop playing?

[rkachowski]

Where it says "Server does not support seeking" https://gist.github.com/rkachowski/d8c94182cec51004d6532ca9ee3c52d2#file-mopidy-tunein-logs-L242

The logs show that the next station in the list (fip radio) gets queued up and is attempted to play, but no audio is actually output. Again, manually pausing and playing through the web interface will start audio again.

It seems that setting is_live does not actually prevent gstreamer from seeking. FWIW i'm on the latest gstreamer from the raspbian deps

pi@kitchenpi:~ $ dpkg -l | grep gstreamer
ii  gir1.2-gstreamer-1.0:armhf           1.14.4-1                            armhf        GObject introspection data for the GStreamer library
ii  gstreamer1.0-alsa:armhf              1.14.4-2                            armhf        GStreamer plugin for ALSA
ii  gstreamer1.0-gl:armhf                1.14.4-2                            armhf        GStreamer plugins for GL
ii  gstreamer1.0-plugins-base:armhf      1.14.4-2                            armhf        GStreamer plugins from the "base" set
ii  gstreamer1.0-plugins-good:armhf      1.14.4-1+rpt1                       armhf        GStreamer plugins from the "good" set
ii  gstreamer1.0-plugins-ugly:armhf      1.14.4-1                            armhf        GStreamer plugins from the "ugly" set
ii  gstreamer1.0-pulseaudio:armhf        1.14.4-1+rpt1                       armhf        GStreamer plugin for PulseAudio
ii  gstreamer1.0-tools                   1.14.4-1                            armhf        Tools for use with GStreamer
ii  gstreamer1.0-x:armhf                 1.14.4-2                            armhf        GStreamer plugins for X11 and Pango
ii  libgstreamer-gl1.0-0:armhf           1.14.4-2                            armhf        GStreamer GL libraries
ii  libgstreamer-plugins-base1.0-0:armhf 1.14.4-2                            armhf        GStreamer libraries from the "base" set
ii  libgstreamer1.0-0:armhf              1.14.4-1                            armhf        Core GStreamer libraries and elements

[tatealive]

I am frequently receiving 'mopidy.audio.gst GStreamer error: Server does not support seeking.' error when listening to SomaFM streams via Mopidy-SomaFM, causing the stream to stop. It's my biggest issue with Mopidy at the moment :(

[RomanKotov]

We use mopidy to play an online radio at work, and sometimes it just stops. Usually we load a single radio station in the tracklist and just play it the whole day.

Sometimes it just stops due to the issues with the radio itself, and then needs to be restarted again.

I have implemented a small workaround for it locally, according to the fix (https://github.com/clementine-player/Clementine/pull/5923/files) for a similar issue from https://github.com/clementine-player/Clementine/issues/5116.

It fits my use-case perfectly: only one online radio station in the tracklist. This solution will jump to the next track in the tracklist, but since it is only one, it is restarted/resumed.

So, I located the mopidy installation path locally, and replaced on_error message handler with

    def on_error(self, error, debug):
        gst_logger.error(f"GStreamer error: {error.message}")
        gst_logger.debug(
            f"Got ERROR bus message: error={error!r} debug={debug!r}"
        )

        if error.message in ("Server does not support seeking.", "Internal data stream error."):
            gst_logger.debug("Restarting playback")
            self._audio.pause_playback()
            self._audio.start_playback()   
            return

        # TODO: is this needed?
        self._audio.stop_playback()

After this fix the radio station stop for some seconds and starts playing again, so we don't need to restart the playback manually every time.