[mythtv-users] Many recordings fail and then succeed a second later

Stephen Worthington stephen_agent at jsw.gen.nz
Mon Jan 20 02:09:29 UTC 2020


On Sun, 19 Jan 2020 14:02:27 -0500, you wrote:

>On 1/19/20, Ross Boylan <rossboylan at stanfordalumni.org> wrote:
>> On Sun, Jan 19, 2020 at 4:56 AM Daryl McDonald <darylangela at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Sun, Jan 19, 2020 at 1:56 AM Ross Boylan
>>> <rossboylan at stanfordalumni.org>
>>> wrote:
>>>
>>>> From that page it looks as if the tuning timeout is the relevant
>>>> parameter for recordings.  Assuming this is the channel_timeout column
>>>> in
>>>> the database, I have the default value of 3 seconds.
>>>> But the failure occurs only a fraction of second (~ 0.005 s =
>>>> 15:58:00.145173 -15:58:00.140392) after the initial attempt.  So it
>>>> doesn't
>>>> seem even the values already set are being respected.  Even if the other
>>>> timeout parameter of 1s is what matters, it's clearly well below that.
>>>> Although the 2nd try is 1s after the first.
>>>>
>>>> Ross
>>>>
>>>> On Sat, Jan 18, 2020 at 3:29 PM Doug Lytle <support at drdos.info> wrote:
>>>>
>>>>> On 1/18/20 5:06 PM, Ross Boylan wrote:
>>>>>
>>>>>
>>>>> Less commonly, the recordings just fail.
>>>>>
>>>>>
>>>>> Ross,
>>>>>
>>>>> Typically you need to increase your tuning timeout in mythtv-setup.
>>>>>
>>>>>
>>>>> https://www.mythtv.org/wiki/Setup_Capture_Cards#Card_type:_HDHomeRun_networked_tuner
>>>>>
>>>>> Doug
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>> Any dual tuner, in Mythtv set up like yours can record four programs
>>>> only
>>> if they come from only two muxes, so a third recording from a third mux
>>> will always fail.
>>>
>>> I don't understand how the remark about muxes (multiplexers?) relates to
>> any of the previous stuff.  I do understand that I can exceed 2
>> simultaneous recordings only if I record off multiple subchannels (I don't
>> know the technical term, but I mentioned 9.1 and 9.2 in my original post).
>> Are you saying that instead of 4 records in capturecard there should be 2?
>> I don't think any of the failures I listed involved attempting to record >
>> 2 programs.
>> And I don't see how that relates to increasing the timeout, or the fact
>> that my failures seem to happen faster than even the shortest timeout.
>> Ross
>>
>
>I'd say you're correct that the number of multiplexes shouldn't be an
>issue here unless you attempted to record more than two shows on
>different multiplexes...for example shows on 9.1, 11.1, 13.1 at the
>same time. You should however be able to record, for example, shows on
>all four of 9.1, 9.2, 11.1, 11.2 at the same time...and your capture
>card setup appears correct for that. You're SQL listing there doesn't
>include the "videodevice" column, but I'm assuming that all of those
>contain your tuner id. Prior to version 30, two of those would have
>had <id>-0 and two would have had <id>-1, but as of 30.0 those suffix'
>where removed. Yours all have a reclimit of 2 which is also correct
>for that.
>
>I have three of the dual tuner HDHRs. I've never had to change those
>default timeouts (the same as you have listed). One possibility is of
>course something that temporarily causes very bad reception. Another
>possibility however...one that I got burned by...is this:
>
>I had a short period where recordings were failing. What I discovered
>was that intermittently the network light on the back of my first
>tuner was flashing red, which indicates a network issue. I took me a
>while to notice it because it was NOT doing it all the time. Once I
>did, simply unplugging the HDHR and plugging it back in solved that
>and it was fine ever since.
>
>Tom

There is one DVB-T channel here in New Zealand ("Three") that needs a
huge timeout setting - it fails to record otherwise.  I had this
problem happen when I upgraded MythTV - the prior version (0.27???)
would retry the tuning automatically on failure and the second tuning
would succeed, but the new version's tuning code had changed that and
now there were no automatic retries and it was failing.  I did some
experimenting and found that it would normally take 7 seconds to work,
but occasionally needed even more.  After I set it to 10 seconds
(10000), it has been fine ever since.  All the other channels here
need a much shorter timeout.  This is the "Tuning timeout" in
mythtv-setup (cardinput.channel_timeout in the database).  It tells
mythbackend how long to keep waiting to see all the data packets
necessary to find all the streams in the DVB data that make up a
channel.  For some reason, the broadcasters of Three seem to have
misconfigured how often they broadcast one or more of the packets
necessary for this process, so they are not all seen with smaller
timeouts.  There have been other reports of rogue channels like this
from around the world since then, but so far, as best I can recall,
no-one has needed a higher timeout than 10 seconds.  When a
broadcaster reconfigures its channels for some reason, this sort of
misconfiguration can happen overnight without any warning, so I think
it would be best if everyone had the tuning timeout set to at least 10
seconds - it probably should be set as the default value.


More information about the mythtv-users mailing list