Tvheadend

OK. Talking to myself here...

If I reboot and start tvheadend, I get an error downloading firmware:

Aug 28 11:37:20 tvburk tvheadend[2097]: linuxdvb: adapter 3 has multiple tuners 2 for type DVB-T, only one can be use
Aug 28 11:37:20 tvburk kernel: usb 4-1.1: DVB: adapter 3 frontend 1 frequency 0 out of range (42000000..1002000000)
Aug 28 11:37:19 tvburk kernel: mn88473 13-0018: firmware download failed=-32
Aug 28 11:37:19 tvburk kernel: mn88473 13-0018: downloading firmware from file 'dvb-demod-mn88473-01.fw'

If I power on, then run 'w_scan -fc -cFI', then start tvheadend, I see:

Aug 28 12:10:07 tvburk kernel: rtl2832 6-0010: i2c reg read failed -32
Aug 28 11:55:07 tvburk kernel: mn88473 6-0018: firmware already running
Aug 28 11:55:06 tvburk kernel: mn88473 6-0018: firmware parity check succeeded=0x20
Aug 28 11:55:06 tvburk kernel: mn88473 6-0018: downloading firmware from file 'dvb-demod-mn88473-01.fw'

And the adapter shows up:

I have the older version of this stick using the mn88472 driver and have exactly the same issue using DVB-T. It looks like the stick locks up or something.

OK. I guess there is some consolation in the fact that I am not alone...

Both adapters work now:

ug 28 15:11:10 tvburk tvheadend[4552]: http: 192.168.1.4: using ticket F40D7572A1DADFECC00EB13949AF85848A1A01C0 for /stream/channel/4411270327a9c6646c48096869b552aa
Aug 28 15:11:10 tvburk tvheadend[4552]: mpegts: 138MHz in MCA - tuning on Silicon Labs Si2168 : DVB-C #0
Aug 28 15:11:10 tvburk tvheadend[4552]: subscription: 004A: "HTTP" subscribing on channel "Nelonen MP4", weight: 100, adapter: "Silicon Labs Si2168 : DVB-C #0", network: "MCA", mux: "138MHz", provider: "MCA", service: "Nelonen MP4", profile="pass", hostname="192.168.1.4", client="VLC/2.2.1 LibVLC/2.2.1" 
Aug 28 15:11:29 tvburk tvheadend[4552]: http: 192.168.1.4: HTTP/1.1 GET /1_0_1_130_B_1_FFFF0000_0_0_0.png -- 1
Aug 28 15:11:32 tvburk tvheadend[4552]: http: 192.168.1.4: using ticket 968BD59242AC76F6D977BB44BC49880D110B9DAF for /stream/channel/85a80c57c1990828c6b5f71202f4f271
Aug 28 15:11:32 tvburk tvheadend[4552]: mpegts: 162MHz in MCA - tuning on Panasonic MN88473 : DVB-C #1
Aug 28 15:11:32 tvburk tvheadend[4552]: subscription: 004B: "HTTP" subscribing on channel "TV3", weight: 100, adapter: "Panasonic MN88473 : DVB-C #1", network: "MCA", mux: "162MHz", provider: "MCA", service: "TV3", profile="pass", hostname="192.168.1.4", client="VLC/2.2.1 LibVLC/2.2.1" 
Aug 28 15:11:34 tvburk tvheadend[4552]: TS: MCA/162MHz/TV3 Transport error indicator (total 1)
Aug 28 15:11:34 tvburk tvheadend[4552]: TS: MCA/162MHz/TV3: TELETEXT @ #948 Continuity counter error (total 1)
Aug 28 15:11:34 tvburk tvheadend[4552]: TS: MCA/162MHz/TV3: MPEG2VIDEO @ #772 Continuity counter error (total 1)

even if I see this:

Aug 28 14:21:23 tvburk tvheadend[4552]: mpegts: 130MHz in MCA - tuning on Panasonic MN88473 : DVB-C #1
Aug 28 14:21:23 tvburk tvheadend[4552]: linuxdvb: Panasonic MN88473 : DVB-C #1 - failed to tune [e=Invalid argument]
Aug 28 14:21:23 tvburk tvheadend[4552]: mpegts: 202MHz in MCA - tuning on Panasonic MN88473 : DVB-C #1
Aug 28 14:21:23 tvburk tvheadend[4552]: subscription: 0018: "epggrab" subscribing to mux "202MHz", weight: 4, adapter: "Panasonic MN88473 : DVB-C #1", network: "MCA", service: "Raw PID Subscription" 

FWIW, this is the driver I am using:

