Can anyone recommend a device similar to the 292e which is supported by Raspian on a Pi. I've got kernel 5.4. I don't want to have to upgrade to kernel 5.10 because I found that this introduced faults in the 491e
satellite decoder: I've forgotten the details now, but I remember having to regress to an older image of the system drive with kernel 5.4 (thank
goodness I image the SD card every so often).
My present setup has:
- PCTV 491e DVB-S2
- PCTV 292e DVB-T2
- Hauppauge WinTV Nova DVB-T (not T2)
The Hauppauge is getting very flaky: it suddenly starts throwing thousands
of continuity errors, even when the signal is good and it's been working fine.
So I'm looking to replace it. I'd go for a second PCTV 292e, but Amazon
seem
to have stopped selling it, and I can't find it for sale anywhere else.
Can anyone recommend a device similar to the 292e which is supported by Raspian on a Pi. I've got kernel 5.4. I don't want to have to upgrade to kernel 5.10 because I found that this introduced faults in the 491e
satellite decoder: I've forgotten the details now, but I remember having to regress to an older image of the system drive with kernel 5.4 (thank
goodness I image the SD card every so often).
I'd go for another satellite tuner instead of terrestrial (*), but it would mean a major upgrade to my dish (to fit an LNB with more than two feeds)
and
then running an extra cable to the living room.
NY <me@privacy.invalid> wrote:
Can anyone recommend a device similar to the 292e which is supported by
Raspian on a Pi. I've got kernel 5.4. I don't want to have to upgrade to
kernel 5.10 because I found that this introduced faults in the 491e
satellite decoder: I've forgotten the details now, but I remember having
to
regress to an older image of the system drive with kernel 5.4 (thank
goodness I image the SD card every so often).
Does it need to be USB?
https://www.raspberrypi.org/blog/raspberry-pi-tv-hat/
should be supported out of the box, and less of a lottery as you get with
the
bottom-end USB sticks.
My present setup has:
- PCTV 491e DVB-S2
- PCTV 292e DVB-T2
- Hauppauge WinTV Nova DVB-T (not T2)
The Hauppauge is getting very flaky: it suddenly starts throwing thousands
of continuity errors, even when the signal is good and it's been working fine.
So I'm looking to replace it. I'd go for a second PCTV 292e, but Amazon
seem
to have stopped selling it, and I can't find it for sale anywhere else.
Can anyone recommend a device similar to the 292e which is supported by Raspian on a Pi. I've got kernel 5.4. I don't want to have to upgrade to kernel 5.10 because I found that this introduced faults in the 491e
satellite decoder: I've forgotten the details now, but I remember having to regress to an older image of the system drive with kernel 5.4 (thank
goodness I image the SD card every so often).
I'd go for another satellite tuner instead of terrestrial (*), but it would mean a major upgrade to my dish (to fit an LNB with more than two feeds)
and
then running an extra cable to the living room.
(*) Terrestrial reception is good but not flawless, because of a nearby
hill. And as today's news about the fire at Bilsdale proves, transmitters (very, very occasionally) can go off air for long periods of time.
Does the Pi TV hat have support for TVHeadend - does it still map to devices of the form /dev/dvb/adapter0/dvr0? Or does it need special PVR software to talk to it?
I'd love to know what the intermittent problem is with my Hauppauge device. Normally the two DVB-T devices report (in TVHeadend) very similar signal strengths of about -40 dBm. But sometimes the Hauppauge reports about -60
dBm (a lot weaker). And yet the two devices are fed from the same aerial amplifier. The Hauppauge has always been a bit "weird": the signal-to-noise ratio (*) is reported as 0.2 dB (signal and noise fairly similar level!!!) whereas the PCTV 292e reports a more healthy 20 dB. I've tried swapping cables in case one amplifier-to-tuner cable is dodgy, but this makes no difference.
For people outside the UK, in mainland Europe specifically, I don't
think the Pi TV HAT is a good solution because it doesn't decrypt and
most DVB streams in Europe are encrypted.
For people outside the UK, in mainland Europe specifically, I don't
think the Pi TV HAT is a good solution because it doesn't decrypt and
most DVB streams in Europe are encrypted. See e.g. this subthread https://www.raspberrypi.org/blog/raspberry-pi-tv-hat/#comment-1479661
I'm running a similar setup to yours on a Pi2 with a 491e for DVB-S2 and a Hauppauge WinTV-dual HD for DVB-T2.
The WinTV-dual seems to still be available from the usual outlets. It
seems to use the same chipset as the 292e and IIRC the same firmware
worked. The USB interface uses 'bulk' mode which some claim reduces the
load on the USB network.
"Dave" <dave@cyw.uklinux.net> wrote in message news:sf07vr$hg5$1@dont-email.me...
I'm running a similar setup to yours on a Pi2 with a 491e for DVB-S2
and a Hauppauge WinTV-dual HD for DVB-T2.
The WinTV-dual seems to still be available from the usual outlets. It
seems to use the same chipset as the 292e and IIRC the same firmware
worked. The USB interface uses 'bulk' mode which some claim reduces
the load on the USB network.
Looks good. I'd have bought a dual-tuner device when I bought the 292e
if such a thing had been available.
I presume it's this one
https://www.amazon.co.uk/Hauppauge-WinTV-dual-HD-Freeview-broadcasts/dp/B011Z7I0JY/ref=sr_1_3
On 11/08/2021 13:52, NY wrote:
the PCTV engineer on the support thread where this was being discussed
was talking about people having to rebuild their kernel to include the
driver. When I investigated, this looked non-trivial and required a lot
of dependent packages to be It's a shame that UNIX "compiles" all drivers
into the kernel rather than having them separately loaded on demand, as
Windows does.
Raspbian is Linux not Unix. Linux has supported loadable kernel modules
for decades, and rebuilding the kernel is not necessary. I suspect this is not the area of expertise of the PCTV engineer.
the PCTV engineer on the support thread
where this was being discussed was talking about people having to
rebuild their kernel to include the driver. When I investigated, this
looked non-trivial and required a lot of dependent packages to be
It's a shame
that UNIX "compiles" all drivers into the kernel rather than having them separately loaded on demand, as Windows does.
... and for once product has been in a positive direction...
A. Dumas <alexandre@dumas.fr.invalid> wrote:
For people outside the UK, in mainland Europe specifically, I don't
think the Pi TV HAT is a good solution because it doesn't decrypt and
most DVB streams in Europe are encrypted. See e.g. this subthread
https://www.raspberrypi.org/blog/raspberry-pi-tv-hat/#comment-1479661
I'm not familiar with the details, but do you know if decryption is
something that needs to be supported by the DVB adapter? I'd have thought the adapter produces a data stream, and if (part of) the stream happens to
be encrypted then you need to do a software decryption before you try and display it.
A point to mention is the Pi TV HAT is only single stream, so you can't record multiple muxes at once.
A. Dumas wrote:
For people outside the UK, in mainland Europe specifically, I don't
think the Pi TV HAT is a good solution because it doesn't decrypt and
most DVB streams in Europe are encrypted.
That's not quite true, it varies with every country. In Germany for
example nearly everything is unencrypted with the exception of some HD streams of private stations and, of course, Pay TV.
Theo wrote on 11-08-2021 at 15:07:
A point to mention is the Pi TV HAT is only single stream, so you can't
record multiple muxes at once.
In that announcement post I linked, a RPi engineer said: "Yes. Single
tuner. But viewing/recording multiple channels from the same mux is supported."
But if I were to buy DVB-T/2 receiver I would want to watch HD channels,
not just SD. By "private" I think you mean anything that's not ARD/ZDF?
Maybe WDR/NDR etc are unencrypted HD, too?
A. Dumas wrote:
But if I were to buy DVB-T/2 receiver I would want to watch HD channels,
not just SD. By "private" I think you mean anything that's not ARD/ZDF?
Maybe WDR/NDR etc are unencrypted HD, too?
They all are unencryped. By private I mean Sat1, RTL, Pro7 etc. Their SD programs are unencrypted, the HD ones are and you have to pay to be able
to watch these.
On 11/08/2021 13:52, NY wrote:
"Dave" <dave@cyw.uklinux.net> wrote in message
news:sf07vr$hg5$1@dont-email.me...
I'm running a similar setup to yours on a Pi2 with a 491e for DVB-S2 and >>> a Hauppauge WinTV-dual HD for DVB-T2.
The WinTV-dual seems to still be available from the usual outlets. It
seems to use the same chipset as the 292e and IIRC the same firmware
worked. The USB interface uses 'bulk' mode which some claim reduces the
load on the USB network.
Looks good. I'd have bought a dual-tuner device when I bought the 292e if
such a thing had been available.
I presume it's this one
https://www.amazon.co.uk/Hauppauge-WinTV-dual-HD-Freeview-broadcasts/dp/B011Z7I0JY/ref=sr_1_3
Yep. Bought mine five months ago.
Do DVB-T/S tuners always send the full mux to the PVR software, and let that >software select the PIDs that it wants to record/view. Or does the protocol >allow the tuner to be given the PIDs that are required, so only they (and no >others) are sent over USB? In other words, getting the tuner rather than the >software to do the filtering, to reduce USB bandwidth.
"druck" <news@druck.org.uk> wrote in message news:sf1ao1$6n5$1@dont-email.me...
On 11/08/2021 13:52, NY wrote:
the PCTV engineer on the support thread where this was being
discussed was talking about people having to rebuild their kernel to
include the driver. When I investigated, this looked non-trivial and
required a lot of dependent packages to be It's a shame that UNIX
"compiles" all drivers into the kernel rather than having them
separately loaded on demand, as Windows does.
Raspbian is Linux not Unix. Linux has supported loadable kernel
modules for decades, and rebuilding the kernel is not necessary. I
suspect this is not the area of expertise of the PCTV engineer.
Ah, thanks. I took the PCTV engineer's word as gospel, not least because
the last time I worked on UNIX (on ICL servers) you definitely *did*
have to rebuild the kernel, and the installation script for one of the packages I was working on copied a driver in place and then rebuilt the kernel to include it. But time has marched on, and for once product has
been in a positive direction (*) - loadable kernel modules sound the
dog's bollocks.
(*) I always remember my maths teacher, a card-carrying professional
cynic, telling us "progress is a vector quantity - it has direction as
well as size so sometimes it goes backwards".
Do DVB-T/S tuners always send the full mux to the PVR software, and let
that software select the PIDs that it wants to record/view.
On 12/08/2021 09:53, NY wrote:
Do DVB-T/S tuners always send the full mux to the PVR software, and
let that software select the PIDs that it wants to record/view.
I believe that to be the case.
The Natural Philosopher wrote:
On 12/08/2021 09:53, NY wrote:
Do DVB-T/S tuners always send the full mux to the PVR software, and
let that software select the PIDs that it wants to record/view.
I believe that to be the case.
USB tuners do tend to send the full 40+ Mbps mux contents to the
software, and let them chuck away what they don't need.
However PCI tuners tend to have hardware PID filters so that only the requsted streams (audio/video/subtitles etc) are sent to the driver and
on to the software, cuts down the interrupt rate, probably matters less
now, but 15 years ago when I was running mythTV inside a Xen VM, high interrupt rates were a problem.
The Natural Philosopher wrote:
I cant see any reason why a PCI card would generate more interrupts than
a USB one.
Other way round. USB is delivering the whole 38Mbps mux, and PCI is just delivering a 2Mbps programme from within it Makes a difference between about 200 and about 1000 interrupts per second above background level here (PCIe) Of course I can choose to stream the whole MUX to VLC and let it choose which programme to watch.
In the end once tuned to a mux its simply all about dragging great chunks
of, presumably just-as-buffered, data off.
Depends if the card/dongle is with or without hardware to filter which DVB packets need sending to the O/S.
There is no requirement for 'real time' performance. And a PCI bus is
usually faster than USB.
I cant see any reason why a PCI card would generate more interrupts than
a USB one.
In the end once tuned to a mux its simply all about dragging
great chunks of, presumably just-as-buffered, data off.
There is no requirement for 'real time' performance. And a PCI bus is--- SoupGate-Win32 v1.05
usually faster than USB.
Andy Burns wrote:
The Natural Philosopher wrote:
I cant see any reason why a PCI card would generate more interrupts
than a USB one.
Other way round. USB is delivering the whole 38Mbps mux, and PCI is
just delivering a 2Mbps programme from within it Makes a difference
between about 200 and about 1000 interrupts per second above
background level here (PCIe) Of course I can choose to stream the
whole MUX to VLC and let it choose which programme to watch.
In the end once tuned to a mux its simply all about dragging great
chunks of, presumably just-as-buffered, data off.
Depends if the card/dongle is with or without hardware to filter which
DVB packets need sending to the O/S.
There is no requirement for 'real time' performance. And a PCI bus is
usually faster than USB.
Do PCI cards with PID filtering have a "promiscuous mode" (to use
network traffic-capture terminology) by which controlling software can
ask for the whole stream as opposed to specific PIDs?
I think TNP's question about more interrupts might have been sort-of
asking why PCI cards tend to be designed with PID filtering whereas USB
ones aren't, when USB bandwidth might be more limited and more prone to saturation than PCI bandwidth.
On my Raspberry Pi TVHeadend setup, I've testing it with several
instances of VLC being served over Ethernet to a Windows PC, one
instance per USB-connected DVB tuner, with each VLC instance recording
the whole stream to disk. Not something you'd do every day, but I was interested to see the effect. The CPU usage on the Pi rose from 2% to
about 5% (so it was hardly breaking into a sweat).
LAN usage was about
150 Mbps, as you'd expect with about 24 or 40 Mbps from each of four
muxes, plus some networking overhead. The Windows PC that was running
all these VLC sessions was struggling a bit: CPU usage was about 80% and
the CPU fan was running continuously at jet-aircraft speed.
"Andy Burns" <usenet@andyburns.uk> wrote in message news:inn12bFmgq7U1@mid.individual.net...
The Natural Philosopher wrote:
I cant see any reason why a PCI card would generate more interrupts
than a USB one.
Other way round. USB is delivering the whole 38Mbps mux, and PCI is
just delivering a 2Mbps programme from within it Makes a difference
between about 200 and about 1000 interrupts per second above
background level here (PCIe) Of course I can choose to stream the
whole MUX to VLC and let it choose which programme to watch.
In the end once tuned to a mux its simply all about dragging great
chunks of, presumably just-as-buffered, data off.
Depends if the card/dongle is with or without hardware to filter which
DVB packets need sending to the O/S.
There is no requirement for 'real time' performance. And a PCI bus is
usually faster than USB.
Do PCI cards with PID filtering have a "promiscuous mode" (to use
network traffic-capture terminology) by which controlling software can
ask for the whole stream as opposed to specific PIDs?
I think TNP's question about more interrupts might have been sort-of
asking why PCI cards tend to be designed with PID filtering whereas USB
ones aren't, when USB bandwidth might be more limited and more prone to saturation than PCI bandwidth.
On my Raspberry Pi TVHeadend setup, I've testing it with several
instances of VLC being served over Ethernet to a Windows PC, one
instance per USB-connected DVB tuner, with each VLC instance recording
the whole stream to disk. Not something you'd do every day, but I was interested to see the effect. The CPU usage on the Pi rose from 2% to
about 5% (so it was hardly breaking into a sweat). LAN usage was about
150 Mbps, as you'd expect with about 24 or 40 Mbps from each of four
muxes, plus some networking overhead. The Windows PC that was running
all these VLC sessions was struggling a bit: CPU usage was about 80% and
the CPU fan was running continuously at jet-aircraft speed.
I am fairly sure my PCI card satellite tuner wasnt preferential as to
the channel within any given mux.
Linux and tvheadend only 'know' about /dev/dvb*...I cant see why, even
if the card has got 'per channel' selection built in, that would stop it delivering more than one channel at a time via two instances of opening
the device.
| Sysop: | Rempala |
|---|---|
| Location: | Richlands, NC |
| Users: | 106 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 40:32:14 |
| Calls: | 205 |
| Files: | 6 |
| Messages: | 111,121 |