[mythtv] [mythtv-commits] Ticket #3690: Prebuffering pauses with ivtv sinceffmpeg resync

Mark Buechler mark.buechler at gmail.com
Wed Aug 8 16:44:51 UTC 2007


Question for those having this issue, does this happen only in LiveTV or in
all recordings?

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.

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.

- Mark.

On 8/7/07, Matt <skd5aner at gmail.com> wrote:
>
> On 8/6/07, Anduin Withers <awithers at anduin.com> wrote:
> > >  Since the ffmpeg resync - [13655] - one of my frontends has had
> issues
> > >  playing back recordings from the PVR150 in the backend. If I roll
> back to
> > >  13654 playback is smooth but on 13655 it's unwatchable (prebuffering
> > >  pauses every 2 seconds or so). This only occurs with recordings from
> the
> > >  PVR150, playing from the DVB cards is fine.
> > [...]
> > > Ticket URL: <http://svn.mythtv.org/trac/ticket/3690>
> >
> > I had one frontend that was hitting this bug and so spent a good chunk
> of
> > yesterday looking in to 3690.
> >
> > It looks like libavformat/mpeg.c mpegps_read_pes_header line 1446:
> >
> > url_fseek(&s->pb, last_sync, SEEK_SET);
> >
> > This will result in calls to RingBuffer::Seek() with seeks to where we
> are,
> > not too bad except for unnecessary things like a potential network call
> and
> > worse, a ResetReadAhead call.
> >
> > For me the difference between unwatchable even at 1x and, as it was back
> at
> > 13654, is a check early in RingBuffer::Seek(). My change is to do
> nothing
> > (not literally nothing, return the right values) when SEEK_SET(where we
> are)
> > and SEEK_CUR(0).
> >
> > Does anyone object to this change? (I'll attach the patch to the ticket
> > later tonight)
> >
> > --
> > Anduin Withers
> >
> > _______________________________________________
> > mythtv-dev mailing list
> > mythtv-dev at mythtv.org
> > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> >
>
>
> Anduin... I'll be happy to test a patch to let you know if it
> addresses my issues!  This has probably been one of the very few bugs
> out there that I've ever experienced in trunk that has cause my myth
> system to be completely unusable.  Thank you for taking the time to
> research and address this issue.  I see the patch is there now.  I
> don't have time tonight to test, but hopefully can test tomorrow.
>
> Thanks!
> Matt
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20070808/c7ec3854/attachment.htm 


More information about the mythtv-dev mailing list