• Recommendations for DVB-T2 USB tuner (for use with Pi 4 running TVHeade

    From NY@3:770/3 to All on Tue Aug 10 22:18:07 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to me@privacy.invalid on Wed Aug 11 10:14:47 2021
    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.

    Theo
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Pancho@3:770/3 to All on Wed Aug 11 10:16:45 2021
    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.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From NY@3:770/3 to Theo on Wed Aug 11 10:30:12 2021
    "Theo" <theom+news@chiark.greenend.org.uk> wrote in message news:V5h*bvory@news.chiark.greenend.org.uk...
    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.

    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.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dave@3:770/3 to All on Wed Aug 11 11:15:22 2021
    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
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From A. Dumas@3:770/3 to All on Wed Aug 11 12:45:30 2021
    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
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to me@privacy.invalid on Wed Aug 11 11:22:13 2021
    NY <me@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
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Joerg Walther@3:770/3 to A. Dumas on Wed Aug 11 14:14:44 2021
    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...
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to A. Dumas on Wed Aug 11 14:07:09 2021
    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.

    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
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From NY@3:770/3 to Dave on Wed Aug 11 13:52:32 2021
    "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

    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.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Dave@3:770/3 to All on Wed Aug 11 14:33:36 2021
    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.
    --
    Dave
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From NY@3:770/3 to druck on Wed Aug 11 21:16:50 2021
    "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".
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to All on Wed Aug 11 21:08:30 2021
    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
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From NY@3:770/3 to me@privacy.invalid on Wed Aug 11 21:26:12 2021
    "NY" <me@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".
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From A. Dumas@3:770/3 to Theo on Thu Aug 12 07:19:11 2021
    Theo wrote on 11-08-2021 at 15:07:
    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.

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From A. Dumas@3:770/3 to Joerg Walther on Thu Aug 12 07:22:49 2021
    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?

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From NY@3:770/3 to A. Dumas on Thu Aug 12 09:53:05 2021
    "A. Dumas" <alexandre@dumas.fr.invalid> wrote in message news:sf2b0f$30a$1@dont-email.me...
    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."

    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Joerg Walther@3:770/3 to A. Dumas on Thu Aug 12 10:48:52 2021
    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.

    - j -

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

    And now for something completely different...

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From A. Dumas@3:770/3 to Joerg Walther on Thu Aug 12 11:55:20 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From NY@3:770/3 to Dave on Thu Aug 12 14:32:09 2021
    "Dave" <dave@cyw.uklinux.net> wrote in message news:sf0jjg$2kj$1@dont-email.me...
    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.

    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).
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Mike@3:770/3 to me@privacy.invalid on Thu Aug 12 20:16:34 2021
    In article <sf2nis$b4u$1@dont-email.me>, NY <me@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
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Fri Aug 13 09:41:32 2021
    On 11/08/2021 21:16, NY wrote:
    "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.

    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
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Fri Aug 13 09:42:47 2021
    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
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Andy Burns@3:770/3 to The Natural Philosopher on Fri Aug 13 10:31:41 2021
    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.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Andy Burns on Fri Aug 13 10:57:53 2021
    On 13/08/2021 10:31, Andy Burns wrote:
    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.




    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
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From NY@3:770/3 to Andy Burns on Fri Aug 13 12:14:52 2021
    "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.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Andy Burns@3:770/3 to The Natural Philosopher on Fri Aug 13 11:49:46 2021
    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.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Andy Burns@3:770/3 to All on Fri Aug 13 12:42:44 2021
    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.
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to All on Fri Aug 13 16:59:01 2021
    On 13/08/2021 12:14, NY wrote:
    "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.

    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.





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

    Marshall McLuhan
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Andy Burns@3:770/3 to The Natural Philosopher on Fri Aug 13 17:21:53 2021
    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#>
    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)