<div dir="ltr"><span style="font-family:courier new,monospace"><font>Hi again,<br><br>if I'm not wrong I think the proposed patch for modules/access_output/livehttp.c will fix it.<br><br>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)<br>
<br><br>532c532<br>< if ( p_sys->b_delsegs && i_firstseg > 1 )<br>---<br>> if ( p_sys->b_delsegs && i_firstseg > 3 )<br>534c534<br>< char *psz_name = formatSegmentPath( p_access->psz_path, i_firstseg-1, true );<br>
---<br>> char *psz_name = formatSegmentPath( p_access->psz_path, i_firstseg-3, true );<br><br>Regards<br><br>Enrique<br><br><br><br>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.<br>
- Send it to the dev list?<br> - Submit a bug repport?<br> - Writting a mail to the last person I found working on this module (according to git log it figures Ilkka Ollakka) ?<br><br><br></font></span><br><span style="font-family:courier new,monospace"><font><span style="font-family:courier new,monospace"><font>> On Thu Jun 13 14:27:45 CEST 2013, Rob Jonson <<a href="mailto:rob@hobbyistsoftware.com">rob@hobbyistsoftware.com</a>> wrote:</font></span><br>
> Hi Enrique,<br>> <br>> it looks like the issue here is that VLC isn't fully implementing the spec<br>> on sliding playlists<br>> <br>> <a href="http://tools.ietf.org/html/draft-pantos-http-live-streaming-07#page-19">http://tools.ietf.org/html/draft-pantos-http-live-streaming-07#page-19</a><br>
> <br>> specifically<br>> <br>> ---<br>> <br>> When the server removes a media URI from the Playlist, the<br>> corresponding media segment SHOULD remain available to clients for a<br>> period of time equal to the duration of the segment plus the duration<br>
> of the longest Playlist file distributed by the server containing<br>> that segment.<br>> <br>> ---<br>> <br>> <br>> given this, I think the fix would be to keep the segment for n+1 updates<br>
> where n is the number of segments retained in the window.<br>> <br>> cheers,<br>> <br>> Rob<br><br>> > On Thu, Jun 13, 2013 at 9:09 AM, Enrique Arizón Benito <<a href="mailto:enrique.arizonbenito@gmail.com">enrique.arizonbenito@gmail.com</a>> wrote:<br>
> > Hello,<br>> > <br>> > For an small project I'm developping an livehttp server based on vlc+livehttp and a web server (Apache).<br>> > <br>> > The livehttp module works properly but when I add the delsegs option to remove old segment next random raise condition sequence of events arise:<br>
> > <br>> > Note:<br>> > <br>> > 1.- Clients requests index.m3u8 index file to apache<br>> > 2.- web-server sends back the index.m3u8 index file to the client<br>> > 3.- Client reads the m3u8 and parses it.<br>
> > 4.- livehttp creates a new ts segment, updates the index.m3u8 index and removes the oldest existing fragment.<br>> > 5.- Client request to the web-server the first ts fragment it founds after parsing (this fragment has just been removed in step 4)<br>
> > 6.- web-server returns a 404-Not Found error.<br>> > <br>> > I think a simple patch in modules/access_output/livehttp.c like the next one will fix the error.<br>> > The two oldest files will not be removed inmediatly but just after two other updates:<br>
> > <br>> > 532c532<br>> > < if ( p_sys->b_delsegs && i_firstseg > 1 )<br>> > ---<br>> > > if ( p_sys->b_delsegs && i_firstseg > 3 )<br>> > 534c534<br>
> > < char *psz_name = formatSegmentPath( p_access->psz_path, i_firstseg-1, true );<br>> > ---<br>> > > char *psz_name = formatSegmentPath( p_access->psz_path, i_firstseg-3, true );<br>
> > <br>> > </font></span><br></div>