Some Muxes Fail Scan on Newer Version

Jamoi Holland

Hi all,

I had a stable first gen ModelB RaspberryPi running RaspBMC with Tvheadend server, installed between late-2013 and early-2014. I had to manually add a driver for my TV tuner. Then it started acting slow, and I am about to use the Tvheadend in anger o stream TV around the house, so in preparation to replace it with a ModelB+ I created another installation on separate SD card with OpenElec. I installed Tvheadend server through the unsupported (clue?) add-on repository of OpenElec, which gave me Tvheadend version 3.9.something. The driver seems to already be present in a read-only part of the file system. The old Tvheadend server on RaspBMC reported version 0.0.0-unknown somewhat annoyingly.

If I flick between the installations with the same hardware (except the SD card I guess!) and the same mux configuration, on the old RaspBMC and older Tvheadend, they all work fine. On the OpenElec with newer version of Tvheadend, only 2 out of 5 work. Same frequencies, modulation, hi/low, etc. The tuner is Hauppauge WinTV-NOVA-T DVB-T (70019) over USB via a powered hub.

Am I now running something seriously unsupported through OpenElec? Or did so many things change in Tvheadend that my tuner is now not being accessed properly? The GUI for adding adaptors, networks and muxes has changed dramatically so all the old guides you find are out of date also. Any help on this would be much appreciated. And if there is a better recommendation of RaspberryPi distribution/OS to use for Tvheadend server, please let me know - ideally it will have a nice GUI like the Kodi-variants so that the RaspberryPi running Tvheadend server can also be a Tvheadend client and play other media from my NAS.

Thanks!

mpmc

I have the exact same tuner as yourself and have used it on a PI B, PI B+ and a PI 2 without issue.

The only time I've experienced scan failures is due to incorrect tuning params, You need to make sure you're entering all available details and not leave it set to AUTO. IIRC 3.9 requires most values & not AUTO, 3.4 would allow you to get away with using AUTO.

Example mux info:

!example.png!

Jamoi Holland

