[Solved] new recordings getting cut off at about 60%

[stlouisubntu]

Hi Friends,

Faithful longtime mythtv user here needing advice and assistance with an issue such that our new recordings are getting cut off at about 60% percent or so.

We will be playing a recording (while the recording is still in progress or once it has completed - been happening either way) and a half hour program will stop and exit at about 18 minutes. The recording will continue for the full half hour but when we play it back, it will abruptly end at the same 18 minute point. Likewise, this happens at around 39 minutes for an hourlong program (and so on.)

We are cranking Xubuntu 20.04.2 (but with xfce replaced with a bare bones openbox wm)
Linux 5.4.0-562012221313-generic #0+mediatree+hauppauge-Ubuntu (PPA kernel for Hauppauge tuner hardware support)
Hauppauge WinTV-QuadHD-ATSC Hauppauge model 165101
NVIDIA GeForce GT 710 (with audio over HDMI)
Running mythtv 2:31.0+fixes.202102081459.ba4036099f~ubuntu20.04.1 (from the mythbuntu/31/ PPA)

The database and recordings were migrated to new(er) hardware from an old Mythbuntu 14.04 / mythtv 29 system.

The cause of this seems like bad seektables are being generated when the programs are being recorded and possibly corrupt mysql db tables as well.

As such we tried running the specified script to optimize the mythdb tables

then

mythcommflag --file <filepath> --rebuild

(from official MythTV wiki for Repairing_the_Seektable )

However, the result for a recording that was a hourlong but stopped prematurely at 39 minutes was that the entire recording was then made only 39 minutes long.

When this happens while a program is still recording and it exits prematurely, we can then launch LiveTV and watch the remainder of the program (and if we hit record it records as a new recording - not a part of the original.)

This seems a little bit like old MythTV trac/ticket/7978 but not completely as rebuilding the seektable using mythcommflag does not fix the issue.

Also, existing prior migrated recordings are fine. Also, not all recordings are impacted by this.

Further FWIW we have six difference storage directories recordings (each on mounted on a separate physical hardrive) as follows:

/home/mythtv/recordings_a/
/home/mythtv/recordings_b/
/home/mythtv/recordings_c/
/home/mythtv/recordings_d/
/home/mythtv/recordings_e/
/home/mythtv/recordings_ssd/

Advice and assistance would be much appreciated. Many thanks to the Mythtv devs and community for all you are doing.

[stlouisubntu]

Okay, friends. Confession time. Each of the storage drives is dangerously low on space (as follows):

/dev/sdd1 917G 917G 167M 100% /home/mythtv/recordings_a
/dev/sdb1 917G 908G 9.1G 100% /home/mythtv/recordings_d
/dev/sdc1 22G 19G 1.2G 95% /home/mythtv/recordings_c
/dev/sde1 917G 908G 1.1M 100% /home/mythtv/recordings_e
/dev/sdc3 894G 883G 2.0G 100% /home/mythtv/recordings_b

However, cumulatively mythtv indicates that I have 57 GB available for new recordings. Yes, on my old (pre migration mythtv 0.28) system, bad things did happen when we got low on space but only when we got below 40 GBs or so.

backend log excerpt:

Code: Select all

Feb 14 14:35:20 mythbox mythbackend: mythbackend[992]: E TFWWrite threadedfilewriter.cpp:507 (DiskLoop) TFW(/home/mythtv/recordings_b/1111_20210214200000.ts:65): File I/O  errcnt: 1#012#011#011#011eno: No space left on device (28)
Feb 14 14:35:20 mythbox mythbackend: mythbackend[992]: E TFWWrite threadedfilewriter.cpp:580 (DiskLoop) TFW(/home/mythtv/recordings_b/1111_20210214200000.ts:65): No space left on the device for file '/home/mythtv/recordings_b/1111_20210214200000.ts'#012#011#011#011file will be truncated, no further writing will be done.
Feb 14 16:00:13 mythbox mythbackend: mythbackend[992]: E TFWWrite threadedfilewriter.cpp:507 (DiskLoop) TFW(/home/mythtv/recordings_b/coverart//tmdb3.py_51481_coverart.jpg:109): File I/O  errcnt: 1#012#011#011#011eno: No space left on device (28)
Feb 14 16:00:13 mythbox mythbackend: mythbackend[992]: E TFWWrite threadedfilewriter.cpp:580 (DiskLoop) TFW(/home/mythtv/recordings_b/coverart//tmdb3.py_51481_coverart.jpg:109): No space left on the device for file '/home/mythtv/recordings_b/coverart//tmdb3.py_51481_coverart.jpg'#012#011#011#011file will be truncated, no further writing will be done.
Feb 14 16:00:15 mythbox mythbackend: mythbackend[992]: E TFWWrite threadedfilewriter.cpp:507 (DiskLoop) TFW(/home/mythtv/recordings_b/fanart//tmdb3.py_51481_fanart.jpg:109): File I/O  errcnt: 1#012#011#011#011eno: No space left on device (28)
Feb 14 16:00:15 mythbox mythbackend: mythbackend[992]: E TFWWrite threadedfilewriter.cpp:580 (DiskLoop) TFW(/home/mythtv/recordings_b/fanart//tmdb3.py_51481_fanart.jpg:109): No space left on the device for file '/home/mythtv/recordings_b/fanart//tmdb3.py_51481_fanart.jpg'#012#011#011#011file will be truncated, no further writing will be done.
Feb 14 18:11:40 mythbox mythbackend: mythbackend[13983]: E TFWWrite threadedfilewriter.cpp:507 (DiskLoop) TFW(/home/mythtv/recordings_a/1041_20210215000000.ts:82): File I/O  errcnt: 1#012#011#011#011eno: No space left on device (28)
Feb 14 18:11:40 mythbox mythbackend: mythbackend[13983]: E TFWWrite threadedfilewriter.cpp:580 (DiskLoop) TFW(/home/mythtv/recordings_a/1041_20210215000000.ts:82): No space left on the device for file '/home/mythtv/recordings_a/1041_20210215000000.ts'#012#011#011#011file will be truncated, no further writing will be done.

Okay, point taken. We have allowed our drives to fill up excessively. However, is there some "Storage Groups" setting of some kind I am missing. Mythtv 0.28 seemed to handle this better (unless there is some config setting we had applied on the prior system that we missed now.)

Although we are making progress, any advice or assistance would still be most welcome. How are other folks handling this? Yes, I did get a 4 TB drive we are about to install (and swap out with an existing 1 TB drive.)

[kmdewaal]

This can happen when your records are not allowed to expire, i.e. be deleted, by MythTV.
Check the Recording Rules / Default (Template) / Allow recordings to expire. This should be checked so that all new recording rules generate recordings that can be expired by default.

[stlouisubntu]

Thanks for the response and the advice. Deleting some recordings and freeing space solved the problem.

Issue resolved.

Thank you.

[bill6502]

I'm marking this solved, but future readers should note the comment two above.
Be sure recording rules (old ones and templates) have auto expire set.