Recommendations for DVB-T2 USB tuner (for use with Pi 4 running TVHeadend)

[NY]

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.

[Theo]

NY <m...@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.

Theo

[Pancho]

On 10/08/2021 22:18, NY wrote:
> 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.
>

You could upgrade your TVs and run them all off WIFI/Ethernet from the
RPi/DVB streamer, then there wouldn't be any need for TVs to have their
own satellite feed, or ariel/satellite cables. The ariel cable could be
replaced with Ethernet cable.

Only the rPi would need satellite feeds, and that could be hidden away.

It's what I did, used a HTPC for each TV and effectively used the TV as
a dumb computer monitor. I was playing with using a RPi as the HTPC but
it wasn't powerful enough.

It worked well until I decided I just didn't watch broadcast TV and no
longer needed a licence or satellite.

[NY]

"Theo" <theom...@chiark.greenend.org.uk> wrote in message
news:V5h*bv...@news.chiark.greenend.org.uk...

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.


(*) That was the case even when we lived at another house which had a much
stronger signal which didn't even need an amplifier, so I think the SNR
figure being reported is fictitious.

[Dave]

On 10/08/2021 22:18, NY wrote:

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

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.

My only criticism is that the tuner gets very warm, even hanging in free
air supported by its cables. I have a powered USB hub with a 4A PSU so
power is not a problem.
--
Dave

[Theo]

NY <m...@privacy.invalid> wrote:
> 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?

TVHeadend is the recommended software:
https://www.raspberrypi.org/documentation/accessories/tv-hat.html

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

Given the RPi folks have a close relationship with Sony who make the silicon
(use Sony camera modules, assemble boards in Sony's factory) I would expect
solid engineering[1]. But I haven't used the Pi TV HAT myself.

Theo

[1] page 12: https://dvb.org/wp-content/uploads/2019/12/dvb-scene53.pdf

[A. Dumas]

NY wrote on 10-08-2021 at 23:18:
> (*) 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.

Ah-ha! NY = North Yorkshire :)

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

[Joerg Walther]

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.

- j -

--
Mail address is valid for a limited time only.

And now for something completely different...

[NY]

"Dave" <da...@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

Let's hope the "New model, with improved TV receiver for superior
over-the-air TV reception" is still Linux-compatible. I got bitten with the
491e DVB-S2. I bought two of them (thinking the house would have two
satellite feeds to the living room, in addition to the one for watching TV
live) and one was the old chipset which works, whereas the other is the new
chipset for which a driver was not yet available. I don't know whether
that's still the case: 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 downloaded because they are not
supplied with Raspbian. It's a shame that UNIX "compiles" all drivers into
the kernel rather than having them separately loaded on demand, as Windows
does.

[Theo]

A. Dumas <alex...@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.

There is a question of how you get the decryption keys, and the adapter
doesn't have a smartcard or other slot. But possibly you could have an
external smartcard interface (USB?) and talk to it that way.

A point to mention is the Pi TV HAT is only single stream, so you can't
record multiple muxes at once.

Theo

[Dave]

On 11/08/2021 13:52, NY wrote:
> "Dave" <da...@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.
--
Dave

[druck]

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.

---druck

[NY]

"druck" <ne...@druck.org.uk> wrote in message
news:sf1ao1$6n5$1...@dont-email.me...

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".

[NY]

"NY" <m...@privacy.invalid> wrote in message
news:sf1b8u$h6o$1...@dont-email.me...
> ... and for once product has been in a positive direction...

Grrr. Fingers disobeyed brain. I meant "progress".

[A. Dumas]

Theo wrote on 11-08-2021 at 15:07:
> A. Dumas <alex...@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.

I think that's true, but there has to be some planning & integration
between DVB adapter, smartcard reader and software. For Raspberry Pi,
the development seems to have halted straight when the TV HAT was
released. So, no news about American models, DVB-C support or smartcard
integration.

> 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."

[A. Dumas]

Joerg Walther wrote on 11-08-2021 at 14:14:
> 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.

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?

