French DVB-T Channel IDs vs. EIT Channel IDs

  On 27.02.2018 17:58, Patrick Boettcher wrote:
> On Tue, 27 Feb 2018 16:54:35 +0100
> Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote:
> 
>> Hello Patrick,
>> 
>> your scan doesn't contain the NIT, which is where the transponder
>> innformation is broadcast. Can you scan that, too, please?
> 
> Hi Klaus,
> 
> NIT attached (from another multiplex with the same symptoms).


     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:


Klaus
  

On Wed, 28 Feb 2018 11:01:23 +0100
Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote:

> On 27.02.2018 17:58, Patrick Boettcher wrote:
> > On Tue, 27 Feb 2018 16:54:35 +0100
> > Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote:
> >   
> >> Hello Patrick,
> >> 
> >> your scan doesn't contain the NIT, which is where the transponder
> >> innformation is broadcast. Can you scan that, too, please?  
> > 
> > Hi Klaus,
> > 
> > NIT attached (from another multiplex with the same symptoms).  
> 
>              DVB-DescriptorTag: 90 (0x5a)  [=
> terrestrial_delivery_system_descriptor] descriptor_length: 11 (0x0b)
>              Center frequency: 0xffffffff (= 42949672.095 kHz)
> 
> @@ -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 };

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:

> On Wed, 28 Feb 2018 11:01:23 +0100
> Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote:
> 
> > On 27.02.2018 17:58, Patrick Boettcher wrote:  
> > > On Tue, 27 Feb 2018 16:54:35 +0100
> > > Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote:
> > >     
> > >> Hello Patrick,
> > >> 
> > >> your scan doesn't contain the NIT, which is where the transponder
> > >> innformation is broadcast. Can you scan that, too, please?    
> > > 
> > > Hi Klaus,
> > > 
> > > NIT attached (from another multiplex with the same symptoms).    
> > 
> >              DVB-DescriptorTag: 90 (0x5a)  [=
> > terrestrial_delivery_system_descriptor] descriptor_length: 11 (0x0b)
> >              Center frequency: 0xffffffff (= 42949672.095 kHz)
> > 
> > @@ -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 };  
> 
> It works. I had to have VDR recreate the channels because it was
> mixing things up with the already existing ones.

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:
> On Wed, 28 Feb 2018 11:01:23 +0100
> Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote:
> 
>> On 27.02.2018 17:58, Patrick Boettcher wrote:
>> > On Tue, 27 Feb 2018 16:54:35 +0100
>> > Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote:
>> >   
>> >> Hello Patrick,
>> >> 
>> >> your scan doesn't contain the NIT, which is where the transponder
>> >> innformation is broadcast. Can you scan that, too, please?  
>> > 
>> > Hi Klaus,
>> > 
>> > NIT attached (from another multiplex with the same symptoms).  
>> 
>>              DVB-DescriptorTag: 90 (0x5a)  [=
>> terrestrial_delivery_system_descriptor] descriptor_length: 11 (0x0b)
>>              Center frequency: 0xffffffff (= 42949672.095 kHz)
>> 
>> @@ -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 };
> 
> 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.

Can you please send me the log line that was generated by the added dsyslog() statement?

> 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?

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 10:22:10 +0100
Patrick Boettcher <patrick.boettcher@posteo.de> wrote:

> On Wed, 28 Feb 2018 11:01:23 +0100
> Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote:
> 
> > On 27.02.2018 17:58, Patrick Boettcher wrote:  
> > > On Tue, 27 Feb 2018 16:54:35 +0100
> > > Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote:
> > >     
> > >> Hello Patrick,
> > >> 
> > >> your scan doesn't contain the NIT, which is where the transponder
> > >> innformation is broadcast. Can you scan that, too, please?    
> > > 
> > > Hi Klaus,
> > > 
> > > NIT attached (from another multiplex with the same symptoms).    
> > 
> >              DVB-DescriptorTag: 90 (0x5a)  [=
> > terrestrial_delivery_system_descriptor] descriptor_length: 11 (0x0b)
> >              Center frequency: 0xffffffff (= 42949672.095 kHz)
> > 
> > @@ -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 };  
> 
> 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. 

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 01.03.2018 11:39, Patrick Boettcher wrote:
> On Thu, 1 Mar 2018 10:22:10 +0100
> Patrick Boettcher <patrick.boettcher@posteo.de> wrote:
> 
>> On Wed, 28 Feb 2018 11:01:23 +0100
>> Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote:
>> 
>> > On 27.02.2018 17:58, Patrick Boettcher wrote:  
>> > > On Tue, 27 Feb 2018 16:54:35 +0100
>> > > Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote:
>> > >     
>> > >> Hello Patrick,
>> > >> 
>> > >> your scan doesn't contain the NIT, which is where the transponder
>> > >> innformation is broadcast. Can you scan that, too, please?    
>> > > 
>> > > Hi Klaus,
>> > > 
>> > > NIT attached (from another multiplex with the same symptoms).    
>> > 
>> >              DVB-DescriptorTag: 90 (0x5a)  [=
>> > terrestrial_delivery_system_descriptor] descriptor_length: 11 (0x0b)
>> >              Center frequency: 0xffffffff (= 42949672.095 kHz)
>> > 
>> > @@ -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 };  
>> 
>> 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. 
> 
> 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.