Thanks for the reply Mark. What a coincidence with the same tuner! I'll share an example mux that works in the old, but not in the new. In the old I can't work out how to show the mux config in the web GUI, but I found the mux config by command line! (Also, here's the listing for my transmitter: http://www.ukfree.tv/transmitters/tv/Sutton_Coldfield)

Old (THE version unknown)
{
"quality": 100,
"enabled": 1,
"status": "Bursty FEC",
"transportstreamid": 4165,
"originalnetworkid": 9018,
"network": "West Midlands",
"frequency": 650000000,
"initialscan": 0,
"bandwidth": "8MHz",
"constellation": "QAM64",
"transmission_mode": "8k",
"guard_interval": "1/32",
"hierarchy": "NONE",
"fec_hi": "2/3",
"fec_lo": "1/2"

}

New (THE version 3.9.2690)

!greenshot_2015-04-20_07-07-04.png!

mpmc

Jamoi Holland wrote:
> Thanks for the reply Mark. What a coincidence with the same tuner! I'll share an example mux that works in the old, but not in the new. In the old I can't work out how to show the mux config in the web GUI, but I found the mux config by command line! (Also, here's the listing for my transmitter: http://www.ukfree.tv/transmitters/tv/Sutton_Coldfield) >
>Old (THE version unknown)
> {
> "quality": 100,
> "enabled": 1,
> "status": "Bursty FEC",
> "transportstreamid": 4165,
> "originalnetworkid": 9018,
> "network": "West Midlands",
> "frequency": 650000000,
> "initialscan": 0,
> "bandwidth": "8MHz",
> "constellation": "QAM64",
> "transmission_mode": "8k",
> "guard_interval": "1/32",
> "hierarchy": "NONE",
> "fec_hi": "2/3",
> "fec_lo": "1/2"
> }
>
>
>New (THE version 3.9.2690)
>

> !greenshot_2015-04-20_07-07-04.png!

Ah Sutton Coldfield, I can just about receive that Transmitter using the same aerial that's pointed at Waltham, although the signal is very weak.

I've done a bit of testing for you.

It would appear to be an issue with the Hauppauge NOVA-T on the RPI2 exclusively as I'm just able to receive 650MHz on Sutton using the NOVA-*TD* (the dual version of the NOVA-T / same chip) on my Microserver although VLC cannot render an image correctly.

This is where it gets interesting the NOVA-*T* on the RPI 2 fails to receive anything on 650MHz, it will however receive 674MHz although once again it breaks up due to poor signal.

However, I also tried my Astrometa DVB-T2 RTL2832 and thatis able to tune and receive both 650MHz & 674MHz on the RPI2 and is able to render an image without breakup!.

- Below are my notes I took while testing and a bonus screenshot of VLC playing 650MHz on the RPI2 using the Astrometa stick!

+*650MHz* Microserver using Hauppauge NOVA-TD DiBcom 7000PC (it's the same tuner as the NOVA-T only there are two..) = OK No issues except poor signal.+

2015-04-20 19:02:51.148 mpegts: 650MHz in Sutton Test - tuning on DiBcom 7000PC : DVB-T #0 2015-04-20 19:02:51.170 opentv-ausat: registering mux 650MHz in Sutton Test 2015-04-20 19:02:51.202 subscription: 1007: "HTTP" subscribing to mux "650MHz", weight: 10, adapter: "DiBcom 7000PC : DVB-T #0", network: "Sutton Test", service: "Raw PID Subscription", hostname="192.168.1.40", client="VLC/2.2.0 LibVLC/2.2.0" *2015-04-20 19:03:00.863 mpegts: 650MHz in Sutton Test scan complete* 2015-04-20 19:03:10.968 subscription: 1007: "HTTP" unsubscribing, hostname="192.168.1.40", username="VLC/2.2.0 LibVLC/2.2.0"

+*650MHz* Raspberry PI 2 using Hauppauge NOVA-T DiBcom 7000PC = Failure.+

2015-04-20 19:06:54.501 mpegts: 650MHz in Sutton Coldfield Test RPI2 - tuning on DiBcom 7000PC : DVB-T #0 2015-04-20 19:06:54.501 opentv-skyit: registering mux 650MHz in Sutton Coldfield Test RPI2 2015-04-20 19:06:54.525 subscription: 0039: "HTTP" subscribing to mux "650MHz", weight: 10, adapter: "DiBcom 7000PC : DVB-T #0", network: "Sutton Coldfield Test RPI2", service: "Raw PID Subscription", hostname="192.168.1.40", client="VLC/2.2.0 LibVLC/2.2.0" 2015-04-20 19:06:59.000 mpegts: 650MHz in Sutton Coldfield Test RPI2 - scan no data, failed 2015-04-20 19:07:04.782 linuxdvb: DiBcom 7000PC : DVB-T #0 - poll TIMEOUT 2015-04-20 19:07:10.866 subscription: 0039: "HTTP" unsubscribing, hostname="192.168.1.40", username="VLC/2.2.0 LibVLC/2.2.0"

+*674MHz* Raspberry PI 2 using Hauppauge NOVA-T DiBcom 7000PC = OK No issues except poor signal.+

2015-04-20 19:09:30.170 subscription: 003F: "HTTP" unsubscribing, hostname="192.168.1.40", username="VLC/2.2.0 LibVLC/2.2.0" 2015-04-20 19:10:40.717 mpegts: 674MHz in Sutton Coldfield Test RPI2 - tuning on DiBcom 7000PC : DVB-T #0 2015-04-20 19:10:40.718 subscription: 0043: "HTTP" subscribing to mux "674MHz", weight: 10, adapter: "DiBcom 7000PC : DVB-T #0", network: "Sutton Coldfield Test RPI2", service: "Raw PID Subscription", hostname="192.168.1.40", client="VLC/2.2.0 LibVLC/2.2.0" 2015-04-20 19:11:09.475 subscription: 0043: "HTTP" unsubscribing, hostname="192.168.1.40", username="VLC/2.2.0 LibVLC/2.2.0"

+*650MHz* Raspberry PI 2 using Astrometa Realtek RTL2832 = No issues, this tuner appears to be more sensitive & is able to decode the very weak signal.+

2015-04-20 19:19:31.000 mpegts: 650MHz in Sutton Coldfield Test RPI2 - tuning on Realtek RTL2832 (DVB-T) : DVB-T #0 2015-04-20 19:19:31.004 subscription: 0004: "epggrab" subscribing to mux "650MHz", weight: 4, adapter: "Realtek RTL2832 (DVB-T) : DVB-T #0", network: "Sutton Coldfield Test RPI2", service: "Raw PID Subscription" 2015-04-20 19:19:31.545 subscription: 0006: "HTTP" subscribing to mux "650MHz", weight: 10, adapter: "Realtek RTL2832 (DVB-T) : DVB-T #0", network: "Sutton Coldfield Test RPI2", service: "Raw PID Subscription", hostname="192.168.1.40", client="VLC/2.2.0 LibVLC/2.2.0

!RPI2.png!

It's an odd one indeed!

Hope this helps you somehow :)

Jamoi Holland

Wow, thanks for the extensive research Mark! :)

Some of that output is way over my head to be honest. I'm a techie, but very new to this TV stuff. My only query is that my "old that works" and "new that doesn't work" scenarios are both on the same first gen RPI. I haven't actually moved over to a RPI Model B yet. Between both scenarios, the only differences are the SD card, the OS installed, and the version of TVheadend.

This is getting beyond my level of hackery to be honest. before I had kids I'd have hacked all night at learning then making things work, but these days I want something that works a bit easier. Is there a good recommendation for OS and tuner hardware for a RPI Model B (not actually a gen 2) that is known to work? Or is it really all trial and error?

mpmc

Jamoi Holland wrote:

> Wow, thanks for the extensive research Mark! :)

