TVHeadend on Pi4, with PCTV 491e DVB-S2 and Hauppauge WinTV DualHD DVB-T2, feeding USB spinning HDD - glitches

On a sunny day (Sun, 2 Jan 2022 17:51:23 -0000) it happened "NY" snipped-for-privacy@privacy.invalid wrote in <sqson5$onl$ snipped-for-privacy@dont-email.me:

OK, not been here for a long time.. will try to share my experience with my PI4 with 4 GB memory. I have a 3.something Toshiba TB USB harddisk on it via a Sitecom powered USB hub, recording 5 security cameras 24/7, plus some other recordings, plus background music player, plus Chromium browser. I had similar mysterious problems and it had to do with the Pi cache. After adding this to crontab; 0,15,30,45 * * * * /bin/echo 3 > /proc/sys/vm/drop_caches clears the cache every 15 minutes, I have not seen any problems. # uptime 19:42:20 up 59 days, 10:27, 15 users, load average: 0.26, 0.61, 0.88

As to satellite, recently a new radar was installed a few miles from here, it _completely_ interrupts almost all DVB-S reception every few seconds or so (revolution time of the radar dish) but somehow not DVB-S2 HD. But that is both on a PC with sat card and also on a Chinese satellite receiver, I think that does not apply to you in this case.

And no, the system with harddisk boots normally. But the Pi and other stuff is now on an UPS so booting is rare.

My Pi4 8 GB with similar Toshiba harddisk on similar USB hub also boots normally. but does not have the drop cache line active, but does not do a lot of recording so don't know about recording errors.

So maybe you have a cache fill problem?

Any windmills around? play havoc with radio and TV reception..

I'll give that crontab line a try. A cache-clearing problem does sound plausible. I wonder what effect it would have if a cache was cleared while a recording was being made. Only one way to find out... :-)

The problem with hanging on booting seems to be reported by quite a lot of people on the RasPi 4 forums. There have been a number of theories, such as that the Pi 4 doesn't like to boot if the USB +5V line has power on it (from the PSU of a powered up feeding "up" the cable). However I proved that this was not the cause of my problem by making a special USB cable between Pi and hub with the data lines intact but the +5V line cut, to prevent back powering. I decided to cut my losses and use a powered USB/SATA interface to a SATA disc instead.

That problem with the radar site sounds pretty serious if it is taking out satellite reception for people nearby. I imagine the radar uses different frequencies to the 10-13 GHz used by DVB-S(2) but something is generating harmonics of the radar frequency which *are* in the 10-13 range.

On a sunny day (Sun, 2 Jan 2022 19:58:54 -0000) it happened "NY" snipped-for-privacy@privacy.invalid wrote in <sqt06m$epn$ snipped-for-privacy@dont-email.me:

Just checked, the Pis here are powered from the original Raspberry wallwarts.

Yes it is, there are even meetings between the army and the people here and email exchange, they say they fixed some things, I am glad I at lest get the HD channels without problems. The army is afraid the Russians are coming, that is why the radar as far as I understand it. The radar here is around 1.3 GHz, very close to GPS

with an RTL-SDR stick. So, whatever the community says (they complain about noise from the rotating dish too) the thing is probably here to stay.

I used to have this problem with DVB-C, starting on a Pi1 all the way to a Pi4.

3 receivers on a powered hub and a disk with its own power supply.

For the slower devices playing with overclocking and force_turbo seemed to help a little, but finding just the right setting required some experimenting. Higher is not always better.

Unfortunately the errors always came back after a while.

For the Pi4 it helped a lot to put the disk on USB3 with the receivers on USB2, but a few errors per hour remained.

After I finally tried to run tvh on a laptop without getting any errors for half a day I got a used zbox with an internal ssd. Not a single error for months and fewer cables.

I can't quickly find the reference but I read somewhere that the USB data lines could leak enough power back into the Pi to prevent it doing a full cold start.

My terrestrial reception is remarkably glitch-free despite the hill about

500 metres from our village which blocks what is otherwise perfect line of sight, although at about 75 km range from the Belmont transmitter. I was warned that I'd probably have problems whenever there was an atmospheric "lift", causing distant transmitters on the same frequencies to interfere with the ones from Belmont. But I've not seen any evidence of that - reception does not get worse at certain times of year or during certain types of weather.

The only time I had exceptionally poor terrestrial reception was just after we moved to our house. I noticed that in an evening that one multiplex (but no others) started producing horrendous amounts of continuity errors. I'd replaced some tungsten GU10 light bulbs in my study (which is directly below the aerial) with LED ones. I should have realised that the problem dated from that time, and that it always started *after dark* when I'd turned the study lights on. Once I went round turning everything off one by one, and realised that it was the lights, I quickly traced it to one rogue GU10 which was apparently kicking out lots of crap at about 482 MHz (Belmont's PSB1 mux). Surprisingly, COM5 on 490 and PSB2 on 506 were not noticeably affected. I swapped that GU10 with one from another part of the house (further away from the aerial) and have not had problems since.

Satellite reception is fine, apart from in very heavy rain - when I force TVHeadend to record from terrestrial versions of channels, if I remember to check weather forecasts.

I get the distinct feeling that it is a problem with the Pi or the tuners rather than the signal that is being fed to them, because it seems to happen more often if I'm recording from two or three tuners at the same time, and when it happens it almost always affects all active tuners. If it was reception conditions, I'd expect terrestrial to be fine when satellite was glitching, or vice versa. I've checked that at times of glitches, the TV, fed from another LNB on the same dish, and from another leg from the terrestrial aerial amplifier, is glitch-free, and that if I swap the two satellite/aerial feeds (between TV and RPi tuner) the problem stays with the RPi. So it's not LNB or cable.

Also there is the fact that rebooting the Pi, even without turning off its power or that to the satellite LNB, always cures the problem for a few days/weeks. I suppose I ought to set up a cron job to reboot the Pi in the middle of the night (avoiding the time when TVH updates its EPG).

I'll try Jan's /bin/echo 3 > /proc/sys/vm/drop_caches as a manual command (with sudo) next time I detect a problem, firstly to check that it doesn't cause problems at the moment of execution and secondly to see if the glitches go away (ie that TVH's Status|Stream doesn't report any *new* continuity errors).

I'm not sure why it happens on my Pi with my powered hub even when the lead has its +5V line cut to prevent this happening. And I'm not sure why the Pi

4 is sensitive to it when the 3B+ (with the same hub) isn't.

I wonder if, as you say, the hub also holds the *data* lines high or low, instead of allowing them to float at whatever voltage the Pi sets them at. If so, you can't combat it just by cutting the +5V line.

I'm surprised the PiHut haven't produced a list of known-good hubs so you know which to buy (and which not to buy).

It's only a problem if you need to inject power to a spinning USB drive, rather than letting the computer supply its power as you'd do with a PC, laptop or Mac. I imagine SSDs use sufficiently little power that they can be powered directly from a Pi.

The way I've got round all these issues is to power everything from an external heavy duty 5V PSU, taking care of fusing/protection at source, then feeding the Pi itself from the 5V pins on the IO header (also connecting 0V to *all* the ground pins). Power for drives etc. also comes from the same source, so everything starts up together. So far, I've had no problems.