" 
tvburk:~ # modinfo mn88473
filename:       /lib/modules/4.1.15-8-default/kernel/drivers/staging/media/mn88473/mn88473.ko
firmware:       dvb-demod-mn88473-01.fw
license:        GPL
description:    Panasonic MN88473 DVB-T/T2/C demodulator driver
author:         Antti Palosaari <[email protected]>
srcversion:     38C33AEBA4CF9046C1EFAF4
alias:          i2c:mn88473
depends:        regmap-i2c
staging:        Y
intree:         Y
vermagic:       4.1.15-8-default SMP preempt mod_unload modversions
signer:         openSUSE Secure Boot Signkey
sig_key:        03:32:FA:9C:BF:0D:88:BF:21:92:4B:0D:E8:2A:09:A5:4D:5D:EF:C8
sig_hashalgo:   sha256

I also see this patch: https://patchwork.kernel.org/patch/9094681/

I did some debuging and found out, that newer kernel drivers are looking for a specific chip_id (0x03), whereas my device reports 0x08. The behavior changed in this commit:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/media/dvb-frontends/mn88473.c?id=7908fad99a6cc08a41c666d425df42809b34dce2

You could try this patch:

--- mn88473.c.orig         2016-09-17 23:02:36.207362191 +0200
+++ mn88473.c      2016-09-17 23:03:10.420786897 +0200
@@ -492,7 +492,7 @@

           dev_dbg(&client->dev, "chip id=%02x\n", uitmp);

-          if (uitmp != 0x03) {
+          if (uitmp != 0x03 && uitmp != 0x08) {
               ret = -ENODEV;
               goto err_regmap_0_regmap_exit;
           }

I have the same problem.

Also allowing chip ID 0x08 results in the stick reappearing in Tvheadend indeed.

However, I'm not able to tune in frequencies above roughly 500 MHz in DVB-C mode very well. The video becomes more and more choppy then. I'm running Tvheadend on Raspbian (Linux kernel 4.4) on a Raspberry Pi 2. By the way, this issue doesn't occur under Windows.

Can you confirm the same or is it working for you now?

Problem is that I have no DVB-C channels above 500MHz that I watch (or can watch). All channnels here are 130MHz to 250MHz

Still have not tried updating driver. I am running Open SUSe 42.1 FWIW

I'm not able to tune in frequencies above roughly 500 MHz in DVB-C mode very >> well.

Add patch:

Hi,
I had a similar issue in the past (only getting DVB-T) but was related with user/group permissions. I've forced Tvheadend to start with "hts" user and "video" group and got back the tuner.

If I'm allowed I take the opportunity to also make a question.
I'm unable to tune 3 freq/muxes between 215 to 270 Mhz they fail to scan, all other freq/muxes are ok, inclusive some within the range.
Not sure if it will solve but I want to try the patch above on r820t.ko.
I was able to compile r820t.ko, first just this module alone after applying the patch, replace it on Kernel using same rigths, it load ok but when open channels they don't open.
I've changed the approach and compile the whole V4L modules and the them copied just the r820t.ko and replace it on the kernel, it load ok, but then is unable to open channels, similar behavior as above.
Can you give me some lights on the compilation/installation, most likely I'm doing something wrong...
Thanks!

Hi
Patch helps for DVB-C. When scanning ranges above 500 MHz.

Eduard.

Hi Eduard,
Thanks for the feedback.
Any addiotional sugestion on this would be much appreciated.
Regards.

Эдуард Мяги wrote:

Hi
Patch helps for DVB-C. When scanning ranges above 500 MHz.

Eduard.

Hi Eduard,

Thank you very much. This patch really solved my continuity and transport issues with high frequencies using DVB-C. Hope it finds it way into the main kernel repository.

Kind regards,
Mart

Эдуард Мяги wrote:

I'm not able to tune in frequencies above roughly 500 MHz in DVB-C mode very >> well.

Add patch:

Only just discovered this patch, it has solved all my high frequency issues with the Astrometa device, thank you!

Please help me how do I install the patch?

German: Bitte helft mir wie installiere ich den patch?

114/5000
This patch requires a Linux kernel recompilation. Or at least kernel modules. In which Linux assembly do you work.

Ed68.

I've experienced the exact same issue with Raspbian on a Pi2. HD was working perfectly but now refuses to receive any signal whatsoever. I guess we need to wait for things to get patched downstream?

HD was working for the Astrometa on Raspbian?

Wow - Shocked. I have a Astrometa stick (mn88473 version not mn88472) working for DVB-T2 (HD) - Simply could not get this USB working for HD on OSMC or OpenELEC... just wasted a lot of time.

I only ever got this working for HD on a resized Offical Ubuntu 16.04 Desktop image [for the Raspberry Pi 2]. Think I may have copied the firmware to /lib/firmware? W-Scan worked fine. Tvheadend got the HD channels on a scan, and all 3 adaptors (DVB-T, DVB-T2, DVB-C) showup in Tvheadend (not just the Realtek adaptor which means only DVB-T works). But it is slow and unfortunately, although the latest Tvheadend works just great, KODI doesn't and I can't get it to launch from the lubuntu desktop I installed.
So unfortunately not suitable for a TV centre.
Will look into Raspbian for my stick... thanks.

I may have found a solution to this problem, which I faced wanting to use the MN88473 for DVB-T2. I experienced what looks like the same situation: everything worked, and after a restart (or more precisely a full power down and unplug from electrical power), I would only see the DVB-T adapter.
The w_scan would properly detect the MN88473 adapter though.

It came to my mind that maybe tvheadend started using the tuner and locked it before the firmware could be loaded.
I disabled:
- Over-the-air EPG
- Initial scan
- Idle scan

After doing so, I could not reproduce the problem making me think that the problem is solved. [I have another tuner that should take care of the Over-the-air EPG scan]

I am thinking that only disabling "Initial scan" may be the fix, but I didn't try this yet.

Just sharing hoping it helps somebody else.
[And still hoping it really fixes the problem]

Hi all,

Is this patch already in mainstream kernel ?

Thnx in advance.

Dave

No, patch not include in mainstream kernel.

Edvard.

Teddy Thomas wrote:

I may have found a solution to this problem, which I faced wanting to use the MN88473 for DVB-T2. I experienced what looks like the same situation: everything worked, and after a restart (or more precisely a full power down and unplug from electrical power), I would only see the DVB-T adapter.
The w_scan would properly detect the MN88473 adapter though.

This is a hardware problem. Not treated.

hi, i had the same problem and looked around the net and it looks like i have found a solution (https://forum.mythtv.org/viewtopic.php?t=1582). What you need to do is to simply rename frontends in /dev/dvb/adapterX
here are a few steps i made to make it work after restart.

1) set static adapter number to astrometa (in my case i choose adapter5)

create /etc/modprobe.d/astrometa.conf by
sudo nano /etc/modprobe.d/astrometa.conf

add to astrometa.conf

# Configuration file for Astrometa DVB-T2 USB receiver
# Note firmware dvb-demod-mn88473-01.fw in /lib/firmware

# force consistent adapter numbering
options dvb-usb-rtl28xxu adapter_nr=5

and save file. Now everytime you reboot, your astrometa will be adapter5

2) create file with the commands (i called mine swop_astrometa_frontend.sh) , put it somewhere, make it executable

#!/bin/bash
#swops frontend for Astrometa DVB-T/T2 usb dongle ID 15f4:0131 HanfTek 
# this is  necessary due to device having single demux
/etc/init.d/tvheadend stop &&
cd /dev/dvb/adapter5 && mv frontend0 frontend99 && mv frontend1 frontend0 &&
/etc/init.d/tvheadend start

3) put the following in /etc/rc.local immediately before the exit line at end of the file.

sudo /path_to_your_file/swop_astrometa_frontends.sh

after this reboot the machine, after it reboots, check by doing
ls /dev/dvb/adapter5

and you should get

demux0 dvr0 frontend0 frontend99 net0

i hope it helps someone.)

Yeah - can confirm this works for me! Crazy solution but thanks for posting. Hopefully a cleaner fix can come at some point?

This works ! Thank you so much!
EDIT: it fixes frontend problem for TV Headend, not the 'out of range' problem, typo in name of .sh script.

I copied above solution to LibreElec (Raspberry 1) :

-----
STEP 1 on Libreelec :

1) set static adapter number to astrometa (i also choose adapter5)

create /etc/modprobe.d/astrometa.conf by

nano /etc/modprobe.d/astrometa.conf

add to astrometa.conf

#Configuration file for Astrometa DVB-T2 USB receiver
#Note firmware dvb-demod-mn88473-01.fw in /lib/firmware

#force consistent adapter numbering
options dvb-usb-rtl28xxu adapter_nr=5

and i saved the file.

STEP 2

created the file /storage/swop_astrometa_frontend.sh ( /storage is writable on flash card, /etc/ is not in LE)

made it executable with

$ chmod 755 swop_astrometa_frontend.sh

The content of the script will be slightly different in Libreelec , due to slightly different service commands

$ nano swop_astrometa_frontend.sh

#!/bin/bash
#swops frontend for Astrometa DVB-T/T2 usb dongle ID 15f4:0131 HanfTek
#this is necessary due to device having single demux
systemctl stop service.tvheadend42 &&
cd /dev/dvb/adapter5 && mv frontend0 frontend99 && mv frontend1 frontend0 &&
systemctl start service.tvheadend42

STEP 3 is a bit different then above:

$ nano /storage/.config/autostart.sh

/storage/swop_astrometa_frontend.sh

REST is the same

after this reboot the machine, after it reboots, check by doing

ls /dev/dvb/adapter5

and you should get

demux0 dvr0 frontend0 frontend99 net0

All I can say is that mine still seems to work with Tvheaded 4.2.4 on OpenSuSE. Tried playing two different programmes on two different muxed and it works, but none of my DVB-C muxes are above 500MHz.