[vlc-devel] [PATCH] http: Mark the http-reconnect option as plugin-safe
lu_zero at gentoo.org
Sat Sep 26 21:10:56 CEST 2015
On 26/09/15 20:34, Rémi Denis-Courmont wrote:
> Le 2015-09-26 21:16, Luca Barbato a écrit :
>> On 26/09/15 18:57, Rémi Denis-Courmont wrote:
>>> Le 2015-09-26 19:44, Luca Barbato a écrit :
>>>> On 26/09/15 12:34, Rémi Denis-Courmont wrote:
>>>>> TBH, I would much prefer obsoleting the option and reconnecting
>>>>> automatically when appropriate (i.e. connection broken before known
>>>>> of file).
>>>> I might try to find some time to do that later, that would require to:
>>>> - have the fact the connection is broken reported by the lower layer
>>>> - get the expected end of file or know that the file doesn't have an
>>>> In the mean time I'd merge it and get some plugin users happier.
>>>> Would it be ok?
>>> Exposing http-reconnect to playlist and then removing it later is not a
>>> good idea. I am also not convinced that allowing random playlist files
>>> to enable http-reconnect against third party web servers is a good idea
>> I think for the plugin users it makes sense to have it, no matter what,
> The NPAPI plugin is dead. Google killed it. Mozilla is killing it. I
> forget when it last worked with Apple, if ever. Anyone depending on the
> web plugin is running full speed toward a wall of hard concrete that is
> now getting dangerously close. So whitelisting is all about playlist
> files now. Not that it makes much difference though.
> However I don't want to deal with demuxer bugs stemming from unvalidated
> HTTP resumption, or with web server operators annoyed by VLC's
> misbehaviour. The correct way to do with is with If-Match (possibly with
> fallback to If-Not-Modified-Since), not with a user option.
The problem I'm trying to solve is as stupid as it sounds:
- Pause cause the tcp connection to timeout
- Reading from the dead tcp link returns 0 instead of a different error
- the http layer happily takes it as end of file.
- Returning from pause gets you to close vlc.
So far I hadn't tried to figure out if at the tcp level there is a way
to send an error that let me know that http has to reconnect, an
approximation could be something around:
diff --git a/modules/access/http.c b/modules/access/http.c
index ae0f722..1caec1c 100644
@@ -686,7 +686,8 @@ static ssize_t Read( access_t *p_access, uint8_t
*p_buffer, size_t i_len )
p_sys->b_continuous = true;
Disconnect( p_access );
- if( p_sys->b_reconnect )
+ if( p_sys->b_reconnect ||
+ ( p_sys->b_has_size && p_sys->p_sys->i_remaining ))
msg_Dbg( p_access, "got disconnected, trying to reconnect" );
if( Connect( p_access, p_sys->offset ) )
@@ -695,9 +696,13 @@ static ssize_t Read( access_t *p_access, uint8_t
*p_buffer, size_t i_len )
+ int reconnect = p_sys->b_reconnect;
+ int has_size = p_sys->b_has_size;
p_sys->b_reconnect = false;
+ p_sys->b_has_size = false;
i_read = Read( p_access, p_buffer, i_len );
- p_sys->b_reconnect = true;
+ p_sys->b_reconnect = reconnect;
+ p_sys->b_has_size = has_size;
Works just if the file size is known but is better than the current
situation and shouldn't cause problems that I can see.
More information about the vlc-devel