Error handling with playbin in gapless mode

[Robert Tiemann]

Hi!

I am currently struggling with error handling using playbin in gapless
mode, and I hope someone here can help me out on this one. The
GStreamer version is 1.16.2, but upgrading should be possible if
required.

My player maintains a queue of audio URIs to play, and I am using the
"about-to-finish" signal to pull URIs from the queue so to feed them
into playbin by setting the "uri" property.

This is working very well so far, but sometimes one of the URIs fails
to play, either the one which is currently playing (maybe due to some
network failure) or the next one which has already been written to the
"uri" property, but isn't playing yet (might be typefind complaining,
might be a network failure). When an error occurs, I can see a
GST_MESSAGE_ERROR message in the bus message handler which I have
attached to the pipeline via gst_bus_add_watch(), and I'd like to
handle the error so that bad URIs can be skipped.

Now, I cannot seem to find out which URI has caused the error: the one
which is still playing (so I just need to wait for the next URI to
play), or the one which is supposed to be played next (so I need to
pull the next URI from my queue and give it to playbin), or both. My
current approach to this is to keep track of URI states (i.e., was it
handed over to playbin already, did I see some stream state change,
did I see a stream start, possibly more) and some guesswork, but this
seems to be overly complicated and fails to work correctly for certain
cases.

I think I have just missed something here. Is there a reliable way to
map an error message caught in my bus message handler to the URI which
has caused the error? This would simplify things a lot. Or should I do
error handling in a completely different way?

Thank you in advance!

Regards,
Robert
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Tim Müller]

Hi Robert,

> Now, I cannot seem to find out which URI has caused the error: the
> one which is still playing (so I just need to wait for the next URI
> to play), or the one which is supposed to be played next (so I need
> to pull the next URI from my queue and give it to playbin), or both.

Have you tried checking the read-only "current-uri" property?

I think this was the reason it was added originally.

Cheers
 Tim

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Robert Tiemann]

On 1/29/21 12:07 AM, Tim Müller wrote:
> Hi Robert,

Hi!

> Have you tried checking the read-only "current-uri" property?
>
> I think this was the reason it was added originally.

Thank you for your quick answer. Honestly, I didn't expect the
current-uri property to work reliably during error handling, so I am
currently not using it. The documentation of current-uri just says,
"The currently playing uri."

If this is the intended use of current-uri, then I'll rework my error
recovery around that property. A first try confirms that the property
contains the expected URI in case typefind complains about it, so
that's great.

However, in case the URI points to some file:// that does not exist,
the filesrc plugin fails (Resource not found), and current-uri is
NULL. For bad http:// URIs resulting in DNS lookup failures or a 404,
current-uri is good and not NULL. I think that's a bit inconsistent,
but I guess it should be possible to detect this case and handle it
correctly.

A corner case that came to my mind is an ambiguity in case my queue
contains the same URI several times. If it fails while playing, then I
don't know for sure which instance the current-uri refers to
(currently playing or prefetched). Of course, I could just assume that
the URI won't play anyway and remove all instances of that URI from
the queue.

Still, it would be great if it would be possible to associate some ID
with the URI written to the uri property so that this ID could be used
to identify the currently playing instance of the URI, especially in
case of an error, to avoid this ambiguity. There is the current-audio
property, but it seems not to be intended to be used for this (it
always reads as -1 or 0, no matter if or to which value I am setting
it).

Would it be possible to attach such an ID to the stream and to extract
it during error handling?

> Cheers
>   Tim

Best regards,
Robert
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel