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

[Bradley Kite]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20060912/be445a58/attachment.htm