[mythtv-users] Two "recordings" of the same episode, one is zero bytes

[Hika van den Hoven]

Hoi Stephen,

Saturday, February 22, 2025, 10:58:20 AM, you wrote:

> On Sat, 22 Feb 2025 10:35:24 +0100, you wrote:

>>On Fri, 21 Feb 2025 at 23:58, Ian Evans <dheianevans at gmail.com> wrote:
>>
>>> On Fri, Feb 21, 2025, 5:36?p.m. Hika van den Hoven <hikavdh at gmail.com>
>>> wrote:
>>>
>>> Hoi Ian,
>>>>
>>>> This means that for whatever reason at first the recording fails. Then
>>>> on restarting the recording one second later it succeeds. Check your
>>>> logs around that time for more info.
>>>>
>>>> Friday, February 21, 2025, 11:05:30 PM, you wrote:
>>>> [snip]
>>>>
>>>> >
>>>>
>>>
>>> Is this immediate retry/restart something new in the code? I've been
>>> running MythTV since 2011 and I've only seen this happening in the last
>>> month or so.
>>>
>>> No, this part of the code has not been changed as far as I know. On my
>>production backend I do not have any zero byte recording. The zero byte
>>recordings that are created by Live TV are automatically deleted real soon
>>and they never appear in the "Watch Recordings" list.
>>On my development system however there are many zero bytes recordings as
>>the result of recording failures.
>>My best guess is that Hika is right about the first recording failing and
>>that it succeeds on a restart.
>>This can mean that there is something going wrong with your tuner hardware.
>>
>>Groetjes,
>>Klaas.

> But recordings do not actually fail until the stop time - before then,
> they are "failing", but not "failed".  So if I have a "failing"
> recording for an hour long programme, it will not re-record it from a
> +1 channel because an hour later when the +1 channel starts that
> programme it has not hit the stop time and not marked the original
> recording as failed.  So I just get a 0 byte recording for the
> original time on the normal channel.  The only times I would get a 0
> byte recording and then a restart on the same channel is if I manually
> stop the first recording and manually restart it, or if there was a
> stop and restart of mythbackend.

> This behaviour has been a problem for a long time - if a recording is
> failing, mythbackend should stop the tuner and restart it again.  If
> it is unable to stop that tuner due to another recording being in
> progress on the same tuner, it should try and use another tuner on the
> same multiplex.  It makes no sense for mythbackend to see no recording
> data for a recording, but just ignore that for the entire scheduled
> length of the recording.


I repeat check the log if there is more info.

I get similar restart behavior if I restart my main frontend. I never
came to really investigating it. My current guess is that it makes the
backend so busy it has insufficient process time and/or memory left or
the network is flooded.
My database is quite big and the backend at the same time becomes a
bit sluggish.
I just do not restart the frontend when a recording is in proces.
Which I anyhow rarely do. I suspend when not using it and wake it
later at need.

Tot mails,
  Hika                            mailto:hikavdh at gmail.com

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens