[vlc-devel] "Race condition" in livehttp module

[Enrique Arizón Benito]

Hi again,

if I'm not wrong I think the proposed patch for
modules/access_output/livehttp.c will fix it.

Just Changing "1" -> "3"  will keep it for n+2 updates, just in case there
is something wrong with the network, (which is not so unusual for mobile
devices)


532c532
<     if ( p_sys->b_delsegs && i_firstseg > 1 )
---
>     if ( p_sys->b_delsegs && i_firstseg > 3 )
534c534
<         char *psz_name = formatSegmentPath( p_access->psz_path,
i_firstseg-1, true );
---
>         char *psz_name = formatSegmentPath( p_access->psz_path,
i_firstseg-3, true );

Regards

Enrique



P.S.: I'm don't really know what's the best procedure to report bugs like
this that require just small fixes in code.
 - Send it to the dev list?
 - Submit a bug repport?
 - Writting a mail to the last person I found working on this module
(according to git log it figures Ilkka Ollakka) ?



> On Thu Jun 13 14:27:45 CEST 2013, Rob Jonson <rob at hobbyistsoftware.com>
wrote:
> Hi Enrique,
>
> it looks like the issue here is that VLC isn't fully implementing the spec
> on sliding playlists
>
> http://tools.ietf.org/html/draft-pantos-http-live-streaming-07#page-19
>
> specifically
>
> ---
>
>    When the server removes a media URI from the Playlist, the
>    corresponding media segment SHOULD remain available to clients for a
>    period of time equal to the duration of the segment plus the duration
>    of the longest Playlist file distributed by the server containing
>    that segment.
>
> ---
>
>
> given this, I think the fix would be to keep the segment for n+1 updates
> where n is the number of segments retained in the window.
>
> cheers,
>
> Rob

> > On Thu, Jun 13, 2013 at 9:09 AM, Enrique Arizón Benito <
enrique.arizonbenito at gmail.com> wrote:
> > Hello,
> >
> > For an small project I'm developping an livehttp server based on
vlc+livehttp and a web server (Apache).
> >
> > The livehttp module works properly but when I add the delsegs option to
remove old segment next random raise condition sequence of events arise:
> >
> > Note:
> >
> > 1.- Clients requests index.m3u8 index file to apache
> > 2.- web-server sends back the index.m3u8 index file to the client
> > 3.- Client reads the m3u8 and parses it.
> > 4.- livehttp creates a new ts segment, updates the index.m3u8 index and
removes the oldest existing fragment.
> > 5.- Client request to the web-server the first ts fragment it founds
after parsing (this fragment has just been removed in step 4)
> > 6.- web-server returns a 404-Not Found error.
> >
> > I think a simple patch in modules/access_output/livehttp.c like the
next one will fix the error.
> > The two oldest files will not be removed inmediatly but just after two
other updates:
> >
> > 532c532
> > <     if ( p_sys->b_delsegs && i_firstseg > 1 )
> > ---
> > >     if ( p_sys->b_delsegs && i_firstseg > 3 )
> > 534c534
> > <         char *psz_name = formatSegmentPath( p_access->psz_path,
i_firstseg-1, true );
> > ---
> > >         char *psz_name = formatSegmentPath( p_access->psz_path,
i_firstseg-3, true );
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20130613/fa63fc3c/attachment.html>