[Joerg Walther]

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.

[NY]

"A. Dumas" <alex...@dumas.fr.invalid> wrote in message
news:sf2b0f$30a$1...@dont-email.me...

Support for multiple channels *on the same mux* is not guaranteed. I used to
use Windows Media Centre to record TV programmes in the early days, and this
could only record one channel per tuner: it couldn't record two channels
from the same mux even though this should have been technically possible.

Other PVR programs I've used - NextPVR and TVHeadend - have no problem
recording multiple programmes from one mux via one tuner, so it was just WMC
that was antediluvian.

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.

On my RPi setup I've done test recordings where I record all of a multiplex
(all 24 or 40 Mbps of it), for three different muxes (using one DVB-S and
two DVB-T tuners). That seems to be pretty flawless. Likewise I've tried
setting to record multiple channels from the same mux simultaneously. That
again works fine.

[A. Dumas]

Joerg Walther wrote on 12-08-2021 at 10:48:
> 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.

That is what I meant, yes. Commercial station might be a better
description than private, despite the English term for the
non-commercial stations being "public broadcaster".

I'm in NL where we only get ARD/ZDF/WDR so I don't know these other ones
except by name. Just like their Dutch counterparts, they're probably
garbage but popular. So a TV adapter that can't do encrypted HD channels
might be of limited use to most Germans, just like I said originally.

[NY]

"Dave" <da...@cyw.uklinux.net> wrote in message

news:sf0jjg$2kj$1...@dont-email.me...

Well that was easy to set up! Almost *too* easy - what might I have
forgotten?

On my Windows PC, using the <IP>:9981 web site

- plug in the new device:
- two new tuners appear in Config | DVB Inputs | TV Adapters
- enable each one and set it to use the same Network as for the existing
PCTV 292e
- set the priorities so they are in the order (most to least preferable)
PCTV 491e sat, new Hauppauge #1 terr, new Hauppauge #2 terr, PCTV 292e terr
(I could set all the terrestrials to the same priority; I only used
different value to prove a point)
- went into Config | DVB Inputs | Services and clicked in turn on three
different services (channels) for the terrestrial network, to view them in
VLC
- Status showed that tuners were allocated in the order that I was expecting
based on priorities

With three instances of VLC on Windows playing three channels, streaming
over the network, the PC's CPU fan ramps up a gear, but CPU usage on the Pi
barely changes - 2% with nothing playing to 3-4% with three channels. That
was for 3 SD channels. I'll have to repeat it with three HD channels...


For some reason I originally set up two separate networks for the PCTV 292e
and the old Hauppauge, even though they were the same frequencies and
muxes - probably ignorance and piss-poor setup instructions. TVHeadend's
manual is somewhat lacking and describes *what* controls do but not *why*
you would use one thing rather than the other. They need a decent
many-to-one and one-to-many diagram to show multiple tuners mapped to one
service and then several of those services mapped to one channel. I can
probably delete the second network.

Luckily my local transmitter isn't Bilsdale so I'm not affected by the total
loss of all muxes following the fire. Sad to see it on the local news with
paint blistering and to imagine equipment and cabling which will all need to
be ripped out and replaced. It's a majestic sight from the Helmsley to Chop
Gate road, standing proud on the hillside - only passed that way a couple of
weeks ago. I can vaguely remember when I was little being taken to see Emley
Moor mast which had collapsed in 1969 when ice broke the guy ropes. I don't
remember the impact as regards loss of channels, but then we had a 405-line
TV in those days so BBC 1 at least would have been from Moorside Edge, but
ITV would have been down until they got a temporary transmitter going. And
of course no 625-line BBC1 or ITV, and no BBC 2 at all (it was never on 405
line).

[Mike]

In article <sf2nis$b4u$1...@dont-email.me>, NY <m...@privacy.invalid> 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. 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.

