Project

General

Profile

Trying to record 24/7 - recording fails after a few hours (update: found a possible workaround)

Added by Timo Albert about 4 years ago

Update:
Continuous encoded recording of the same channel (1 file per hour) crashed after a random number of hours (<24). Last recorded file was shorter than an hour. All following recordings failed (file missing).
Assumption:
Encoder fails at some point, causing following recordings to also fail.
Workaround:
Used a different encoder for each recording. So far I got >40 successful recordings.
Will update again if recording is stable for at least one week.

Hi,

i'm trying to record a channel 24/7 for documentation purpose (small local tv station, have to sometimes prove to customer if something played on a specific date and time).

System ran for a few month, was never reliable so i reinstalled it just yesterday. Only things i installed after Linux Mint setup was chromium and tvheadend. Updated everything with Linux Mint built in Update tool.

I created 24 1-hour-Timers and used the "webtv-vp8-vorbis-webm" stream profile for transcoding and edited it to my needs: Video bitrate is reduced to 200 kb/s, resolution to 288, audio is set to libvorbis at 32 kb/s. The files just need to show what was running. No need for good quality. The records are stored in the standard folder (/home/hts) with standard permissions. PC has a 1TB hdd that should be good for about 10 month of 24/7 recordings (<100 MB/h). DVR file retention period is set to 300 (so the files will be automatically deleted, hopefully).

The issue:
When the PC starts up, tvheadend will record and transcode just fine, not causing much cpu-load. But after some recordings each following recording showed as "file missing" in the "removed recordings" section. And when i look at the Upcomming /Current Recordings tab the Recording File Size stays at ---. As i said: I reinstalled everything from scratch just yesterday. Tonight the recordings stopped after just 18 files. I also noticed that the last recorded files is just 56 minutes long. So i guess the error occurred during the recording and transcoding of this file and caused the following recordings to also fail.

When i noticed that some recordings had failed i stopped the current recording (that obviously also din't work) and made a short test recording (in the EPG tab). That worked. Following timed recording also worked, so does the current one (Recording File Size is rising). Didn't restart tvheadend to "fix" the problem.

So maybe it is a problem with the encoder or the overlapping of the timers. Tvheadend has no problem doing two simultaneous recordings from the same channel (tested by accident and also experienced from my own RasPi setup).

I'm entertaining the idea of restarting tvheadend each 6 hours ( sudo /etc/crontab -> * 3 * * * /bin/systemctl restart tvheadend ?) or even the complete PC. But that would cause a gap in the documentation that could make the complete setup useless (what if i lose an essential minute?).

I just now ticked the "Restart on error" box in the stream profile and will observe the next days. But i highly doubt that will fix the problem because why should one failed recording cause the following recordings to also fail? The last setup only recorded 12 continuous hours per day (also split to 1-hour-recordings), because we are still testing the system. If i remember right, it sometimes failed only for a few hours, sometimes for days until i restarted the pc.

Does anybody have an idea what i should try?
Can i provide any logs to help identifying the problem?
Or does anybody have the magical solution because i made a very obvious mistake?

Greetings

System:
Lenovo Thinkcentre M93 p with an i5 4570T, 8GB RAM, Linux Mint 20 with Cinnamon desktop.

DVB-S2 tuner:
Technisat Skystar USB HD (was recognized by Tvheadend without me installing the firmware)

Tvheadend version:
HTS Tvheadend 4.2.9~pre+201911151752-0~built202011131255~git5bdcfd8ac~ubuntu20.04.1
(from this repository: ppa:mamarley/tvheadend-git-stable)


Replies (2)

RE: Trying to record 24/7 - recording fails after a few hours - Added by Timo Albert about 4 years ago

Update:
With my current setup i had 13 successful recordings. The 14th stopped after about 46 minutes (should have been 1 hr). After that no more files have been recorded. My guess is that the encoder is failing at some point, somehow causing all following recordings to also fail.

I stopped the current recording, set the default recording profile to use the "webtv-h264-aac-matroska" Streaming profile (which i edited to my needs, see 1st post) and continued testing. Neither the PC nor Tvheadend have been restarted and the test recording worked. CPU load is low (like with webm profile). The next 23 timers will use the Default profile (now with matroska). Just to see if matroska will fail within 24 hours.

I now created two different Recording profiles. One using the matroska preset (libx264: libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10), the other one webm (libvpx: libvpx VP8). After the already planned timer recordings i will switch the preset every hour to use a different encoder.

RE: Trying to record 24/7 - recording fails after a few hours - Added by Timo Albert about 4 years ago

Just as i feared:
Changing the recording profile to use the matroska based streaming profile for encoding didn't provide the needed reliability. Last recording started at 6am (after 19 successfull recordings) and is only ~20 min long.

At 11 am the first timed recording using the webm based streaming profile started and was successful. All following recordings where set to use a different streaming profile each hour. 12 pm matroska, 1 pm webm, 2 pm matroska, ...

So far i got 47 successful recordings in a row.

Would still like to know why a failed recording can cause the following recordings (using the same encoder) to fail.

Maybe Tvheadend should force a new instance of the encoder with each recording event?

Again:
Can anybody tell me if there is something else i can do to help investigating the cause of my problem? Or is there simply no one interested because i maybe already found a workaround?

    (1-2/2)