Question for those having this issue, does this happen only in LiveTV or in all recordings?<br><br>I've seen this as well, but under different circumstances. I'm running kernel 2.6.18 with slightly newer DVB modules and
ivtv-0.8.2 all with MythTV just before the ffmpeg sync. All this worked quite well until I updated my DVB modules to the latest hg snap after which time I see the same pre-buffer pauses others are seeing. I reverted back to an older DVB hg tree and all is well now.
<br><br>The reason I suspect this MAY be related is that the DVB hg tree includes more than just DVB modules - it also includes media modules used with ivtv, and these modules frequently get sync'ed into newer kernel versions. I suspect we're either looking at a combination of factors or possibly something having nothing to do with the ffmpeg sync at all.
<br><br>- Mark.<br><br><div><span class="gmail_quote">On 8/7/07, <b class="gmail_sendername">Matt</b> <<a href="mailto:skd5aner@gmail.com">skd5aner@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 8/6/07, Anduin Withers <<a href="mailto:awithers@anduin.com">awithers@anduin.com</a>> wrote:<br>> > Since the ffmpeg resync - [13655] - one of my frontends has had issues<br>> > playing back recordings from the PVR150 in the backend. If I roll back to
<br>> > 13654 playback is smooth but on 13655 it's unwatchable (prebuffering<br>> > pauses every 2 seconds or so). This only occurs with recordings from the<br>> > PVR150, playing from the DVB cards is fine.
<br>> [...]<br>> > Ticket URL: <<a href="http://svn.mythtv.org/trac/ticket/3690">http://svn.mythtv.org/trac/ticket/3690</a>><br>><br>> I had one frontend that was hitting this bug and so spent a good chunk of
<br>> yesterday looking in to 3690.<br>><br>> It looks like libavformat/mpeg.c mpegps_read_pes_header line 1446:<br>><br>> url_fseek(&s->pb, last_sync, SEEK_SET);<br>><br>> This will result in calls to RingBuffer::Seek() with seeks to where we are,
<br>> not too bad except for unnecessary things like a potential network call and<br>> worse, a ResetReadAhead call.<br>><br>> For me the difference between unwatchable even at 1x and, as it was back at<br>> 13654, is a check early in RingBuffer::Seek(). My change is to do nothing
<br>> (not literally nothing, return the right values) when SEEK_SET(where we are)<br>> and SEEK_CUR(0).<br>><br>> Does anyone object to this change? (I'll attach the patch to the ticket<br>> later tonight)
<br>><br>> --<br>> Anduin Withers<br>><br>> _______________________________________________<br>> mythtv-dev mailing list<br>> <a href="mailto:mythtv-dev@mythtv.org">mythtv-dev@mythtv.org</a><br>> <a href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev">
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev</a><br>><br><br><br>Anduin... I'll be happy to test a patch to let you know if it<br>addresses my issues! This has probably been one of the very few bugs<br>out there that I've ever experienced in trunk that has cause my myth
<br>system to be completely unusable. Thank you for taking the time to<br>research and address this issue. I see the patch is there now. I<br>don't have time tonight to test, but hopefully can test tomorrow.<br><br>
Thanks!<br>Matt<br>_______________________________________________<br>mythtv-dev mailing list<br><a href="mailto:mythtv-dev@mythtv.org">mythtv-dev@mythtv.org</a><br><a href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev">
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev</a><br></blockquote></div><br>