Message ID | 31220933-dda2-5e51-7e61-c3655197dddb@tvdr.de |
---|---|
State | New |
Headers |
Received: from localhost ([127.0.0.1] helo=www.linuxtv.org) by www.linuxtv.org with esmtp (Exim 4.84_2) (envelope-from <vdr-bounces@linuxtv.org>) id 1eqyYC-0005lx-Dy; Wed, 28 Feb 2018 10:01:28 +0000 Received: from racoon.tvdr.de ([88.198.76.220]) by www.linuxtv.org with esmtp (Exim 4.84_2) (envelope-from <Klaus.Schmidinger@tvdr.de>) id 1eqyY8-0005lf-8Q for vdr@linuxtv.org; Wed, 28 Feb 2018 10:01:25 +0000 Received: from eagle.tvdr.de (eagle.tvdr.de [192.168.1.10]) by racoon.tvdr.de (8.14.9/8.14.9) with ESMTP id w1SA1NZH011424 for <vdr@linuxtv.org>; Wed, 28 Feb 2018 11:01:23 +0100 Received: from [192.168.1.10] (eagle.tvdr.de [192.168.1.10]) by eagle.tvdr.de (8.15.2/8.15.2) with ESMTP id w1SA1NBQ011755 for <vdr@linuxtv.org>; Wed, 28 Feb 2018 11:01:23 +0100 To: VDR Mailing List <vdr@linuxtv.org> References: <20180225152621.75458a81@yaise-pc1> <8b233e07-db60-b942-e298-a14c08e647f0@tvdr.de> <20180226232758.454f8022@yaise-pc1> <33ccd29f-8f5f-5d00-7b20-a99d3742286e@tvdr.de> <20180227175820.607bbebb@posteo.de> From: Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> Message-ID: <31220933-dda2-5e51-7e61-c3655197dddb@tvdr.de> Date: Wed, 28 Feb 2018 11:01:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180227175820.607bbebb@posteo.de> Content-Language: de-DE X-LSpam-Score: -1.9 (-) X-LSpam-Report: No, score=-1.9 required=5.0 tests=BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01 autolearn=ham autolearn_force=no Subject: Re: [vdr] French DVB-T Channel IDs vs. EIT Channel IDs X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: VDR Mailing List <vdr.linuxtv.org> List-Unsubscribe: <https://www.linuxtv.org/cgi-bin/mailman/options/vdr>, <mailto:vdr-request@linuxtv.org?subject=unsubscribe> List-Archive: <http://www.linuxtv.org/pipermail/vdr/> List-Post: <mailto:vdr@linuxtv.org> List-Help: <mailto:vdr-request@linuxtv.org?subject=help> List-Subscribe: <https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=subscribe> Reply-To: VDR Mailing List <vdr@linuxtv.org> Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: vdr-bounces@linuxtv.org Sender: "vdr" <vdr-bounces@linuxtv.org> |
Commit Message
Klaus Schmidinger
Feb. 28, 2018, 10:01 a.m. UTC
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
Comments
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
--- 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 };