[mythtv-users] one recording keeps failing

Mark Perkins perkins1724 at hotmail.com
Wed Sep 3 13:23:59 UTC 2014



> On 3 Sep 2014, at 9:04 pm, "Vincent McIntyre" <vincent.mcintyre at gmail.com> wrote:
> 
>> On 9/3/14, Mark Perkins <perkins1724 at hotmail.com> wrote:
> 
>>> mysql> select cardinputid, cardid, schedorder, livetvorder
>>>   -> from cardinput;
>>> +-------------+--------+------------+-------------+
>>> | cardinputid | cardid | schedorder | livetvorder |
>>> +-------------+--------+------------+-------------+
>>> |           1 |      1 |          1 |           1 |
>>> |           2 |      2 |          1 |           1 |
>>> |           3 |      3 |          3 |           3 |
>>> |           4 |      4 |          3 |           3 |
>>> +-------------+--------+------------+-------------+
>> 
>> Note, depending on your usage the general recommendation is to have your
>> LiveTV order the opposite to your scheduler order to try and minimise LiveTV
>> tripping up your recordings.
> 
> Yes, indeed. I use livetv only rarely and never while recordings are
> in progress.
> I have tried this out now though; I deleted all cards and video
> sources (there was only one source) and started over; when I saw the
> option to have livetv in a different order I tried to set it up (in
> the mythtv-setup gui). I ended up with this mess:
> 
> mysql> select cardinputid, cardid, schedorder, livetvorder from cardinput;
> +-------------+--------+------------+-------------+
> | cardinputid | cardid | schedorder | livetvorder |
> +-------------+--------+------------+-------------+
> |           1 |      1 |          1 |           4 |
> |           3 |      3 |          3 |           1 |
> |           2 |      2 |          1 |           4 |
> |           4 |      4 |          3 |           1 |
> +-------------+--------+------------+-------------+
> 
> I need to go and reread Mike Dean's patient and detailed explanations
> and try again.

I don't see anything particular wrong here? The LiveTV order is reversed compared to the schedule order which is recommended.

> 
>>> For my system I am starting to suspect the hardware,
>>> but there are other things at play.
>>> * The network changed their callsign from 'ABC1' to 'ABC'
>>>  (on both subchannels of the multiplex, sigh)
>>>  So I deleted the recording rule and recreated it,
>>>  with the 'this channel' and 'this time' scheduling filters ticked.
>>>  That did not seem to make a difference.
>> 
>> Note that 'this time' recording rules might be a bit sensitive to changes in
>> your EPG schedule.
>> 
>> If there have been changes to the channels have you tried doing a rescan of
>> the channels in MythTV-setup and checking video source setup? Could always
>> try a delete all capture card / video sources (on all hosts) and readd as a
>> bit of a longshot.
> 
> I tried this, last night. Tonight the recordings that failed yesterday worked.
> 
>>> * Some other recordings trying to use tuner 1 have been failing too.
>>> 
>>> I do think there is some kind of mythtv bug or misfeature lurking here.
>>> When the recording starts, it shows up in the 'watch recordings'
>>> view rendered in green (currently recording). But there is no file
>>> open in any of the recordings directories - the system is waiting for
>>> the tuner to settle.
>> 
>> I'm not sure I followed your conclusion here that the system is waiting for
>> the tuner to settle? Did you get this from the log files? If you try and
>> view an in progress recording what do you see? If you go to LiveTV and
>> manually change the input source to the second virtual tuner in the physical
>> tuner you are having trouble with and channel change to the channel in
>> question what do you see?
> 
> 
> The log files suggested this to me. When a recording fails I
> _sometimes_ see messages like this for the duration of the recording
> window -
> 
> localhost mythbackend: mythbackend[2118]: I TVRecEvent tv_rec.cpp:3955
> (TuningSignalCheck) TVRec[1]: TuningSignalCheck: Still waiting.  Will
> timeout @ 17:35:00.000
> 
> I've posted the logfile showing the failures of Sep 2nd;
> https://drive.google.com/file/d/0B1Uoq3VrNrkRMGh2dlRKdWhTWFU/edit?usp=sharing
> 

This bit (extract below) got my attention first. I think deleting the capture cards / video sources and re-adding / scanning for channels should have fixed it now. The key part being the channel scan.

Sep  2 16:28:00 localhost mythbackend: mythbackend[2118]: E DVBRead
recorders/dtvsignalmonitor.cpp:322 (HandlePAT)
DTVSigMon[1](/dev/dvb/adapter0/frontend0): Program #769 not found in
PAT!#012Program Association Section#012 PSIP tableID(0x0) length(41)
extension(0x221)#012      version(0) current(1) section(0)
last_section(0)#012      tsid(545) programCount(8)#012  program number     0
has PID 0x0010#012  program number   544 has PID 0x0102#012  program number
545 has PID 0x0100#012  program number   546 has PID 0x0101#012  program
number   547 has PID 0x0103#012  program number   548 has PID 0x0106#012
program number   550 has PID 0x0104#012  program number   551 has PID 0x0105
Sep  2 16:28:00 localhost mythbackend: mythbackend[2118]: W DVBRead
mpeg/mpegstreamdata.cpp:806 (ProcessPAT) MPEGStream[1](0x7f7b0002dca0):
ProcessPAT: PAT is missing program, setting timeout
Sep  2 16:28:00 localhost mythbackend: mythbackend[2118]: D DVBRead
recorders/signalmonitor.cpp:220 (AddFlags)
SigMon[1](/dev/dvb/adapter0/frontend0)::AddFlags: Seen(PAT,) Match() Wait()
Sep  2 16:28:00  mythbackend: last message repeated 3 times
Sep  2 16:28:00 localhost mythbackend: mythbackend[2118]: E DVBRead
mpeg/mpegstreamdata.cpp:814 (ProcessPAT) MPEGStream[1](0x7f7b0002dca0):
ProcessPAT: Program not found in PAT. Rescan your transports.


> You will see this behaviour at 16:28:00 - 17:34:59 and 19:30:00 - 20:04:59.
> The recording scheduled to start at 19:00 or so seems to have failed
> for a different reason,
> hence the "_sometimes_".
> 
> Note that this is not a complete-log-since-boot and things will get
> very confusing after
> about 2100 when I start wreaking havoc and redid the cards and sources
> as noted above.
> But hopefully it's enough to be useful to someone interested enough to
> plough through it.
> 
> Thanks for your interest
> Vince
> _______________________________________________
> 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


More information about the mythtv-users mailing list