Not a USB/PiHat answer, but the NEC "EMMA" chipset used in Topfield/Humax? PVRs
have a "filter" where you can specify which streams you want the hardware
to decode and push across. Normally, it would be programmed to supply
the data/video/audio streams for the channel you are interested in, which
are buffered and shovelled to disk -- but there was a "proof of concept"
TAP for Topfield PVRs that reprogrammed the filter, so that the filters
were opened wide, to allow recording the WHOLE mux to disk at once.

It required some equivalent interference in the playback of the .REC file
which contained multiple video/audio streams -- now suddenly the filters
need to be loaded to screen out the unwanted data coming from disk, on
playback!

As the Topfield is twin-tuner, that meant in theory, recording
two entire muxes to disk was possible at a hardware level, without
overtaxing the CPU at all.

So it does seem to be a hardware feature, going back some years, to
at least attempt to throttle the amount of data being flung around.
--
--------------------------------------+------------------------------------
Mike Brown: mjb[-at-]signal11.org.uk | http://www.signal11.org.uk

[The Natural Philosopher]

On 11/08/2021 21:16, NY wrote:
> "druck" <ne...@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.
>

In general you may need to recompile *driver modules* against the kernel.

But this is handled as part of the automated installation process

What you *may* have to do is install firmware for the DVB system.

>
> (*) 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".

--
"In our post-modern world, climate science is not powerful because it is
true: it is true because it is powerful."

Lucas Bergkamp

[The Natural Philosopher]

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.

--
“I know that most men, including those at ease with problems of the
greatest complexity, can seldom accept even the simplest and most
obvious truth if it be such as would oblige them to admit the falsity of
conclusions which they have delighted in explaining to colleagues, which
they have proudly taught to others, and which they have woven, thread by
thread, into the fabric of their lives.”

― Leo Tolstoy

[Andy Burns]

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]

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
usually faster than USB.


--
"A point of view can be a dangerous luxury when substituted for insight
and understanding".

Marshall McLuhan

[Andy Burns]

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.

[NY]

"Andy Burns" <use...@andyburns.uk> wrote in message
news:inn12b...@mid.individual.net...

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]

NY wrote:

> 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?

Basically yes, clients can set a filter of "NONE".

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

More sophisticated tuner/demuxer chips on cards than dongles? Maybe
tuner-only and no demuxer at all on USB? I'm not saying no USB dongles
exist with filters, just none that I've used, OTOH I have used a PCI
card that was little more than a USB hub plus USB tuners on a card, it
didn't have filters.

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

have you got dstat installed? int and csw columns would be interesting
when streaming one prog vs the whole mux.

I suspect a lot more drivers use zero-copy techniques nowadays, rather
than constantly rebuffering between user and kernel address space.

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

Yes, mythTV never supported recording or streaming a full mux, but could
handle multiple programmes from a mux concurrently, I did 12 recordings
"because I could", skyQ calls that progress.

[The Natural Philosopher]

On 13/08/2021 12:14, NY wrote:
> "Andy Burns" <use...@andyburns.uk> wrote in message
> news:inn12b...@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.
>

yes. And 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.

> 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]

The Natural Philosopher wrote:

> I am fairly sure my PCI card satellite tuner wasnt preferential as to
> the channel within any given mux.

Depends what the software asks of the V4L API

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

nothing will stop it, if that's what an app requests, what I am saying
is that ...

the tuner will tune to the required frequency, and get e.g. a raw 40Mbps
data stream, if the app opens the relevant /dev/dvb/* device and doesn't
specify a filter, it will get that raw stream, it might use all of it,
or might throw most of it away. Or possibly the V4L API simiulates the
filtering by doing the demux in software, I haven't checked.

But if a DVB device supports HARDWARE FILTERING, the PCI card itself can
demux the stream and throw away the uninteresting parts of the stream
before they even get passed to the kernel driver, let alone to the app,
so the app might only have to deal with the e.g. 2Mbps stream of a
programme it is actually interested in.

USB devices don't typically do the hardware filtering, PCI ones
typically do.

<https://www.kernel.org/doc/html/v4.16/media/kapi/dtv-demux.html#>