[mythtv-users] LiveTV issues (root caused to cable signals)

MonkeyPet monkeypet at gmail.com
Mon Sep 3 02:19:39 UTC 2012


On Sun, Sep 2, 2012 at 5:53 PM, MonkeyPet <monkeypet at gmail.com> wrote:

> With 0.26 (Master Head), I tried a few more experiments:
> 1. LiveTV - Remote frontend, Tune to a TV Channel within a few mins, it
> aborts almost immediately with "max buffering exceeded".  Frontend will
> crash and needs to be restarted.
> 2. Recording - Now schedule the same channel, same show and start the
> recording.  No remote frontend are viewing the stream. Recording proceeds
> with no problems.
>

3. Recording/then streaming to remote frontend - This works also.  I tell
myth to record the show, then watch the recording immediately after
starting.  I am guessing I have to use this as the workaround until the
LiveTV streaming is more robust.  It sucks that I can't channel surf
anymore, but now I can watch almostLiveTV again.

If any developers want to work with me to debug the LiveTV issue, let me
know.  Since my setup reproduces the issue 100% of the time, I can test
patches, theories, etc.


>
> I am really doubting that this is a signal issue.  If it was a signal
> issue, #2 would behavior exactly like #1 and would be aborted also.  Also a
> majority of my recordings are finishing without any issues.  However,
> LiveTV would consistently fail and most of the time fail immediately within
> the first 5 mins.
>
> Backend log:
>
> 2012-09-02 17:16:20.798928 I [6287/28999] ProcessRequest
> ringbuffer.cpp:1098 (WaitForAvail) - RingBuf(/export/data/myth
> tv/4766_20120903001527.mpg): Waited 0.5 seconds for data
>                         to become available... 225236 < 327680
> 2012-09-02 17:16:21.299115 I [6287/28999] ProcessRequest
> ringbuffer.cpp:1098 (WaitForAvail) -
> RingBuf(/export/data/mythtv/4766_20120903001527.mpg): Waited 1.0 seconds
> for data
>                         to become available... 225236 < 3276802012-09-02
> 17:16:22.299456 I [6287/28999] ProcessRequest ringbuffer.cpp:1098
> (WaitForAvail) - RingBuf(/export/data/myth
> tv/4766_20120903001527.mpg): Waited 2.0 seconds for data
>       to become available... 225236 < 327680
> 2012-09-02 17:16:27.569263 I [6287/6351] HouseKeeping housekeeper.cpp:221
> (RunHouseKeeping) - Running housekeeping thread
> 2012-09-02 17:17:04.086174 I [6287/6340] TVRecEvent tv_rec.cpp:1043
> (HandleStateChange) - TVRec(5): Changing from WatchingLiveTV to None
> 2012-09-02 17:17:04.105938 E [6287/29068] HDHRStreamHandler
> hdhrstreamhandler.cpp:211 (UpdateFilters) - HDHRSH(1313E021-0):
> UpdateFilters called in wrong tune mode
> 2012-09-02 17:17:05.079236 I [6287/6340] TVRecEvent tv_rec.cpp:830
> (FinishedRecording) - TVRec(5):
> FinishedRecording(4766_2012-09-03T00:15:27Z) damaged recq:<RecordingQuality
> overall_score="0" key="4766_2012-09-03T00:15:27Z" countinuity_e
> rror_count="0" packet_count="365988">    <Gap start="2012-09-03T00:00:00Z"
> end="2012-09-03T00:15:27Z" duration="927" />
>     <Gap start="2012-09-03T00:16:14Z" end="2012-09-03T01:00:00Z"
> duration="2625" /></RecordingQuality>
>
>
> Frontend log:
>
> Sep  2 17:16:53  mythlogserver: last message repeated 10 timesSep  2
> 17:16:53 fa-Macmini mythlogserver: mythfrontend[2949]: N CoreContext myth
> player.cpp:2095 (PrebufferEnoughFrames) Player(0): Waited 19896ms for
> video buffers AAAAAUUUAAUUAAULAuAUUAUAAUAAAAAP
> Sep  2 17:16:53 fa-Macmini mythlogserver: mythfrontend[2949]: E Decoder
> avformatdecoder.cpp:4493 (GetFrame) decoding error#012#011#011#011eno:
> Unknown error 541478725 (541478725)
> Sep  2 17:16:53  mythlogserver: last message repeated 11 timesSep  2
> 17:16:53 fa-Macmini mythlogserver: mythfrontend[2949]: N CoreContext myth
> player.cpp:2095 (PrebufferEnoughFrames) Player(0): Waited 20012ms for
> video buffers AAAAAUUUAAUUAAULAuAUUAUAAUAAAAAP
> Sep  2 17:16:53 fa-Macmini mythlogserver: mythfrontend[2949]: E
> CoreContext mythplayer.cpp:2118 (PrebufferEnoughFrames) Player(0): Waited
> too long for decoder t
> o fill video buffers. Exiting..Sep  2 17:16:53 fa-Macmini mythlogserver:
> mythfrontend[2949]: E Decoder avformatdecoder.cpp:4493 (GetFrame) decoding
> error#012#011#011#011eno: Unknown error 541
> 478725 (541478725)Sep  2 17:16:54 fa-Macmini mythlogserver:
> mythfrontend[2949]: I CoreContext tv_p
> lay.cpp:2155 (HandleStateChange) TV: Attempting to change from
> WatchingLiveTV to None
>
>
>
> On Sat, Sep 1, 2012 at 4:02 PM, Monkey Pet <monkeypet at gmail.com> wrote:
>
>>
>>
>> On Sat, Sep 1, 2012 at 8:40 AM, Monkey Pet <monkeypet at gmail.com> wrote:
>>
>>>
>>>
>>> On Sat, Sep 1, 2012 at 6:01 AM, Michael T. Dean <mtdean at thirdcontact.com
>>> > wrote:
>>>
>>>> On 09/01/2012 01:51 AM, Joseph Fry wrote:
>>>>
>>>>>
>>>>>>  After re-cabling:
>>>>>>>> (notice the numbers jump)
>>>>>>>>
>>>>>>>> [me at mythtv libhdhomerun]$ ./hdhomerun_config 1313E021 get
>>>>>>>> /tuner0/status
>>>>>>>> ch=qam:759000000 lock=qam256 ss=76 snq=82 seq=100 bps=38809216
>>>>>>>> pps=994
>>>>>>>>
>>>>>>> Those numbers, while clearly better, are still rather low.  I
>>>>>>> typically
>>>>>>> see values in the 90's.  I seem to recall ss=76 indicates a power
>>>>>>> level that would normally be out of spec for digital cable (although
>>>>>>> it might just work sometimes).
>>>>>>>
>>>>>>> First thing, plug the hdhr directly into the outlet using a short
>>>>>>> piece of
>>>>>>> quality coax, and see if the values are more reasonable.  If not,
>>>>>>> call
>>>>>>> your cable company and ask them to make a service call.  They are
>>>>>>> responsible for adequate signal levels at the outlet.  If it looks
>>>>>>> good
>>>>>>> directly plugged into the outlet, it would point the finger towards
>>>>>>> your
>>>>>>> coax or splitters (or cable amp if you using one).
>>>>>>>
>>>>>>>  I just don't understand why recording a show works, but LiveTV
>>>>>> always
>>>>>> fail.  That seems odd to me.
>>>>>>
>>>>>>
>>>>>>  That is odd.  Do you have fast channel switching enabled?
>>>>>
>>>>
>>> It is set to never.
>>>
>>> I might have spoken too soon about the issue not occurring on
>>> recordings.  Myth lies about the recording times of truncated recordings,
>>> so it is hard to tell.  I have seen at least one instance of it during a
>>> recording.
>>>
>>> Until i get my signal issues look at by the comcast guys, my mythbox is
>>> useless now, I plan to upgrade to 0.26 to see if the behavior changes.
>>>
>>
>> Now everything is running 0.26-head, as expected I see the same issues.
>>  I found a better/shorter coax cable and used that instead and my signals
>> are getting better.
>>
>> This low signal  issue might be a good test case for the developers.  It
>> leads to strange mythfrontend behaviors for example, you can easily crash
>> the frontend by:
>> 1. starting liveTV
>> 2. then pulling the coax on your HDhomerun box.
>> 3. mythfrontend will either crash OR display the max buffering error
>>
>> I'll file a bug issue for this case.
>>
>>
>>
>>
>>>
>>>
>>>>
>>>> Use quick tuning
>>>>  - Never
>>>>  - Live TV only
>>>>  - Always
>>>> If enabled, MythTV will tune using only the MPEG program number. The
>>>> program numbers change more often than DVB or ATSC tuning parameters, so
>>>> this is slightly less reliable. This will also inhibit EIT gathering during
>>>> Live TV and recording.
>>>>
>>>> in your Input Connections in mythtv-setup, IIRC.
>>>>
>>>> Mike
>>>>
>>>> ______________________________**_________________
>>>> mythtv-users mailing list
>>>> mythtv-users at mythtv.org
>>>> http://www.mythtv.org/mailman/**listinfo/mythtv-users<http://www.mythtv.org/mailman/listinfo/mythtv-users>
>>>>
>>>
>>>
>>
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users at mythtv.org
>> http://www.mythtv.org/mailman/listinfo/mythtv-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20120902/6e9500c9/attachment.html>


More information about the mythtv-users mailing list