Hi list,
since some time (1-2 years) I noticed that the DVB-T channels do not show EPG anymore. I'm not sure what is the root-cause: either it was the migration of French DVB-T to HD (in 2016) or an update of VDR.
Anyway, this morning I took the time to figure out what is wrong and here is what I found.
In short, the channel-ID generated from the one received in the EIT does not correspond to a known channel-ID from the channel list, and VDR drops the whole section:
In cEIT::cEIT (from eit.c) we see
tChannelID channelID(Source, getOriginalNetworkId(), getTransportStreamId(), getServiceId()); cChannel *Channel = Channels->GetByChannelID(channelID, true);
and channel is NULL in my case.
I added some debug prints to GetByChannelID() in the search loop:
printf("sid: %d == %d, %s, %s %d\n", Channel->Sid(), sid, (const char *)ChannelID.ToString(), (const char *)Channel->GetChannelID().ToString(), Channel->GetChannelID() == ChannelID);
And here is an example of what I get:
sid: 517 == 517, T-8442-2-517, T-0-506-517 0
The internal channel ID of vdr reads T-0-506-517. 517 is the SID, 506 is the radio-channel frequency in MHz. This is the right internal channel for this EIT-section.
The EIT-channel-ID is telling me that 8442 is the original network ID and 2 might be the radio-channel ID.
I tweaked the operator==() of ChannelID to make it work, but not in a contributable manner.
How should this be fixed correctly?
Is this a regression introduced somewhere?
Can it be solved by configuration?
Thanks for any help.
best regards, -- Patrick.
On 25.02.2018 15:26, Patrick Boettcher wrote:
Hello Patrick,
where did the channel with ID T-0-506-517 come from in the first place?
What happens if you delete that channel from VDR's channel list and tune to the transponder? Does it create the channel with the correct ID?
Klaus
Hi Klaus,
thank you for your reply.
On Mon, 26 Feb 2018 16:58:20 +0100 Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
I ran dvbv5-scan with -O vdr and it gave me the line. I manually copied it to channels.conf. Upon vdr start I saw that VDR was updating the PIDs.
Here's what came out of it:
France 2:586000:B8C23G32M64S0T8Y0:T:0:120=27:0; \ 130=fra@122,131=qad@122,132=qaa@122:0;140=fra,142=fra :0:257:0:0:0
(\ and line break added by me)
Good idea.
I deleted the channel and switched to another channel on the same transponder.
Nothing happens. VDR does not re-"find" the channel. VDR is set up to "Add New Transponders".
Running scan -c (current transponder) gives:
0x0000 0x0101: pmt_pid 0x006e GR1 B -- France 2 (running) 0x0000 0x0104: pmt_pid 0x0136 GR1 B -- France 4 (running) 0x0000 0x0105: pmt_pid 0x01fe GR1 B -- France Ô (running) 0x0000 0x0106: pmt_pid 0x0262 GR1 B -- franceinfo: (running) 0x0000 0x0111: pmt_pid 0x00d2 GR1 -- F3 Paris Ile-de-France (running) 0x0000 0x0170: pmt_pid 0x02c6 R1 TFL -- BFM Paris (running) dumping lists (6 services) France 2 (0x0101) 01: PCR == V V 0x0078 SUB 0x008e France 4 (0x0104) 01: PCR == V V 0x0140 SUB 0x0156 France Ô (0x0105) 01: PCR == V V 0x0208 SUB 0x021c franceinfo (0x0106) 01: PCR == V V 0x026c SUB 0x0280 F3 Paris Ile-de-France (0x0111) 01: PCR == V V 0x00dc A 0x00e6 (fre) 0x00e7 (qad) 0x00e8 (qaa) SUB0x00f2 BFM Paris (0x0170) 01: PCR == V V 0x02d0
(attached is the complete output with -vvv.)
Any idea?
-- Patrick.
Hello Patrick,
your scan doesn't contain the NIT, which is where the transponder innformation is broadcast. Can you scan that, too, please?
Klaus
On Tue, 27 Feb 2018 16:54:35 +0100 Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
Hi Klaus,
NIT attached (from another multiplex with the same symptoms).
best regards, -- Patrick.
On 27.02.2018 17:58, Patrick Boettcher wrote:
Transport_stream_ID: 1 (0x0001) Original_network_ID: 8442 (0x20fa) [= >>ERROR: not (yet) defined... Report!<<] reserved_1: 15 (0x0f) Transport_descriptor_length: 205 (0x00cd)
DVB-DescriptorTag: 90 (0x5a) [= terrestrial_delivery_system_descriptor] descriptor_length: 11 (0x0b) Center frequency: 0xffffffff (= 42949672.095 kHz)
I assume this is the problem: the NIT doesn't contain a proper frequency entry. To avoid problems with NITs that are broadcast on other transponders, VDR checks whether the frequency contained in the NIT is the same as the transponder that is currently broadcast. This check will always fail in your case.
For a quick test whether my assumtion is correct, please try the following patch:
--- nit.c 2016-12-23 15:16:59.000000000 +0100 +++ nit.c 2018-02-28 10:58:38.595483737 +0100 @@ -22,7 +22,7 @@ #define MAXNETWORKNAME Utf8BufSize(256)
// Set to 'true' for debug output: -static bool DebugNit = false; +static bool DebugNit = true;//XXX false;
#define dbgnit(a...) if (DebugNit) fprintf(stderr, a)
@@ -219,6 +219,8 @@ cDvbTransponderParameters dtp; int Source = cSource::FromData(cSource::stTerr); int Frequency = Frequencies[0] = sd->getFrequency() * 10; + Frequency = Transponder() * 1000000;//XXX + dsyslog("Frequency = %08X, Transponder = %d", sd->getFrequency(), Transponder());//XXX static int Bandwidths[] = { 8000000, 7000000, 6000000, 5000000, 0, 0, 0, 0 }; dtp.SetBandwidth(Bandwidths[sd->getBandwidth()]); static int Constellations[] = { QPSK, QAM_16, QAM_64, QAM_AUTO };
Klaus
On Wed, 28 Feb 2018 11:01:23 +0100 Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
It works. I had to have VDR recreate the channels because it was mixing things up with the already existing ones.
As to why the frequency is set to "-10" I don't know (yet), but I remember it has always been like this since 2005.
Initial tuning files have always contained all active frequencies for their region, because the NIT did not set the center frequencies correctly.
It might be because the multiplexed transport streams are generated centrally and then distributed to all the base-stations where they are emitted as-is but on different frequencies depending on the region.
What can we do to get this upstream?
Thanks for your help, -- Patrick.
On Thu, 1 Mar 2018 10:22:10 +0100 Patrick Boettcher patrick.boettcher@posteo.de wrote:
I called victory too early: something (channel-updates?) is overwriting the frequencies and modulation-data for all DVB-T-channels.
Please see the attached log-file.
-- Patrick.
On 01.03.2018 10:22, Patrick Boettcher wrote:
Can you please send me the log line that was generated by the added dsyslog() statement?
I suggest checking sd->getFrequency() against 0xFFFFFFFF and if it has that value, use Transponder() * 1000000 instead. I'd just like to see whether the log really confirms this.
Klaus
On Thu, 1 Mar 2018 11:38:24 +0100 Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
It does:
Mar 1 11:28:43 vdr vdr: [4096] Frequency = FFFFFFFF, Transponder = 586
-- Patrick.
On Thu, 1 Mar 2018 10:22:10 +0100 Patrick Boettcher patrick.boettcher@posteo.de wrote:
Here is the explanation why the frequency field in French DVB-T shall not be used, (cf. CSA-Profil-de-signalisationv3.4.pdf, page 30, terrestrial_delivery_system_descriptor):
le terrestrial delivery_system_descriptor diffusés dans la NIT correspond au cas général. En effet, la NIT ne décrit pas de façon exhaustive le réseau actuel d’émetteurs, mais l’organisation des services des multiplex diffusés : ainsi les fréquences des multiplex renseignées par le paramètre centre_frequency ont une valeur fixée à 0xFFFFFFFF. Ces fréquences ne sont pas à prendre en compte
It says, grosso modo, that the NIT does not describe the network in an exhaustive manner, but it does for services. Le field centre_frequency contains the value 0xFFFFFFFF and is not to be taken into consideration.
-- Patrick.
On Fri, 9 Mar 2018 11:30:36 +0100 Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
One approach might be to ignore frequencies for DVB-T channels update during NIT parsing (in France only?).
From my experiences with DVB-T SetTopBoxes using the NIT for new channel-discovery is rarely done. No customer of my ex-employer was using it - scanning was entirely based on continuous frequency-band scanning with a spare demod.
That would be my idea. But I don't know whether this can be easily applied to VDR.
-- Patrick.
On 09.03.2018 11:51, Patrick Boettcher wrote:
Well, maybe this works for you?
--- nit.c 2016/12/23 14:16:59 4.4 +++ nit.c 2018/03/09 10:53:38 @@ -218,6 +218,8 @@ SI::TerrestrialDeliverySystemDescriptor *sd = (SI::TerrestrialDeliverySystemDescriptor *)d; cDvbTransponderParameters dtp; int Source = cSource::FromData(cSource::stTerr); + if (sd->getFrequency() == 0xFFFFFFFF) + continue; int Frequency = Frequencies[0] = sd->getFrequency() * 10; static int Bandwidths[] = { 8000000, 7000000, 6000000, 5000000, 0, 0, 0, 0 }; dtp.SetBandwidth(Bandwidths[sd->getBandwidth()]);
Klaus
On 09.03.2018 11:55, Klaus Schmidinger wrote:
Sorry, of course it has to be "break" instead of "continue":
--- nit.c 2016/12/23 14:16:59 4.4 +++ nit.c 2018/03/09 10:57:21 @@ -216,6 +216,8 @@ break; case SI::TerrestrialDeliverySystemDescriptorTag: { SI::TerrestrialDeliverySystemDescriptor *sd = (SI::TerrestrialDeliverySystemDescriptor *)d; + if (sd->getFrequency() == 0xFFFFFFFF) + break; cDvbTransponderParameters dtp; int Source = cSource::FromData(cSource::stTerr); int Frequency = Frequencies[0] = sd->getFrequency() * 10;
Klaus
On Fri, 9 Mar 2018 11:55:02 +0100 Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
This is what I'm doing right now (though I'm using break instead of continue).
But won't his inhibit the update of modulation parameters of the _current_ channel?
-- Patrick.
Hi all VDR users,
I am upgrading my VDR box, using Debian Buster 10.2 (4.19 kernel).
I've some difficulties for reinstalling LIRC [using remote on serial port] due to several changes : - new path / name of LIRC's configurations files. - lirc_serial move out of staging (is no longer part of the kernel) and/or rename to serial_ir.
I am stuck :-(
Could someone please explain to me how to install (ex. need to recompile kernel to add missing module ?) and/or point me to a howto on the Net ?
Thanks ! Regards.
Karim
Here are my notes about those lirc changes from March 2019.
You still need to release the serial port from normal serial driver: setserial /dev/ttyS0 uart none
Load serial_ir module, no need for lirc_serial.
serial_ir will create a /dev/lircN device, and also a /dev/input/eventM
Load one of the ir_*_decoder modules too, for example ir_rc5_decoder or ir_rc6_decoder depending on the type of your remote. This way you'll probably don't need to teach remotes to lircd with irrecord, but can just read events from /dev/input/eventM
Do a cat /sys/class/rc/rc*/protocols That will show you list(s) of supported remote models and you can change the model by writing your choice back to the protocols file.
Before I knew all this, I tried to teach remote to lircd with irrecord, like irrecord -H default -d /dev/lircN
This way I couldn't get irrecord to learn about a Technotrend remote I have.
After I chose rc-5 with the protocols file, I started to get events from /dev/ input/eventM. This wasn't enough to get lircd to react to the events, so I had to teach them to lircd by running irrecord -H devinput -d /dev/input/eventM
After that I ran lircd with lircd -e lirc -H devinput \ -d /dev/input/by-path/platform-serial_ir.0-event-ir \ /etc/lircd.conf
And now lirc works again!
Unfortunately I still couldn't figure out how I could use the Technotrend remote with built-in ir receiver of CT2-4400. There is a /dev/input/event- device for it, but no events come through.
Thanks for helping ! Here is what I did following your advice :
1/ My lirc_options.conf :
[lircd] driver = default device = /dev/lirc0
[modinit] code = /usr/bin/setserial /dev/ttyS0 uart none code1 = /usr/sbin/modprobe serial_ir
2/ Loading modules and check (my remote is an old Philips 8139, rc5): /sbin/modprobe ir_rc5_decoder /sbin/modprobe serial_ir
lsmod | grep ir serial_ir 20480 0 ir_rc5_decoder 16384 0 ir_rc6_decoder 16384 0 irqbypass 16384 1 kvm rc_core 53248 9 budget_ci,ir_rc6_decoder,rc_rc6_mce,cx23885,ir_rc5_decoder,serial_ir,rc_tt_1500
cat /sys/class/rc/rc*/protocols rc-5 nec [rc-6] jvc sony rc-5-sz sanyo sharp mce_kbd xmp imon [lirc]
ls /dev/lirc* -l crw-rw---- 1 root video 243, 0 janv. 5 10:14 /dev/lirc0 crw-rw---- 1 root video 243, 1 janv. 5 10:57 /dev/lirc1
3/ Modules are up, unfortunatelly, I can't run lircd :
/etc/init.d/lircd start [....] Starting lircd (via systemctl): lircd.serviceJob for lircd.service failed because the control process exited with error code. See "systemctl status lircd.service" and "journalctl -xe" for details. failed!
4/ journalctl -xe -- L'unité (unit) lircd.service a commencé à démarrer. janv. 05 10:57:11 pctest lircd[1997]: /usr/sbin/lircd: symbol lookup error: /usr/sbin/lircd: undefined symbol: release_map_remotes janv. 05 10:57:11 pctest systemd[1]: lircd.service: Main process exited, code=exited, status=127/n/a -- Subject: Unit process exited -- Defined-By: systemd -- Support: https://www.debian.org/support
Hello, I finally managed to get working for the fist two steps : mode2 and irrecord are OK. There is only one problem left : lircd KO /sbin/lircd: symbol lookup error: /sbin/lircd: undefined symbol: release_map_remotes
Could someone could help me to fix this problem ?
Thanks a lot ! Karim
Hi,
Finally, I dropped Buster, and moved to Mint 19.3 Tricia. No problem with this version, lirc is working like a charm.
Thanks for your support ! Karim
Le 09/01/2020 à 22:59, Karim AFIFI a écrit :
-
Karim AFIFI -
Klaus Schmidinger -
Mikko Tuumanen -
Patrick Boettcher