My last message was sent before I received your log.
I'll take a further look...

Klaus
  

On Thu, 1 Mar 2018 11:38:24 +0100
Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote:
> >>              DVB-DescriptorTag: 90 (0x5a)  [=
> >> terrestrial_delivery_system_descriptor] descriptor_length: 11
> >> (0x0b) Center frequency: 0xffffffff (= 42949672.095 kHz)
> >> 
> >> @@ -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 };  
> > 
> > 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.  
> 
> Can you please send me the log line that was generated by the added
> dsyslog() statement?

It does:

Mar  1 11:28:43 vdr vdr: [4096] Frequency = FFFFFFFF, Transponder = 586

--
Patrick.
  

On 01.03.2018 10:22, Patrick Boettcher wrote:
> On Wed, 28 Feb 2018 11:01:23 +0100
> Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote:
> 
>> On 27.02.2018 17:58, Patrick Boettcher wrote:
>> > On Tue, 27 Feb 2018 16:54:35 +0100
>> > Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote:
>> >   
>> >> Hello Patrick,
>> >> 
>> >> your scan doesn't contain the NIT, which is where the transponder
>> >> innformation is broadcast. Can you scan that, too, please?  
>> > 
>> > Hi Klaus,
>> > 
>> > NIT attached (from another multiplex with the same symptoms).  
>> 
>>              DVB-DescriptorTag: 90 (0x5a)  [=
>> terrestrial_delivery_system_descriptor] descriptor_length: 11 (0x0b)
>>              Center frequency: 0xffffffff (= 42949672.095 kHz)
>> 
>> @@ -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 };
> 
> 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?

I'm afraid I don't see how this case can be handled correctly.

Maybe somebody else has an idea?

Klaus
  

On Fri, 9 Mar 2018 11:30:36 +0100
Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote:

> On 01.03.2018 10:22, Patrick Boettcher wrote:
> > On Wed, 28 Feb 2018 11:01:23 +0100
> > Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote:
> >   
> >> On 27.02.2018 17:58, Patrick Boettcher wrote:  
> >> > On Tue, 27 Feb 2018 16:54:35 +0100
> >> > Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> wrote:
> >> >     
> >> >> Hello Patrick,
> >> >> 
> >> >> your scan doesn't contain the NIT, which is where the
> >> >> transponder innformation is broadcast. Can you scan that, too,
> >> >> please?    
> >> > 
> >> > Hi Klaus,
> >> > 
> >> > NIT attached (from another multiplex with the same symptoms).    
> >> 
> >>              DVB-DescriptorTag: 90 (0x5a)  [=
> >> terrestrial_delivery_system_descriptor] descriptor_length: 11
> >> (0x0b) Center frequency: 0xffffffff (= 42949672.095 kHz)
> >> 
> >> @@ -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 };  
> > 
> > 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?  
> 
> I'm afraid I don't see how this case can be handled correctly.
> 
> Maybe somebody else has an idea?

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.
  

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
  

> - lirc_serial move out of staging (is no longer part of the kernel)
> and/or rename to serial_ir.

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



> Le 04/01/2020 à 23:02, Mikko Tuumanen a écrit :
>>> - lirc_serial move out of staging (is no longer part of the kernel)
>>> and/or rename to serial_ir.
>> 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.
>>
>>
>>
>>
>> _______________________________________________
>> vdr mailing list
>> vdr@linuxtv.org
>> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
  

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 :
> 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
>
>
>
>> Le 04/01/2020 à 23:02, Mikko Tuumanen a écrit :
>>>> - lirc_serial move out of staging (is no longer part of the kernel)
>>>> and/or rename to serial_ir.
>>> 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.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> vdr mailing list
>>> vdr@linuxtv.org
>>> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>
>> _______________________________________________
>> vdr mailing list
>> vdr@linuxtv.org
>> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr