Hello everyone! I'm from Argentina, and up to last month I've been using
VDR 1.7.262 with an ISDB-T USB adapter. It works really good, but the
last week I've been trying to upgrade to VDR 2.2 and I've found a
problem with ISDB-T cards: they are not supported.
As I'm really interested in using VDR, I was digging inside the code and
found a partial solution for this problem: as ISDBT is the same as DVBT,
I've changed the way delivery system is queried. My changes are applied
in a cloned repo at …
[View More]github:
https://github.com/chrodriguez/vdr/commit/dadbca57c2dc55c1c53b4fa8f68b56728…
That's the only change I've made. Now I can enjoy my fresh upgraded VDR
installation!!
I think a better refactor should be made, but for now it's working
perfectly deployed as a docker container:
https://registry.hub.docker.com/u/chrodriguez/vdr
Thanks for this wonderfull project!
--
Lic. Christian A. Rodriguez
@car_unlp
[View Less]
d->MaySwitchTransponder(Channel) is always false here
Please review,
Sergey Chernyavskiy.
---
device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/device.c b/device.c
index 18867cd..542d120 100644
--- a/device.c
+++ b/device.c
@@ -342,7 +342,7 @@ cDevice *cDevice::GetDeviceForTransponder(const cChannel *Channel, int Priority)
if (d->ProvidesTransponder(Channel)) {
if (d->MaySwitchTransponder(Channel))
Device = d; // this …
[View More]device may switch to the transponder without disturbing any receiver or live view
- else if (!d->Occupied() && d->MaySwitchTransponder(Channel)) { // MaySwitchTransponder() implicitly calls Occupied()
+ else if (!d->Occupied()) { // MaySwitchTransponder() implicitly calls Occupied()
if (d->Priority() < Priority && (!Device || d->Priority() < Device->Priority()))
Device = d; // use this one only if no other with less impact can be found
}
--
1.9.1
[View Less]
Hi Klaus,
I'm 99% of the way to finishing my H264 ffmpeg transcoding script, I'm just getting 2 of these warnings when reindexing transcoded files
May 30 21:08:09 ha-server vdr: [31785] WARNING: required 5 video TS packets to determine frame type
May 30 21:08:09 ha-server vdr: [31785] WARNING: required 5 video TS packets to determine frame type
Sometimes the number is 4. Fortunately not over 6 yet.
Is this a functional problem ? (files play in everything I need them to).
I reduced the I-…
[View More]frame gap which also improves seeking performance, but that's not the issue.
Looking at the code I'm not quite sure what it's looking for - can you help?
I may be able to adjust codec / muxer to avoid warnings
Thanks
Richard
[View Less]
Hi Karim,
Karim schrieb am 26.05.2016 um 22:39:
> I tried today with Jessie 8.4.0 x64, exactly same problem :-(
> I think we tried all the ways. I opened a case at TBS support a few days ago.
> They asked me to send them "lirc_serial.ko working" to check, it seems they could integrate it in their driver.
> If so, it should be great !
>
> Many thanks for your help !
> Of course, if I have some good news from TBS, I will post here.
You mean that the (current) TBS driver is …
[View More]incompatible to Debian?
Maybe .. OK, let's check the TBS support :)
Best regards
Andreas Böttger
[View Less]
Hi Karim,
Karim schrieb am 25.05.2016 um 00:24:
> LIRC is a daemon (/usr/sbin/lircd on my system) and /etc/init.d/lirc is the script to start this daemon.
> If I restart LIRC I see the following in syslog (on my systemd system via journalctl -f):
>
> Unfortunately I don't have journalctl, and I didn't afford to install it on Debian Wheezy.
You do not need journalctl, because your system is no systemd-system obviously.
On my system there is no syslog or other logfile in directory /…
[View More]var/log :)
> Your line "[FAIL] Starting remote control..." means that LIRC has any problem.
> Please try to find any other entries in any logfiles that may be related with this problem.
> This failed start should be visible in syslog...
>
> You've right. But curiously, I didnt find error :
>
> grep lirc /var/log/syslog
> May 24 23:01:00 pctest lircd-0.9.0-pre1[4396]: lircd(default) ready, using /var/run/lirc/lircd
> May 24 23:02:00 pctest lircd-0.9.0-pre1[4396]: caught signal
> May 24 23:09:01 pctest lircd-0.9.0-pre1[4414]: lircd(default) ready, using /var/run/lirc/lircd
> May 24 23:09:09 pctest lircd-0.9.0-pre1[4414]: caught signal
> May 24 23:35:51 pctest kernel: [ 4171.326315] lirc_serial: Manually using active low receiver
> May 24 23:35:51 pctest kernel: [ 4171.326409] lirc_serial lirc_serial.0: lirc_dev: driver lirc_serial registered at minor = 2
>
> grep lirc /var/log/user.log
> nothing.
Strange...
>> 3/
>> During workflow, theses commands returns "no file", I don't know if it's normal :
>> mv /lib/modules/`uname -r`/kernel/drivers/media/* $SICDIR/media/
>> mv /lib/modules/`uname -r`/kernel/drivers/staging/media/*
>> $SICDIR/staging/media/
> On my system the package from TBS installs in different directories than the original modules are.
> This way I had a mixture of original modules and modules from TBS. After deleting the original "media" subdirs and reinstalling TBS stuff all was ok. But if it become necessary to restore the originals you need a backup...
> Maybe your system has a different directory structure?
>
> Yes, I think so. I see 2 path :
> /lib/modules/3.2.0-4-amd64/kernel/drivers/media/
> /lib/modules/3.2.0-4-amd64/kernel/drivers/staging/media/
>
> (I am afraid that if I restore media from backup it erase news modules from TBS).Theses points (path and need/or don't need to restore backup) are not very clear for me.
It is not important in which directory structure the modules are installed.
But it is important, that you have no mixture of modules, that are build from different configurations
or that are incompatible in any other way. The package from TBS install its own version of v4l (Video4Linux)
and your system should use only these modules, not the originals or both of them.
Normally you will not need backups, but to have it is better :)
Maybe it is a good idea to reinstall your Debian system to be sure, that all modules are clean.
Than create a backup of the entire modules tree (/lib/modules/*) and install TBS stuff without deleting any directories.
After that you are able to compare the mixed modules to the backup (diff -Nqr /lib/modules /your.backup) and find out,
what you should delete before installing TBS.
>> 4/
>> I can't check this because "/etc/sysconfig" doesn't exist in my Debian 7.7.0.
>> Do you know the path for Debian ?
>> vdr:~ # grep '^[A-Z]' /etc/sysconfig/lirc LIRCD_DEV_PERMISSIONS="660"
>> LIRCD_DEV_OWNER="root:video"
>> LIRCD_DRIVER="default"
>> LIRCD_DEVICE="/dev/lirc0"
>> LIRC_MODULE="lirc_serial"
>> LIRCD_LISTENPORT=
>> LIRCD_CONNECT=
> vdr:~ # find /etc -name 'lirc*'
> /etc/lirc
> /etc/lirc/lircd.conf
> /etc/init.d/lirc
> /etc/sysconfig/lirc
>
> Try this on your system...
>
> Unfortunately I didn't find this file :-(
>
>
>
>> 5/
>> /etc/lirc/hardware.conf
>> # /etc/lirc/hardware.conf
>> #
>> # Arguments which will be used when launching lircd LIRCD_ARGS=""
>>
>> #Don't start lircmd even if there seems to be a good config file
>> #START_LIRCMD=false
>>
>> #Don't start irexec, even if a good config file seems to exist.
>> #START_IREXEC=false
>>
>> #Try to load appropriate kernel modules LOAD_MODULES=true
>>
>> # Run "lircd --driver=help" for a list of supported drivers.
>> DRIVER=""
>> # If DEVICE is set to /dev/lirc and udev is in use /dev/lirc0 will be
>> # automatically used instead DEVICE=""
>> MODULES="lirc_serial"
>>
>> # Default configuration files for your hardware if any LIRCD_CONF=""
>> LIRCMD_CONF=""
>
> Your /etc/lirc/hardware.conf could be somewhat that /etc/sysconfig/lirc is on my system.
>
>
> Yes, that's why I did'nt find /etc/sysconfig.
>
>
> At this time, I think **the point** is to clarify is the configuration file :
> path, name and content.
>
> In case I can't find/fix this, do you think it could be interesting to try with a fresh install of Debian Jessie **8.4.0** which kernel 3.16 ?
Debian and OpenSUSE are different. Logging is different, configuration is different, ... but both are linux :)
Do you have an old system with running DVB and LIRC? If so, try to find the LIRC configuration...
I do not know Debian and which version is stable or not.
But why not - "latest is greatest" :)
Best regards
Andreas Böttger
[View Less]
Hi Karim,
Karim schrieb am 21.05.2016 um 23:29:
> grep lirc /var/log/syslog
> May 21 22:40:05 pctest kernel: [ 3.835944] lirc_dev: IR Remote Control driver registered, major 251
> May 21 22:40:05 pctest kernel: [ 3.836499] rc rc0: lirc_dev: driver ir-lirc-codec (saa716x) registered at minor = 0
> May 21 22:40:05 pctest kernel: [ 4.402162] rc rc1: lirc_dev: driver ir-lirc-codec (saa716x) registered at minor = 1
> May 21 22:40:05 pctest kernel: [ 7.364112] lirc_serial: …
[View More]Manually using active low receiver
> May 21 22:40:05 pctest kernel: [ 7.364198] lirc_serial lirc_serial.0: lirc_dev: driver lirc_serial registered at minor = 2
> May 21 22:46:27 pctest kernel: [ 388.677309] lirc_dev: module unloaded
> May 21 22:48:32 pctest kernel: [ 513.779622] lirc_dev: IR Remote Control driver registered, major 251
> May 21 22:48:32 pctest kernel: [ 513.780127] lirc_serial: Manually using active low receiver
> May 21 22:48:32 pctest kernel: [ 513.780224] lirc_serial lirc_serial.0: lirc_dev: driver lirc_serial registered at minor = 0
>
> Questions :
>
> 1/
> There is **2 modules**, but I think it's not a problem because modinfo is OK.
> Are you OK ?
It seems to me that there are two rc-devices on receiver cards - rc0 and rc1.
After restart of LIRC only lirc_dev and lirc_serial are running - ok.
> locate lirc_serial.ko
> /lib/modules/3.2.0-4-amd64/kernel/drivers/linux/drivers/staging/lirc/lirc_serial.ko
> /lib/modules/sic/2016-05-20_22:51/3.2.0-4-amd64/kernel/drivers/media/staging/media/lirc/lirc_serial.ko
.. the new one from TBS and a backup - ok.
> 2/
> I found a problem with lirc (I don't know if there is a relation with mode2 :
> setserial /dev/ttyS0 uart none
> /etc/init.d/lirc start
> [ ok ] Loading LIRC modules:.
> [FAIL] Starting remote control daemon(s) : LIRC : failed!
> You mean lirc or lircd ? (I use lircd in my vdr)
LIRC is a daemon (/usr/sbin/lircd on my system) and /etc/init.d/lirc is the script to start this daemon.
If I restart LIRC I see the following in syslog (on my systemd system via journalctl -f):
Mai 22 14:52:10 vdr systemd[1]: Stopping LSB: lirc daemon...
Mai 22 14:52:10 vdr lircd-0.9.0[980]: caught signal
Mai 22 14:52:10 vdr vdr[2522]: [2540] ERROR: lircd connection broken, trying to reconnect every 3,0 seconds
Mai 22 14:52:10 vdr lirc[1024]: Shutting down lircd ..done
Mai 22 14:52:10 vdr systemd[1]: Stopped LSB: lirc daemon.
Mai 22 14:52:12 vdr systemd[1]: Starting LSB: lirc daemon...
Mai 22 14:52:12 vdr lircd-0.9.0[1071]: lircd(default) ready, using /var/run/lirc/lircd
Mai 22 14:52:12 vdr lirc[1044]: Starting lircd (/dev/lirc0)..done
Mai 22 14:52:12 vdr systemd[1]: Started LSB: lirc daemon.
Mai 22 14:52:13 vdr vdr[2522]: [2540] reconnected to lircd
Mai 22 14:52:13 vdr lircd-0.9.0[1071]: accepted new client on /var/run/lirc/lircd
Your line "[FAIL] Starting remote control..." means that LIRC has any problem.
Please try to find any other entries in any logfiles that may be related with this problem.
This failed start should be visible in syslog...
> 3/
> During workflow, theses commands returns "no file", I don't know if it's normal :
> mv /lib/modules/`uname -r`/kernel/drivers/media/* $SICDIR/media/
> mv /lib/modules/`uname -r`/kernel/drivers/staging/media/* $SICDIR/staging/media/
On my system the package from TBS installs in different directories than the original modules are.
This way I had a mixture of original modules and modules from TBS. After deleting the original
"media" subdirs and reinstalling TBS stuff all was ok. But if it become necessary to restore the
originals you need a backup...
Maybe your system has a different directory structure?
> 4/
> I can't check this because "/etc/sysconfig" doesn't exist in my Debian 7.7.0.
> Do you know the path for Debian ?
> vdr:~ # grep '^[A-Z]' /etc/sysconfig/lirc LIRCD_DEV_PERMISSIONS="660"
> LIRCD_DEV_OWNER="root:video"
> LIRCD_DRIVER="default"
> LIRCD_DEVICE="/dev/lirc0"
> LIRC_MODULE="lirc_serial"
> LIRCD_LISTENPORT=
> LIRCD_CONNECT=
vdr:~ # find /etc -name 'lirc*'
/etc/lirc
/etc/lirc/lircd.conf
/etc/init.d/lirc
/etc/sysconfig/lirc
Try this on your system...
> 5/
> I use Homebrew too.
> Could you confirm that parameters must be sent with theses 3 files ?
>
> /etc/lirc/lircd.conf
>
>
> /etc/serial.conf
> /dev/ttyS0 uart none
>
> /etc/lirc/hardware.conf
> # /etc/lirc/hardware.conf
> #
> # Arguments which will be used when launching lircd
> LIRCD_ARGS=""
>
> #Don't start lircmd even if there seems to be a good config file
> #START_LIRCMD=false
>
> #Don't start irexec, even if a good config file seems to exist.
> #START_IREXEC=false
>
> #Try to load appropriate kernel modules
> LOAD_MODULES=true
>
> # Run "lircd --driver=help" for a list of supported drivers.
> DRIVER=""
> # If DEVICE is set to /dev/lirc and udev is in use /dev/lirc0 will be
> # automatically used instead
> DEVICE=""
> MODULES="lirc_serial"
>
> # Default configuration files for your hardware if any
> LIRCD_CONF=""
> LIRCMD_CONF=""
On my system there is no /etc/serial.conf.
Your /etc/lirc/hardware.conf could be somewhat that /etc/sysconfig/lirc is on my system.
Best regards
Andreas Böttger
[View Less]
Hi Karim,
Karim schrieb am 20.05.2016 um 22:59:
> lirc_serial is now loading :
>
> dmesg
> [7.492111] lirc_serial: Manually using active low receiver
> [7.492378] lirc_serial lirc_serial.0: lirc_dev: driver lirc_serial registered at minor = 2
>
> Unfortunately, remote doesn't work (tested with mode2).
If you try it with your old setup, original lirc modules and the same config files - is then all ok?
Are there any errors in syslog?
> I noticed in ".config" file :
> #…
[View More] CONFIG_LIRC_SERIAL_TRANSMITTER is not set
>
> I changed to :
> CONFIG_LIRC_SERIAL_TRANSMITTER=y
I think that you will need this only for any infrared sender.
> Did I missed something ?
Hmm...
I restart lirc in my runvdr script like this:
/etc/init.d/lirc stop
sleep 1
rmmod lirc_serial lirc_dev # to be sure
sleep 1
setserial /dev/ttyS0 uart none
sleep 1
/etc/init.d/lirc start
vdr:~ # dmesg | grep lirc
lirc_dev: IR Remote Control driver registered, major 247
lirc_serial: Manually using active low receiver
lirc_serial lirc_serial.0: lirc_dev: driver lirc_serial registered at minor = 0
vdr:~ # lsmod | grep lirc
lirc_serial 18982 3
lirc_dev 19166 1 lirc_serial
vdr:~ # grep '^[A-Z]' /etc/sysconfig/lirc
LIRCD_DEV_PERMISSIONS="660"
LIRCD_DEV_OWNER="root:video"
LIRCD_DRIVER="default"
LIRCD_DEVICE="/dev/lirc0"
LIRC_MODULE="lirc_serial"
LIRCD_LISTENPORT=
LIRCD_CONNECT=
Best regards.
Andreas Böttger
[View Less]
Hi Karim,
Karim schrieb am 19.05.2016 um 22:36:
> I have an issue with TBS drivers (even with last version from april 2016).
> As soon as I install TBS Linux drivers and reboot, lirc_serial doesn't load anymore.
I use TBS drivers v160405 with OpenSuse 13.2 (kernel 3.16.7-35) but lirc from TBS driver package.
My workflow to do this is:
cd linux-tbs-drivers
make distclean
./v4l/tbs-x86_64.sh
make # but only some seconds to initialize build and generate v4l/.…
[View More]config
vi v4l/.config # CONFIG_LIRC_STAGING=y and CONFIG_LIRC_SERIAL=m
make
# remove (with or without backup) original media
SICDIR=/lib/modules/sic/`date +%Y-%m-%d_%H:%M`/`uname -r`/kernel/drivers/media/
mkdir -p $SICDIR/media $SICDIR/staging/media
mv /lib/modules/`uname -r`/kernel/drivers/media/* $SICDIR/media/
mv /lib/modules/`uname -r`/kernel/drivers/staging/media/* $SICDIR/staging/media/
make install
reboot
Best regards.
Andreas Böttger
[View Less]