TVHeadend on RasPi4 gives occasional runs of "Continuity counter error"

For those times when the problem has started and will affect future recordings, what is the memory consumption? Are there stale processes left behind?

A couple of suggestions:

"free -m" can keep track of memory consumption. Storing one result in a file shortly after reboot and then each day on the journey toward appearance of the problem would help identify any trends.

"ps augx" can show processes. Some processes will start shortly after boot and then stay forever. Others will come and go. If you put one output per day or so into a file, you can compare and see what is going on.

HTH

Thanks. I'll keep checking "free -m". So far I've seen Free Mem reduce from about 7000 (GB?) to 890 and then spontaneously increase when I next looked a few hours later, but the Swap statistics remain at 99 total/free.

I'll see if I can spot any trends or memory-hogging processes in "ps".

When I next see the problem happening, the free and ps readings should be interesting... So far, the problem has not happened since I started monitoring.

And then I can try Jan's crontab lines to clear caches.

I am considering a crontab entry to do a "shutdown -r -y" in the small hours of each morning, if all else fails...

Am 27.02.23 um 14:44 schrieb NY: > Is anyone running TVHeadend TV-recording software on a Raspberry Pi? > If so, have you found times when you get loads of "Continuity counter > errors" during a recording?

I used to do that. The more traffic there was on the USB bus the more errors I got.

Getting a PI4 and connecting the HDD via USB3 improved the situation quite a bit, but the problem did never go away completely.

For earlier devices overclocking seemed to help a little bit.

In the end I gave up solved the problem by getting a used ZBOX for recording.

On Wed, 1 Mar 2023 14:47:17 +0000, NY snipped-for-privacy@privacy.net declaimed the following:

Probably MB -- the biggest R-Pi 4 only has 8GB. Here is a fresh boot of my 4GB R-Pi 4 (apologies about line wrap in the news client)

pi@rpi4b4gb:~$ free -m total used free shared buff/cache available Mem: 3838 218 3158 34 461 3455 Swap: 99 0 99 pi@rpi4b4gb:~$

You might also be interested in the output of "top", though that is interactive and not a one-shot command.

top - 11:52:22 up 7 min, 3 users, load average: 0.01, 0.27, 0.19 Tasks: 178 total, 1 running, 177 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.2 us, 0.2 sy, 0.0 ni, 99.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 3838.9 total, 3155.9 free, 218.9 used, 464.1 buff/cache MiB Swap: 100.0 total, 100.0 free, 0.0 used. 3455.2 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1536 pi 20 0 11348 2972 2540 R 1.0 0.1 0:00.13 top 350 root 0 -20 0 0 0 I 0.3 0.0 0:03.44 kworker/u9:1-brcmf_wq/mmc+ 380 avahi 20 0 6916 2736 2476 S 0.3 0.1 0:01.17 avahi-daemon 1 root 20 0 33908 8892 7020 S 0.0 0.2 0:03.06 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd 3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp 5 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 slub_flushwq 6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 netns 10 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq 11 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_tasks_rude_ 12 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_tasks_trace 13 root 20 0 0 0 0 S 0.0 0.0 0:00.10 ksoftirqd/0 14 root 20 0 0 0 0 I 0.0 0.0 0:00.09 rcu_sched 15 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/0 16 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0 17 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/1 18 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/1 19 root 20 0 0 0 0 S 0.0 0.0 0:00.07 ksoftirqd/1 21 root 0 -20 0 0 0 I 0.0 0.0 0:00.01 kworker/1:0H-events_highp+ 22 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/2 23 root rt 0 0 0 0 S 0.0 0.0 0:00.01 migration/2 24 root 20 0 0 0 0 S 0.0 0.0 0:00.05 ksoftirqd/2

I'm a plonker: what I meant was 7000 MB or 7 GB, not 7000 GB. *I* knew what I meant ;-)

My Pi has just started misbehaving again.

Free -m gives

total used free shared buff/cache available Mem: 7875 247 372 70 7255 7309 Swap: 99 0 99

Whereas previously it was around

total used free shared buff/cache available Mem: 7875 234 6981 70 660 7334 Swap: 99 0 99

So "free" has dropped dramatically and buff/cache has increased dramatically.

Jan's

/bin/echo 3 > /proc/sys/vm/drop_caches

when executed manually, does restore things: "free -m" is

total used free shared buff/cache available Mem: 7875 247 7413 72 214 7333 Swap: 99 0 99

Am I correct that the command should have a space between what Jan gave as "3>", so as to say "echo the digit 3 redirected into 'file' /proc/sys/vm/drop_caches"?

I will see whether the problem still happens. I'll clear TVH's count of errors (60 continuity errors since a recording a few hours ago, before which there were 0) and see if the count increases again in a recording in an hour or so.

I suppose the problem could be due either to a software error or a hardware error (in Pi or the USB tuners), and rebooting (without power off) may clear any/all of those, so identifying which of those mechanisms is to blame could be a problem ;-)

On 01/03/2023 19:41, NY wrote: [free -m]

Use free -h instead, as it will then print the units it's using. You can also use -h with other commands such as ls, du or df which will otherwise display sizes with lots of digits.

---druck

Also Linux will use any spare memory for disk caches and buffers. That doesn't mean its 'running out'

$ free -h total used free shared buff/cache available Mem: 7.7Gi 2.5Gi 1.4Gi 754Mi 3.8Gi 4.2Gi Swap: 2.0Gi 335Mi 1.7Gi

Note that 'available' = 'free'+ 'buff/cache'

It's early days yet, and I've only been using Jan's "echo 3 > /proc/sys/vm/drop_caches" crontab fix for a day or so, but so far it's looking good.

I'll post again after a few more days, by which time the problem would probably have occurred - so the longer I go without seeing any continuity errors, the more likely it is that Jan's fix was the right one.

I'll be frustrated if what I was ascribing to reception faults turns out to be a memory-usage problem on the Pi. I could have asked and received the fix ages ago if I'd known...

The Pi has now been running non-stop for a week and TVHeadend seems to be behaving a lot better.

I did a "deluge test" by scheduling simultaneous recordings of multiple SD and HD channels on each of the DVB-S2 and DVB-T2 decoders. Over an hour's recording, I had no errors whatsoever, despite presumably very large amount of data being written to the USB-connected spinning HDD and a smaller amount of data being read from each of the tuners over each one's USB.

(Do DVB tuners tend to send all the data for a mux over USB to software, or are they told which SIDs to pick out and only send the required ones over USB? In other words, is the amount of data that a tuner sends dependent on how many simultaneous recordings are made on the same tuner/mix?)

Of all the recordings I've made, defaulting to DVB-S but using DVB-T for second and third simultaneous recordings, I think one recording had one continuity error. Interestingly, the Status page reported more errors (maybe 10 at worst per hour) but the actual recording did not contain any errors and nothing appeared in the diagnostic log.

Jan, I think your drop_caches fix has done the job. Many thanks. When I do eventually reboot, the swappiness value will be changed at boot-time and I'll see what effect (if any) that has.

USB tuners tend to send the whole mux, and let the software filter out the unwanted PIDs, I've always been a bit wary of them for that reason and the high interrupt rates that generates.

PCI tuners tend to have hardware PID filters (I did once buy a satellite tuner that was essentially a USB tuner on a PCI card with a USB interface on-board).