Better to be
systemctl stop tvheadend
Checking again I realized that also the firmware has been loaded successfully.
root@osmc:~$ dmesg | grep "usb 1-1" [ 2.876370] usb 1-1: new high-speed USB device number 2 using xhci-hcd [ 3.026211] usb 1-1: New USB device found, idVendor=15f4, idProduct=0131 [ 3.026225] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 3.026230] usb 1-1: Product: dvbt2 [ 3.026235] usb 1-1: Manufacturer: astrometadvbt2 [ 4.768192] usb 1-1: dvb_usb_v2: found a 'Astrometa DVB-T2' in warm state [ 4.837746] usb 1-1: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer [ 4.879005] usb 1-1: DVB: registering adapter 0 frontend 0 (Realtek RTL2832 (DVB-T))... [ 4.879121] usb 1-1: DVB: registering adapter 0 frontend 1 (Panasonic MN88473)... [ 4.926030] usb 1-1: dvb_usb_v2: schedule remote query interval to 400 msecs [ 4.935636] usb 1-1: dvb_usb_v2: 'Astrometa DVB-T2' successfully initialized and connected [ 16.228999] usb 1-1: DVB: adapter 0 frontend 0 frequency 0 out of range (174000000..862000000) [ 17.786897] usb 1-1: DVB: adapter 0 frontend 1 frequency 0 out of range (42000000..1002000000) root@osmc:~$ dmesg | grep "downloading firmware" [ 16.937852] mn88473 3-0018: downloading firmware from file 'dvb-demod-mn88473-01.fw'
Nevertheless, at least w_scan still does not find any muxes.
Running “tvheadend -u osmc -g video” during scan periodically give a warning like this, even for known muxes:
2018-03-07 09:51:49.376 [ INFO] mpegts: 586MHz in DVB-T Netzwerk - tuning on Panasonic MN88473 #0 : DVB-T #1 2018-03-07 09:51:49.376 [ INFO] subscription: 0072: "scan" subscribing to mux "586MHz", weight: 6, adapter: "Panasonic MN88473 #0 : DVB-T #1", network: "DVB-T Netzwerk", service: "Raw PID Subscription" 2018-03-07 09:51:50.679 [WARNING] linuxdvb: Panasonic MN88473 #0 : DVB-T #1 - poll TIMEOUT 2018-03-07 09:51:54.375 [ INFO] mpegts: 586MHz in DVB-T Netzwerk - scan no data, failed 2018-03-07 09:51:54.375 [ INFO] subscription: 0072: "scan" unsubscribing
Is this warning relevant in terms of causing problems? Otherwise I would potentially try a different antenna.
The message could be due to a poor signal. The signal strength indication in the TVH webui may give a clue but it doesn’t always work. Then there’s a ‘LNA’ switch in the adapters setup screen. I’ve no idea whether that does anything but I’ve ticked it anyway.
Again, you are better to use
systemctl start tvheadend which starts tvheadend in the correct way.
From a general perspective I agree to better use the systemctl command to run TVH, but in the end it doesn’t change anything. Since I temporarily need to run it with IPv6 enabled, it is easier to start it right from the cli (with additional ‘-6’)
The idea of having a (too) poor signal is not completely unlikely. But while already using an active antenna near to the window it should at least find something as it did earlier before even with a passive antenna indoor.
Regarding LNA I assume this is related to an additional Low Noise Amplifier, which I would rather expect in a satellite system. Apart from that, the active antenna has external power, assuming that the dongle isn’t even capable of phantom powering the antenna.
OK. It’s just that I got in a tangle once starting tvh from cli when it was already running from systemd.
Only you can be sure about signal strength. I am able to check mine by confirimng the stick works fine on a RPi with the same aerial.
I believe it is still a driver and not a signal / antenna issue. To dig a bit deeper I just installed “usbutils” and subsequently the output of “usb-devices” indicates a driver just being loaded for the RT2832, but not for the MN88473.
Unfortunately, no success here with the media_build kernel and TerraTec Cynnergy S2 USB Box (DVB-S).
$ uname -a Linux fernseher 3.14.29-59-osmc #1 SMP Sun Mar 4 05:08:41 UTC 2018 aarch64 GNU/Linux
While installing the kernel I got these warnings:
Hmm. There is a symbolic link /lib/modules/3.14.29-59-osmc/build However, I can not read it: No such file or directory Therefore, I am deleting /lib/modules/3.14.29-59-osmc/build Hmm. The package shipped with a symbolic link /lib/modules/3.14.29-59-osmc/source However, I can not read the target: No such file or directory Therefore, I am deleting /lib/modules/3.14.29-59-osmc/source
lsusb never finishes, indicative of a kernel crash, tvheadend does not show any adapter.
The most popular adapter on the Vero 4K is the OSMC branded DVB-T2 dongle. I’ve backported
support for the second tuner which handles DVB-T2 and DVB-C in this commit.
So the “DVB-T2 dongle” from the store can also be used for DVB-C? There is no mention of this in the store…
But very few countries provide unencrypted DVB-C. We don’t advertise the feature as we suspect a lot of people would then try and connect it to encrypted DVB-C services and be quite disappointed.
Partly adding the current output of “usb-devices” here, which to my understanding points to the problem with the MN88473 demodulator:
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=15f4 ProdID=0131 Rev=01.00 S: Manufacturer=astrometadvbt2 S: Product=dvbt2 C: #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=dvb_usb_rtl28xxu I: If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In addition, I’m still struggling with the hot-plug mechanism. When plugging the stick into a running Vero the whole device crashes, with only the remote receiver being plugged in as second USB device. According to this I also tried “usbreset” and
echo 0 > /sys/bus/usb/devices/1-1/authorized echo 1 > /sys/bus/usb/devices/1-1/authorized
but all failed.
It seems I misinterpreted you original instructions.
I thought that you were recommending the 3.14.29-62-osmc kernel for the OSMC Dongle.
And found that it still did not access the /T2 channels.
Out of curiosity I installed the 3.14.29-59-osmc kernel and find that I now have working DVBT/T2 on the OSMC dongle .
Aside from the long term stability of the TVHeadend software, it would appear that this closes the issue for me.
I don’t think you did as this clearly says that the first listed kernel (3.14.29-62-osmc) is indeed supposed to fix the OSMC dongle:
For those with a non OSMC tuner, or using a different DVB system, please try this kernel instead:
where “this” refers to the 3.14.29-59-osmc kernel.
It’s been discussed in another thread; but I’m not sure how Richard’s system is currently configured.
I know, but this is still confusing as it’s unclear what exactly he tested and what you subsequently integrated in the latest stable kernel. When you indeed integrated the 59 kernel features he supposedly tested, then you should have integrated the media_build tree backport (as to your first post).
Can you confirm that?
Yes, with fixes for MN88473 which I manually applied to media_build.
Too bad, since that means that the current media_build backport doesn’t improve the situation for all the Hauppauge/PCTV sticks out there (like the 292e) which had at least been fully recognized with an earlier backport.
This also means there are no more test kernels that need testing regarding potential expanded DVB device support, right?
@sam_nazarko since installing the March update on Vero 4k (official osmc tuner) I dont even have SD channels, no devices showing in tvheadend either.
I had installed the test firmware. Any ideas what to try?
Please try updating again. It could take an hour for this update to reach your mirror.
Kernel should be -66 now.
When everyone is on the same kernel, I should be able to make sense of things.