It's no problem.
>
> Some of that output is way over my head to be honest. I'm a techie, but very new to this TV stuff. My only query is that my "old that works" and "new that doesn't work" scenarios are both on the same first gen RPI. I haven't actually moved over to a RPI Model B yet. Between both scenarios, the only differences are the SD card, the OS installed, and the version of TVheadend.
>

I've installed 3.4 on the same Pi2 & I can receive something on 650MHz but once again the signal is far to weak for it to get a list of channels.

I did however try adding the following to /etc/modprobe.d/options.conf:-

options dvb_usb force_pid_filter_usage=1 disable_rc_polling=1
i>

Click the above link to comments some others have made about this problem on IRC - You may want to try doing it on Openelec but the file location is different as pointed out by sraue in that link.

However adding the above options causes too much power drain & causes my Pi2 to crash - Looks like a power issue on my end, I unfortunately cannot find my spare powered hub to test right now & I'm too groggy to go look (Yay insomnia).

> This is getting beyond my level of hackery to be honest. before I had kids I'd have hacked all night at learning then making things work, but these days I want something that works a bit easier.Is there a good recommendation for OS and tuner hardware for a RPI Model B (not actually a gen 2) that is known to work? Or is it really all trial and error?

I personally use a barebones raspbian install "Raspbian-ua-netinstall" & build my own tvheadend packages on the Pi.

But I don't use the Pi's as my tvheadend server I use a HP Microserver - The Pi works great as frontend though.

As for tuners..

I know the pctv nanostick t2 290e (quite hard to find now, replaced by the 292e which is supported on some kernels but not all) does work okay on the Pi & it has the added benefit of being able to receive HD services, however it will put pressure on the Pi & may cause errors - I had to overclock & set higher nice value for it to work without issues. Also note that the PCTV 290e expects the full 480Mbps usb bus so if you plan on watching & recording you may run into issues especially if you stream a HD service over a network - you may just get away with local playback & recording but YMMV.

Any cheapo RTL2832 stick from china should also work & we know from my tests that it can receive a very weak 650MHz. I have another RTL2832 unbranded (DVB-T only) stick that I've used in the past on Waltham without any issues. You can find these all over "Ebay" / "Amazon" at various prices.

But most tuners should work provided they're supported by the Rpi kernel.

HTH :)

Jamoi Holland

Thanks again Mark.

I've found a RTL2832-based stick with a coax socket from eBay, so that's one approach to attempt once it arrives.

Meanwhile, the IRC chat was interesting. In the directories specified I could not find options.conf or options-dvb.conf, in fact I couldn't find them anywhere. Then I Google'd and saw posts like "this" which seem to suggest that OpenElec is not as tweakable as we'd maybe like. Then someone replies saying "you can add the files" If I try adding the files then using some of the options from the IRC chat, how do I know they are being used by Tvheadend? Can you show the running config once booted? Does it log to a specific file? Otherwise I could spend hours trying all combinations of filenames and options!

