SoupHttP source says a media source is seekable but it is not actually

[Arun Raghavan]

On Wed, 11 May 2016, at 07:20 AM, Majaja wrote:
> Hi all:
>  
> I have a problem about the seekable property of an URL for SoupHTTP.
>  
> Please check following link:
>  
> http://itv.mit-xperts.com/hbbtvtest/media/mp3radio.php
> <http://itv.mit-xperts.com/hbbtvtest/media/mp3radio.php>   0511.patch
> <http://gstreamer-devel.966125.n4.nabble.com/file/n4677448/0511.patch>  
>  
> It links to a MP3 file & you can playback it directly on the browser of
> your
> PC.
>  
> However, you can find that SoupHttp will confirm the the link is
> "seekable"
> but once it did seek, the action will fail.
>  
> the log such as "Server does not accept Range HTTP header, URL: 
> http://itv.mit-xperts.com/hbbtvtest/media/mp3radio.php, Redirect to:
> (NULL)"
> appears.
>  
>  
> It means the link in fact is not seekable but currently SoupHTTP fails in
> checking it.
>  
> Is there anyone could comment on why it fails?
>  
> Also, I wonder that if we can check the seekability by actually sending a
> "seek" (byte range request in fact).
>  
> If it successes we will be much more confident in the result. Otherwise,
> the
> seek is unsupported. Currently SoupHttp only checks
> SOUP_ENCODING_CONTENT_LENGTH but it seems to be insufficient...
>  
> I wrote a simple check flow accordingly as the pathc attached.
>  
> Could someone give it a check and leave comments please?

This approach is too specific to your particular use case (also, please
use Bugzilla to submit patches. You can use git bz to make this easier).

You might find the patch on
https://bugzilla.gnome.org/show_bug.cgi?id=658309 to be useful.

-- Arun