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

I'm getting intermittent continuity errors on tuners connected to TVHeadend >on a Pi4.

For several years I've been running TVHeadend on Pi4, with a PCTV 491e
DVB-S2 tuner and a Hauppauge WinTV DualHD DVB-T2 tuner, writing to a USB >caddy containing a spinning HDD. All the USB devices are connected to >separate USB sockets on the Pi: I'm not multiplexing several devices via a >hub onto a single USB socket on the Pi.

Mostly this works perfectly, but every now and again I get continuity
errors, maybe 50-150 per hour of recording, when normally I get zero for >DVB-S2, and 0 to 5 per hour for DVB-T2. The reported signal strength and SNR >when I get glitches (on the Status | Stream tab) seem the same as normal: >around 11-12 dB (SNR) and -30 dBm (strength) for satellite and around 25 dB
/ -42 dBm for terrestrial.

The HDD is a standard Sata 3 spinning HDD: Samsung HD161HJ, and the powered >USB caddy is a WAVLINK one. (*)

I'm wondering whether it's not so much a reception problem as a USB-transfer >problem, either from tuner to Pi or Pi to HDD.

Once the problem happens, it affects all tuners and all recordings made
until I reboot (without powering down Pi or HDD caddy). Rebooting sets the >Status | Stream error counters to zero, but more importantly seems to
prevent future errors occurring - for a few days or weeks. I've got into the >habit of rebooting the Pi every few days, just in case...

Before I go through the hassle of changing components (tuners, USB caddy >interface, HDD) one by one, I wanted to check whether anyone else with a >similar setup has experienced (and maybe fixed) this problem.

Are there any solid-state HDDs which are suitable for repeated writes and >then deletes of large files, such as you'd get on a PVR. I tend to use the >Pi's HDD just for temporary storage, copying and editing out commercials in >recorded programmes onto a Windows PC for long-term storage. Hence the Pi's >HDD does not need to be large - 100 GB is fine.

(*) I found out by bitter experience that a powered hub with a USB HDD (as >opposed to a USB-SATA interface in a caddy containing a SATA HDD) had >problems with the Pi 4: the Pi would not boot if the USB hub was powered on >at the time (as would happen if the power to everything came back on >simultaneously after a power cut). When the Pi had hung, it would resume >booting the instant the powered hub was unplugged either from the Pi's USB
or else from its power supply. This seems to be a Pi 4 "funny": the same USB >hub worked fine with a Pi 3B+. But that's an aside.

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?
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 02/01/2022 17:51, NY wrote:

I'm wondering whether it's not so much a reception problem as a
USB-transfer problem, either from tun

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


--
To ban Christmas, simply give turkeys the vote.
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

"Jan Panteltje" <pNaonStpealmtje@yahoo.com> wrote in message news:sqst34$o9l$1@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

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... :-)

My Pi4 8 GB with similar Toshiba harddisk on similar USB hub also boots normally.

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.
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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

"Jan Panteltje" <pNaonStpealmtje@yahoo.com> wrote in message >news:sqst34$o9l$1@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

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... :-)

My Pi4 8 GB with similar Toshiba harddisk on similar USB hub also boots
normally.

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

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

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.

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
http://panteltje.com/pub/radar_spectrum_sidebands.gif
measured 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.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 02.01.22 18:51, NY wrote:

I'm getting intermittent continuity errors on tuners connected to
TVHeadend on a Pi4.

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.
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 02/01/2022 19:58, NY wrote:

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.

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.
--
Dave
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

"The Natural Philosopher" <tnp@invalid.invalid> wrote in message news:sqsvqa$afc$1@dont-email.me...

On 02/01/2022 17:51, NY wrote:

I'm wondering whether it's not so much a reception problem as a
USB-transfer problem, either from tun

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

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).
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

"Dave" <dave@cyw.uklinux.net> wrote in message news:squp45$v53$1@dont-email.me...

On 02/01/2022 19:58, NY wrote:

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.

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.

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.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Mon, 3 Jan 2022 15:50:54 -0000
"NY" <me@privacy.invalid> wrote:

"Dave" <dave@cyw.uklinux.net> wrote in message >news:squp45$v53$1@dont-email.me...

On 02/01/2022 19:58, NY wrote:

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.

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.

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.

--
Basic
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)