Hi all,
I recently got a USB adapter "Astrometa DVB-T2" that I would like to use with VDR. It comprises two frontends:
/dev/dvb/adapter0/frontend0: Realtek RTL2832 (DVB-T) /dev/dvb/adapter0/frontend1: Panasonic MN88473 (DVB-T2 and DVB-C)
I guess it is similar to this one; just a slightly different plastic case with some more ventilation holes: http://blog.palosaari.fi/2014/09/naked-hardware-18-astrometa-amdvb-t2-v2.htm...
The hardware appears to work fine, once I copied the /lib/firmware/dvb-demod-mn88473-01.fw from somewhere. The firmware upload has failed at least once on the Raspberry Pi 2 (using Linux 4.9.59), but never on another machine that runs a 4.13.0 kernel.
I did not yet get the infrared remote control to produce anything in evtest.
With dvbv5-zap (after running dvbv5-scan), I can tune into DVB-T2 channels like this:
dvbv5-zap -a 0 -f 1 -c dvb_channel.conf 'Yle TV1 HD' -r
After this, I can play the video and audio stream on the Raspberry Pi 2:
omxplayer /dev/dvb/adapter0/dvr0
Unless I explicitly specify the options -a 0 -f 1, then dvbv5-zap will fail to find any DVB-T2 senders, because it apparently defaults to frontend0, which is DVB-T only.
In VDR 2.3.8, I have only been able to view DVB-T from the first frontend.
When I did a trick and renamed /dev/dvb/adapter0/frontend1 to frontend0 before starting VDR, VDR no longer complained that the DVB-T2 channels (which I converted from the dvb_channel.conf to channels.conf with dvb-format-convert) not being available, but it did not seem to receive anything from these channels either.
Also, after using dvbv5-scan or dvbv5-zap, I sometimes have to invoke w_scan to "reset" the hardware so that VDR can receive DVB-T channels.
I would like to receive and record DVB-T and DVB-T2 on this setup. I am willing to try patches or do some programming myself, but I would appreciate some hints to get started.
Marko
On Sun, Nov 26, 2017 at 07:21:58PM +0200, Marko Mäkelä wrote:
Hi all,
I recently got a USB adapter "Astrometa DVB-T2" that I would like to use with VDR. It comprises two frontends:
/dev/dvb/adapter0/frontend0: Realtek RTL2832 (DVB-T) /dev/dvb/adapter0/frontend1: Panasonic MN88473 (DVB-T2 and DVB-C)
Apart from these files, in /dev/dvb/adapter0 I can see the following: demux0 dvr0 net0
It seems to me that the dvbdevice.c of VDR 2.3.8 assumes that all these files exist for all frontends. But there is no demux1, dvr1, or net1 on my system.
In dvbdevice.h, I think that the macros DEV_VIDEO, DEV_DVB_VIDEO, DEV_DVB_AUDIO are unused and the definitions could be removed.
For cDvbTuner::SetFrontend() the cDvbTuner::adapter and cDvbTuner::frontend are already fixed. For my device, frontend0 should only be valid for DVB-T, while frontend1 is valid for DVB-T2 and DVB-C. How to handle these known-invalid combinations? By 'return true'? Or should I rather hack cDvbTuner so that it opens a file descriptor for each frontend, and then chooses the appropriate one in cDvbTuner::SetFrontend() based on frontendType?
Last, I noticed that there exists cDvbDevice::BondDevices() for bonding multiple DVB-S devices to the same dish. I guess it is not feasible to extend this to my DVB-T/DVB-T2 device, because I would suppose that unlike the DVB-S devices, my USB stick does not support concurrent reception from both frontends at the same time.
Marko
On 27.11.2017 19:55, Marko Mäkelä wrote:
On Sun, Nov 26, 2017 at 07:21:58PM +0200, Marko Mäkelä wrote:
Hi all,
I recently got a USB adapter "Astrometa DVB-T2" that I would like to use with VDR. It comprises two frontends:
/dev/dvb/adapter0/frontend0: Realtek RTL2832 (DVB-T) /dev/dvb/adapter0/frontend1: Panasonic MN88473 (DVB-T2 and DVB-C)
Apart from these files, in /dev/dvb/adapter0 I can see the following: demux0 dvr0 net0
It seems to me that the dvbdevice.c of VDR 2.3.8 assumes that all these files exist for all frontends. But there is no demux1, dvr1, or net1 on my system.
That's right, VDR assumes that if there is a frontend1 there is also demux1 and dvr1.
In dvbdevice.h, I think that the macros DEV_VIDEO, DEV_DVB_VIDEO, DEV_DVB_AUDIO are unused and the definitions could be removed.
DEV_DVB_VIDEO is still used by the dvb[sh]ddevice plugins.
For cDvbTuner::SetFrontend() the cDvbTuner::adapter and cDvbTuner::frontend are already fixed. For my device, frontend0 should only be valid for DVB-T, while frontend1 is valid for DVB-T2 and DVB-C. How to handle these known-invalid combinations? By 'return true'? Or should I rather hack cDvbTuner so that it opens a file descriptor for each frontend, and then chooses the appropriate one in cDvbTuner::SetFrontend() based on frontendType?
Which devices does VDR create at startup? Please post the related log entries.
Last, I noticed that there exists cDvbDevice::BondDevices() for bonding multiple DVB-S devices to the same dish. I guess it is not feasible to extend this to my DVB-T/DVB-T2 device, because I would suppose that unlike the DVB-S devices, my USB stick does not support concurrent reception from both frontends at the same time.
Device bonding is only meant for DVB-S devices.
Klaus
Hallo Klaus,
On Tue, Nov 28, 2017 at 11:28:13AM +0100, Klaus Schmidinger wrote:
On 27.11.2017 19:55, Marko Mäkelä wrote:
On Sun, Nov 26, 2017 at 07:21:58PM +0200, Marko Mäkelä wrote:
Hi all,
I recently got a USB adapter "Astrometa DVB-T2" that I would like to use with VDR. It comprises two frontends:
/dev/dvb/adapter0/frontend0: Realtek RTL2832 (DVB-T) /dev/dvb/adapter0/frontend1: Panasonic MN88473 (DVB-T2 and DVB-C)
Apart from these files, in /dev/dvb/adapter0 I can see the following: demux0 dvr0 net0
It seems to me that the dvbdevice.c of VDR 2.3.8 assumes that all these files exist for all frontends. But there is no demux1, dvr1, or net1 on my system.
That's right, VDR assumes that if there is a frontend1 there is also demux1 and dvr1.
In dvbdevice.h, I think that the macros DEV_VIDEO, DEV_DVB_VIDEO, DEV_DVB_AUDIO are unused and the definitions could be removed.
DEV_DVB_VIDEO is still used by the dvb[sh]ddevice plugins.
Sorry, I should have thought of output plugins. rpihddevice does not refer to any of these.
For cDvbTuner::SetFrontend() the cDvbTuner::adapter and cDvbTuner::frontend are already fixed. For my device, frontend0 should only be valid for DVB-T, while frontend1 is valid for DVB-T2 and DVB-C. How to handle these known-invalid combinations? By 'return true'? Or should I rather hack cDvbTuner so that it opens a file descriptor for each frontend, and then chooses the appropriate one in cDvbTuner::SetFrontend() based on frontendType?
Which devices does VDR create at startup? Please post the related log entries.
Attached are two complete logs from /var/log/messages for plain VDR 2.3.8 startup.
On both startup attempts, channels.conf (attached) contains only DVB-T2 entries, and the default channel is free-to-view (YLE TV1 HD). The channels.conf was converted by dvb-format-convert version 1.12.3: dvb-format-convert -I DVBV5 -O VDR dvb_channel.conf channels.conf
The first attempt is with the /dev/dvb/adapter0 as is. VDR expectedly claims that it cannot tune to the channel with the DVB-T frontend.
The second startup is for a tweak where I removed /dev/dvb/adapter0/frontend0 and renamed frontend1 to frontend0. On this startup, VDR will not complain anything, but it will not find any signal either. It properly detects the MN88473, but perhaps improperly claims that it provides DVB-T along with DVB-T2 and DVB-C.
I think we should try to first fix the scenario of the second startup. I tried to read the output of
strace dvbv5-zap -a 0 -f 1 -c dvb_channel.conf 'YLE TV1 HD' -r
but I did not find anything special (or did not know what to look for).
Side note: I got the idea of renaming frontend1 to frontend0 from a forum post where it appeared to work for some DVB-C users: https://www.vdr-portal.de/forum/index.php?thread/129861-gel%C3%B6st-problem-...
Best regards,
Marko
On 28.11.2017 21:12, Marko Mäkelä wrote:
Hallo Klaus,
On Tue, Nov 28, 2017 at 11:28:13AM +0100, Klaus Schmidinger wrote:
On 27.11.2017 19:55, Marko Mäkelä wrote:
On Sun, Nov 26, 2017 at 07:21:58PM +0200, Marko Mäkelä wrote:
Hi all,
I recently got a USB adapter "Astrometa DVB-T2" that I would like to use with VDR. It comprises two frontends:
/dev/dvb/adapter0/frontend0: Realtek RTL2832 (DVB-T) /dev/dvb/adapter0/frontend1: Panasonic MN88473 (DVB-T2 and DVB-C)
Apart from these files, in /dev/dvb/adapter0 I can see the following: demux0 dvr0 net0
It seems to me that the dvbdevice.c of VDR 2.3.8 assumes that all these files exist for all frontends. But there is no demux1, dvr1, or net1 on my system.
That's right, VDR assumes that if there is a frontend1 there is also demux1 and dvr1.
In dvbdevice.h, I think that the macros DEV_VIDEO, DEV_DVB_VIDEO, DEV_DVB_AUDIO are unused and the definitions could be removed.
DEV_DVB_VIDEO is still used by the dvb[sh]ddevice plugins.
Sorry, I should have thought of output plugins. rpihddevice does not refer to any of these.
For cDvbTuner::SetFrontend() the cDvbTuner::adapter and cDvbTuner::frontend are already fixed. For my device, frontend0 should only be valid for DVB-T, while frontend1 is valid for DVB-T2 and DVB-C. How to handle these known-invalid combinations? By 'return true'? Or should I rather hack cDvbTuner so that it opens a file descriptor for each frontend, and then chooses the appropriate one in cDvbTuner::SetFrontend() based on frontendType?
Which devices does VDR create at startup? Please post the related log entries.
Attached are two complete logs from /var/log/messages for plain VDR 2.3.8 startup.
On both startup attempts, channels.conf (attached) contains only DVB-T2 entries, and the default channel is free-to-view (YLE TV1 HD). The channels.conf was converted by dvb-format-convert version 1.12.3: dvb-format-convert -I DVBV5 -O VDR dvb_channel.conf channels.conf
The first attempt is with the /dev/dvb/adapter0 as is. VDR expectedly claims that it cannot tune to the channel with the DVB-T frontend.
The second startup is for a tweak where I removed /dev/dvb/adapter0/frontend0 and renamed frontend1 to frontend0. On this startup, VDR will not complain anything, but it will not find any signal either. It properly detects the MN88473, but perhaps improperly claims that it provides DVB-T along with DVB-T2 and DVB-C.
Well, from the information that VDR gets from the driver, it does support DVB-T, -T2 and -C:
frontend 0/0 provides DVB-T,DVB-T2,DVB-C with QPSK,QAM16,QAM32,QAM64,QAM128,QAM256 ("Panasonic MN88473")
If this is not correct, I assume it's a driver problem.
But since the channel you are initially tuning to is DVB-T2, anyway, it doesn't really matter if VDR thinks the frontend can handle DVB-T, too.
I'm afraid I can't say why tuning fails, though.
Klaus
On Wed, Nov 29, 2017 at 11:13:24AM +0100, Klaus Schmidinger wrote:
The second startup is for a tweak where I removed /dev/dvb/adapter0/frontend0 and renamed frontend1 to frontend0. On this startup, VDR will not complain anything, but it will not find any signal either. It properly detects the MN88473, but perhaps improperly claims that it provides DVB-T along with DVB-T2 and DVB-C.
Well, from the information that VDR gets from the driver, it does support DVB-T, -T2 and -C:
frontend 0/0 provides DVB-T,DVB-T2,DVB-C with QPSK,QAM16,QAM32,QAM64,QAM128,QAM256 ("Panasonic MN88473")
If this is not correct, I assume it's a driver problem.
I made some further experiments today. It turns out that frontend1 indeed supports both DVB-T and DVB-T2 (and presumably DVB-C).
Furthermore, with the trick sudo mv /dev/dvb/adapter0/frontend1 /dev/dvb/adapter0/frontend0 I got VDR to display both DVB-T and DVB-T2 programs. The only difference from my previous attempts was that this time, I did not rename the old frontend0 to frontend2. The only frontend device descriptor that existed in the file system was frontend0.
The reception is not the best here (especially on windy or rainy days, in particular with DVB-T2), and it is possible that during my previous attempts, the DVB-T2 signal was too weak to get the tuner to lock on it in reasonable time. Also, the USB stick might not have the best analog signal path or the best tuner.
So, the good news is that the device indeed works with this little tweak. It probably is not worth the effort to implement something in dvbdevice.c that would allow this device to work without tweaking /dev/dvb/.
Now I will only have to figure out how to get the remote control to work.
Best regards,
Marko
On Sat, Dec 02, 2017 at 09:57:37PM +0200, Marko Mäkelä wrote:
Now I will only have to figure out how to get the remote control to work.
The Astrometa driver in the Linux kernel exposes a /dev/input/event device that did not react to any of my remote control units, including the one that was bundled with the USB stick.
I would guess that slightly different devices with the same USB ID have been bundled with different types of remote control units, and the Linux kernel might support a different type of RCU.
It turns out that /dev/lirc0 would expose the raw pulses. I configured LIRC so that I can use the RC5 based unit that was bundled with the old Hauppauge Nova-T PCI card. It is a much better choice; an almost perfect match for VDR.
I may post configurations later when I have completed the full setup. My plan is to set up a Raspbian-based system that records on the local MicroSD card but can also access a USB hard disk or an NFS server that would be powered up on demand.
Marko
Sun, Dec 03, 2017 at 09:16:31PM +0200, Marko Mäkelä wrote:
On Sat, Dec 02, 2017 at 09:57:37PM +0200, Marko Mäkelä wrote:
Now I will only have to figure out how to get the remote control to work.
The Astrometa driver in the Linux kernel exposes a /dev/input/event device that did not react to any of my remote control units, including the one that was bundled with the USB stick.
I figured out that the package ir-keytable needs to be installed.
After I added the line * * hauppauge.toml as the first non-comment line of /etc/rc_maps.cfg I was able to use my Hauppauge RCU with the USB DVB stick. It is also recognized by vdr-plugin-remote (vdr -Premote).
This is nice, because "sudo apt install inputlirc lirc" would consume more than 85 megabytes due to some Python and X11 dependencies.
One problem remains. If I hold a button down, "ir-keytable -t" will keep reporting key_down and key_up events. I also feel that it is discarding at least every second RC5 packet (occasionally discarding more), no matter which --period or --delay settings I try. I had a crude patch for the cx88 kernel driver years ago to fix the key-repeat (for example, so that holding the volume button will adjust the volume as quickly as possible). Now it could be time to port the patch to the new infrastructure and submit it.
Marko
-
Klaus Schmidinger -
Marko Mäkelä