ProfYaffle

Bugger, I hate being referenced three years later :-)

Yes, you can add options to the modprobe.d directory in those conf files as described.

Try modprobe -c | grep <module>... should work on OE.

mpmc

Tvheadend doesn't use them as such.

But take a look "here" to see more options.

You create the files if they don't exist, you'll know if they're active because you should see something about filtering in dmesg.

I don't personally use Openelec, so I don't know much about how it works I'm afraid.

Edit: The Prof uses OE I think so he should be able to help more :)

ProfYaffle

Clarification: I use OE as a client, but tvheadend (and tuners) all live on a 'buntu box. So don't put me on any pedestal here! :-)

Jamoi Holland

Thanks again Mark/Prof for your assistance. I see I'm a black sheep trying to use something a bit random for the Tvheadend server! I've now also tried a third OS, going for Raspian and installing Tvheadend from the repository using apt-get, plus using the 1.20 firmware copied over manually (that's as technical as I get, build and make and compiling etc are beyond me). This is as similar to my working setup as I can get now. That's given me Tvheadend v3.4, which scans the few muxes I configured, but gives no actual services. This 3.4 version seems to have few options for forcing scans and such, and is reporting zero signal strength. Then I tried OSMC, which has an app store to install Tvheadend. That didn't even start scanning the muxes I configured, and again had no option to force scan.

Losing faith somewhat, I booted up on old XP laptop and grabbed the old Hauppauge drivers and software, to see if my aerial was even still working! It found all the channels through a scan in the WinTV software, so the aerial and tuner are fine, it's just the OS/firmware/Tvheadend part of this which I'm failing to get correct.

I'd put a server-type "full Linux" machine there as a Tvheadend server, but the two places where I have coax sockets aren't the best places to physically have a server (no room in the TV cabinet in the lounge, and the spare room is the little one's playroom), hence me trying to use a little Pi attached to the back of a TV.

With a house to refurbish top to bottom, little one no1 running around, little one no2 on its way, I only have so much tinkering time before I need sleep, so I'll probably wait now and try this RTL2832 if it has more chance of playing nicely with the Pi on one of the OS (Raspian, OpenElec, OSMC, whatever)

ProfYaffle

Only other thought that immediately bubbles up, then, is SAT>IP. From what I understand, that would allow you to have a small tuner where the coax connections are, but then relay the signal over LAN (Wifi or wired, the latter obviously preferable) to your PVR and/or other clients. I haven't played with it, though. Seems folks are moving towards the Inverto IDL-400 and clones (Grundig GSS.BOX, Telestar Digibit R1) and perexg has been re-writing the firmware to make improvements, so they play nicely with tvheadend now.

Raspbian tvheadend... there's probably a 3.9 version out there, or it is genuinely easy enough to build with Autobuild.sh (famous last words...!). There's an old 3.9.1879 in the unstable repo if nothing else.

@Mark - you're a Pi man, aren't you? Have you any Raspbian debs?

mpmc

Prof Yaffle wrote:
> Only other thought that immediately bubbles up, then, is SAT>IP. From what I understand, that would allow you to have a small tuner where the coax connections are, but then relay the signal over LAN (Wifi or wired, the latter obviously preferable) to your PVR and/or other clients. I haven't played with it, though. Seems folks are moving towards the Inverto IDL-400 and clones (Grundig GSS.BOX, Telestar Digibit R1) and perexg has been re-writing the firmware to make improvements, so they play nicely with tvheadend now.
>
> Raspbian tvheadend... there's probably a 3.9 version out there, or it is genuinely easy enough to build with Autobuild.sh (famous last words...!). There's an old 3.9.1879 in the unstable repo if nothing else.
>

>@Mark - you're a Pi man, aren't you? Have you any Raspbian debs?

Yes I have plenty thanks, I can upload the latest if needed, but if 3.4 works with the same device/hardware then it's still obviously something to do with 3.9 & the Pi - I'll have to setup debugging on the Pi2 & compare it with the Microserver, see what's different in the tuning debug & report it to perexg.

ProfYaffle

There are Pi debs here as well - I'd forgotten this thread:

https://tvheadend.org/d/2471-no-new-builds-for-armhf-raspberrypi