[mythtv] Ticket #2340: "Error was encountered while displaying video" while watching livetv

Bradley Kite bradley.kite at gmail.com
Wed Sep 13 15:02:41 UTC 2006


On 12/09/06, Bradley Kite <bradley.kite at gmail.com> wrote:
>
>
>
> On 12/09/06, Bradley Kite <bradley.kite at gmail.com> wrote:
> >
> >
> >
> > On 10/09/06, MythTV < mythtv at cvs.mythtv.org> wrote:
> > >
> > > #2340: "Error was encountered while displaying video" while watching
> > > livetv
> > >
> > > --------------------+-------------------------------------------------------
> > > Reporter:  pasha   |        Owner:  ijr
> > >      Type:  defect  |       Status:  new
> > > Priority:  minor   |    Milestone:  unknown
> > > Component:  mythtv  |      Version:  head
> > > Severity:  medium  |   Resolution:
> > >
> > > --------------------+-------------------------------------------------------
> > > Comment (by Bradley Kite < bradley.kite at gmail.com>):
> > >
> > > Hi all,
> > >
> > > I initially posted this ref #1153.
> > >
> > > I have some logs attached and some further info on the problem that is
> > >
> > > occuring.
> > >
> > > It would appear as if the back-end is renaming the ring-buffer 2
> > > seconds
> > > after its initially switched it.
> > >
> > > The Simpsons ran on Channel 4 from 18:00 to 18:30, at which time
> > > Hollyoaks
> > > started.
> > >
> > > The problem occured at between 18:30:02 and 18:30:07 - the back-end
> > > initially decided that the recoding of Hollyoaks should be
> > > /mnt/store//1004_20060831180000.mpg - which is correct in my view
> > > because
> > > thats when the program started.
> > >
> > > However, 2 seconds later it decided that the recording should in fact
> > > be
> > > /mnt/store//1004_20060831183002.mpg - I dont know why it does this.
> > >
> > > The front-end "knows" that its getting near the end of the Simpsons,
> > > because it starts making
> > > calls to IsReallyNearEnd(), but then at 18:30:02 it tries to open
> > > myth://127.0.0.1:6543/1004_20060831183000.mpg which would/should be
> > > the
> > > correct file name, but instead the back-end has renamed it to be
> > > 1004_20060831183002.
> > >
> > > I've attached front-end and back-end logs with all this, and have
> > > added
> > > some comments.
> > >
> > > Any help will be much appreciated.
> > >
> > > btw, front-end and back-end are on the same machine, so this shouldnt
> > > be a
> > > clock issue.
> > >
> > > If any further info is required, please let me know and I'll try and
> > > obtain it.
> > >
> > > Regards
> > > --
> > > Brad.
> > >
> > > --
> > > Ticket URL: < http://svn.mythtv.org/trac/ticket/2340#comment:3>
> > > MythTV <http://www.mythtv.org/>
> > > MythTV
> >
> >
> >
> >
> > Hi all,
> >
> > I've been looking into this problem in a bit more detail think I am
> > close to finding the problem, but I'm
> > not that familiar with the code so any suggestions/pointers will be
> > helpful at this stage.
> >
> > It would appear that this is a race condition within TVRec::RunTV() in
> > libs/libmythtv/tv_rec.cpp.
> >
> > The condition for changing ring-buffers is:
> >
> > if (!has_rec && !rec_soon && curRecording && LIVETV_END)
> >
> > Where LIVETV_END is a macro which expands to "now >=
> > curRecording->endts".
> >
> > 'now' is initialised just before the condition is evaluated, however,
> > after unwinding
> > SwitchLiveTVRingBuffer() I can see at no point is curRecording actually
> > being updated,
> > so two seconds or so later the main "while (HasFlags(kFlagRunMainLoop))"
> > loop
> > executes again and switches ring buffers a second time - I have several
> > logs which demonstrate this now.
> >
> > At some point (Perhaps in some other thread - which is why I suspect
> > this is a race condition)
> > curRecording must be getting updated because it doesn't keep switching
> > ring-buffers infunatum.
> > .
> > Unless I can find out where curRecording is updated, I might just add
> > some code that prevents
> > the ring-buffer from being switched twice within 5 seconds or so, but
> > I'd rather fix this properly.
> >
> > Oh and btw, there is a commented out definition of the LIVETV_END macro
> > which was used for
> > testing, but will not show this error because it just forces a
> > ring-buffer switch every 20 seconds
> > rather than relying on curRecording to be updated.
> >
> > Any help/suggestions from somebody that knows this area of the code will
> > be much appreciated.
> >
> >
> > Regards
> > --
> > Bradley Kite.
> >
>
>
> Hi again,
>
> I've done some more digging around and it would appear as if the
> SwitchLiveTVRingBuffer()
> function doesn't actually switch the ring-buffer, it only prepares it to
> be switched.
>
> CheckForRingBufferSwitch() in recorderbase.cpp then gets called when the
> next key-frame is processed by HandleKeyframe() in dtvrecorder.cpp - this
> is what actually switches the ring
> buffer and indeed updates the curRecording variable.
>
> The race condition thus occurs when SwitchLiveTVRingBuffer() gets called
> twice between key-frames being processed, hence the error does not always
> occur.
>
> I will see if I can create a patch for this some time tomorrow.
>
> Regards
> --
> Brad.
>


Please see http://svn.mythtv.org/trac/ticket/1153#comment:29 for a patch
that should fix this issue.

Regards
--
Bradley Kite.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20060913/0a71efcb/attachment.htm 


More information about the mythtv-dev mailing list