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

[Bradley Kite]

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