[mythtv-users] Live Tv stalls. Again

[Kevin Johnson]

Got some different errors from the frontend today.
Not sure if they give any other clues.  This is after I updated the backend
to the latest fixes.

Jul 22 18:43:26 g430 mythfrontend.real: mythfrontend[2106]: W CoreContext
mythplayer.cpp:3145 (PauseDecoder) Player(1): Waited 100ms for decoder to
pause

Jul 22 18:43:29 mythfrontend.real: last message repeated 9 times

Jul 22 18:43:29 g430 mythfrontend.real: mythfrontend[2106]: E CoreContext
mythplayer.cpp:3205 (DecoderEnd) Player(1): Failed to stop decoder loop.

Jul 22 18:43:29 g430 mythfrontend.real: mythfrontend[2106]: I CoreContext
mythplayer.cpp:5320 (SetDecoder) Player(1): Waited 10ms for decoder lock

Jul 22 18:44:00 mythfrontend.real: last message repeated 1004 times

Jul 22 18:45:01 mythfrontend.real: last message repeated 2100 times

Jul 22 18:45:33 mythfrontend.real: last message repeated 1099 times



On Tue, Jul 22, 2014 at 7:39 AM, Kevin Johnson <iitywygms at gmail.com> wrote:

>
>
>
> On Tue, Jul 22, 2014 at 1:46 AM, Mike Perkins <
> mikep at randomtraveller.org.uk> wrote:
>
>> On 22/07/14 09:34, Jean-Yves Avenard wrote:
>>
>>> On 22 July 2014 20:26, Mike Perkins <mikep at randomtraveller.org.uk>
>>> wrote:
>>>
>>>  I'm assuming that the error messages shouldn't be truncated like that?
>>>> Is
>>>> this an indication of buffer overflow / underflow?
>>>>
>>> those errors are typical to myth not writing to the file any longer,
>>> or taking a long time to write.
>>>
>>> There are two threads at play.
>>> The recorder, that capture the data from the capture card, and write it
>>> to disk.
>>>
>>> and the reader which serve data to the mythfrontend client.
>>> WaitForReadsAllowed errors are thrown when the reader has read
>>> everything that there is to read and has been waiting for too long for
>>> more data to be available.
>>>
>>> In the backend log, you will probably see where the bottleneck is.
>>> Either the capture card, or the disk taking a long time to write XXX
>>> bytes.
>>>
>>>  I'm talking about the log messages *themselves*, not the errors that
>> are referred to.
>>
>
>
> They are truncated because I fail.
>
> Jul 21 21:46:07 mythbackend mythbackend: mythbackend[1338]: I
> ProcessRequest mainserver.cpp:1556 (HandleAnnounce) adding: g430 as a
> remote file transfer
> Jul 21 21:46:52 mythbackend mythbackend: mythbackend[1338]: W
> ProcessRequest ringbuffer.cpp:1224 (WaitForReadsAllowed)
> RingBuf(/D2/livetv/1706_20140722044607.mpg): Taking too long to be allowed
> to read..
>
> Jul 21 21:47:01  mythbackend: last message repeated 138 times
> Jul 21 21:47:01 mythbackend mythbackend: mythbackend[1338]: E
> ProcessRequest ringbuffer.cpp:1229 (WaitForReadsAllowed)
> RingBuf(/D2/livetv/1706_20140722044607.mpg): Took more than 10 seconds to
> be allowed $
> Jul 21 21:47:04 mythbackend mythbackend: mythbackend[1338]: I
> ProcessRequest mainserver.cpp:1436 (HandleAnnounce) MainServer::ANN Monitor
>
> I think it is safe to assume that since the backend has not been upgraded
> in a month that the software is not the issue.
> I think that upgrading the frontends did not cause this issue.  How could
> it?
> I can stream 3 different high def movies from the backend to 3 separate
> computers without a hiccup. The network must be okay.
>
> This must be a drive starting to fail or something of that nature.
>  Maybe the hdhr prime is causing this.  But then I would see recording
> that failed correct?
>
> I would start the backend with the -v option, but it errors out with a
> message about being a upstart job and -v is not supported.
> So I need to read on how to start the backend with more error logging.
> Once I have that going I can share the more detailed log files.
>
>
>>
>> --
>>
>> Mike Perkins
>>
>>
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users at mythtv.org
>> http://www.mythtv.org/mailman/listinfo/mythtv-users
>> http://wiki.mythtv.org/Mailing_List_etiquette
>> MythTV Forums: https://forum.mythtv.org
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20140722/cbc82bad/attachment.html>