[Bug 776495] New: Handling GST_RESOURCE_ERROR_NOT_FOUND for a stream

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=776495

            Bug ID: 776495
           Summary: Handling GST_RESOURCE_ERROR_NOT_FOUND for a stream
    Classification: Platform
           Product: GStreamer
           Version: 1.x
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: elboulangero at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Dear Gst,

In the current version of GStreamer, when playing an audio stream, different
error cases lead to the same error:

    GST_RESOURCE_ERROR: GST_RESOURCE_ERROR_NOT_FOUND
    Could not resolve server name.

I identified clearly 2 error cases that lead to this error. I need to
distinguish between these two error cases, and at the moment GStreamer doesn't
provide a reliable way to do this.

----

There are clearly two different error cases that lead to this error message.

1. The network is done. Error reported by gst is as such:

Gst error msg: gst-resource-error-quark:3: Could not resolve server name.
Gst error debug: gstsouphttpsrc.c(1315): gst_soup_http_src_parse_status
(): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstSoupHTTPSrc:source:
Error resolving 'direct.fipradio.fr': Temporary failure in name
resolution (2), URL: http://direct.fipradio.fr/live/fip-midfi.mp3,
Redirect to: (NULL)

2. The server name in the uri is wrong. Error:

Gst error msg: gst-resource-error-quark:3: Could not resolve server name.
Gst error debug: gstsouphttpsrc.c(1315): gst_soup_http_src_parse_status
(): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstSoupHTTPSrc:source:
Error resolving 'direct.fipxxxxx.fr': Name or service not known (2),
URL: http://direct.fipxxxxx.fr/live/fip-midfi.mp3, Redirect to: (NULL)

In the 1st case, I want to keep on retrying, until the network is brought back
up. In the 2nd case, I want to stop and report the error to the user. So I need
to distinguish between these two error cases.

At the moment, the only way to do that would be to parse the debug string,
since it contains the libsoup error string, and this gives me the information I
want, as you can see in the debug messages above.

But parsing the debug string is not reliable, the content might change at any
time.

This has been reported on the mailing list, and to quote Sebastian Dröge:

> There are ways to add additional information to error messages now, which you could use here. Maybe some kind of "try-again" flag.

----

Best regards,

Arnaud

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.