Hi,
I was quite annoyed how I could operate my EPIA MII-6000E using a LIRC remote. It was almost not possible to navigate through the OSD in a fast way.
The attached patch allows now to define timeouts and frequencies for example in Make.config, so there is no need to patch every VDR version. Furthermore, frequencies are now defined in unit 1/s instead of the unit ms (which defined the period), making values more intuitive.
There's now an additional frequency which defines, how fast a user is allowed to press the same button repeatedly. The originally used REPEATDELAY allowed only 2.85 button presses per second.
On slow and busy machines like my EPIA it happened often that several button presses were read by VDR in a single read, but only the first one got processed. The code now reads only a single button press from LIRC's socket, so button presses don't get lost (although presses of the same button will be skipped as the timeouts don't get reached).
To make it less likely that button presses get processed in chunks a further define allows to decrease the thread's niceness which means to boost it's priority. This feature requires VDR to be run as root.
This is my setup which follows some common settings found in mainboard bioses for keyboard repeat delay and frequency.
#vdr REMOTE=LIRC LIRC_PUSHFREQ=64 # 1/s LIRC_REPEATDELAY=250 # ms LIRC_REPEATFREQ=32 # 1/s #LIRC_REPEATTIMEOUT=500 # ms #LIRC_RECONNECTDELAY=3000 # ms LIRC_PRIORITYBOOST=1
Bye.
Hi Reinhard,
sound very good, but vdr as root do not :-(
do you think it is possible to use this or something else with an non root user?
I think many use vdr with an special non root user, for example all which use gentoo.
greetings mentox aka dominique
Reinhard Nissl schrieb:
Hi,
I was quite annoyed how I could operate my EPIA MII-6000E using a LIRC remote. It was almost not possible to navigate through the OSD in a fast way.
The attached patch allows now to define timeouts and frequencies for example in Make.config, so there is no need to patch every VDR version. Furthermore, frequencies are now defined in unit 1/s instead of the unit ms (which defined the period), making values more intuitive.
There's now an additional frequency which defines, how fast a user is allowed to press the same button repeatedly. The originally used REPEATDELAY allowed only 2.85 button presses per second.
On slow and busy machines like my EPIA it happened often that several button presses were read by VDR in a single read, but only the first one got processed. The code now reads only a single button press from LIRC's socket, so button presses don't get lost (although presses of the same button will be skipped as the timeouts don't get reached).
To make it less likely that button presses get processed in chunks a further define allows to decrease the thread's niceness which means to boost it's priority. This feature requires VDR to be run as root.
This is my setup which follows some common settings found in mainboard bioses for keyboard repeat delay and frequency.
#vdr REMOTE=LIRC LIRC_PUSHFREQ=64 # 1/s LIRC_REPEATDELAY=250 # ms LIRC_REPEATFREQ=32 # 1/s #LIRC_REPEATTIMEOUT=500 # ms #LIRC_RECONNECTDELAY=3000 # ms LIRC_PRIORITYBOOST=1
Bye.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi,
Dominique Matz schrieb:
sound very good, but vdr as root do not :-(
do you think it is possible to use this or something else with an non root user?
Well, only the LIRC_PRIORITYBOOST option requires root privileges to work. If you don't have root privileges, you'll just get an error logged and the LIRC thread runs without any change in priority -- that's all. See man setpriority for details.
Bye.
Reinhard Nissl a écrit :
Dominique Matz schrieb:
sound very good, but vdr as root do not :-(
do you think it is possible to use this or something else with an non root user?
Well, only the LIRC_PRIORITYBOOST option requires root privileges to work. If you don't have root privileges, you'll just get an error logged and the LIRC thread runs without any change in priority -- that's all. See man setpriority for details.
An option would be to lower priority of all threads except this one. I guess only relative priority within VDR is important. You can also raise priority in your init scripts (nice=-N), before running VDR. This way every thread will have nice=0 priority, except the LIRC one, which will stay at nice=-N
Nicolas Huillard wrote:
Reinhard Nissl a écrit :
Dominique Matz schrieb:
sound very good, but vdr as root do not :-(
do you think it is possible to use this or something else with an non root user?
Well, only the LIRC_PRIORITYBOOST option requires root privileges to work. If you don't have root privileges, you'll just get an error logged and the LIRC thread runs without any change in priority -- that's all. See man setpriority for details.
An option would be to lower priority of all threads except this one. I guess only relative priority within VDR is important. You can also raise priority in your init scripts (nice=-N), before running VDR. This way every thread will have nice=0 priority, except the LIRC one, which will stay at nice=-N
Since the lirc thread doesn't do anything except waiting for input most of the time it should be scheduled quickly anyways. Maybe the useless select timeout destroys that advantage somewhat. Also if multiple lines in the buffer are a problem what about changing the code to consume only one line at a time instead of messing with thread priorities?
cu Ludwig
Hi,
Ludwig Nussel schrieb:
Since the lirc thread doesn't do anything except waiting for input most of the time it should be scheduled quickly anyways. Maybe the useless select timeout destroys that advantage somewhat.
I don't think so. In my case (i. e. on my EPIA MII-6000E), there are a lot of other threads from xine-lib for example which cause already noticeable load and due to the xine-lib design, boost their priority a bit on their own (e. g. the video out thread).
Also if multiple lines in the buffer are a problem what about changing the code to consume only one line at a time instead of messing with thread priorities?
The patch addresses this issue already. But VDR processes these button presses with almost no delay so they will be dropped.
I think, the LIRC protocol misses a timestamp for each button press. Or an even more favorable solution would be to put the timeout and frequency processing into LIRC and have VDR to process each key as it arrives, just like with the KBD remote.
I've first tried to process each key as it arrives but the result wasn't useable as the remote used a too short repeat delay. So most often, one moved on for two items instead of one (per button press).
Bye.
On Saturday 12 January 2008, Reinhard Nissl wrote:
I think, the LIRC protocol misses a timestamp for each button press. Or an even more favorable solution would be to put the timeout and frequency processing into LIRC and have VDR to process each key as it arrives, just like with the KBD remote.
Would using liblirc_client instead of the current "homebrew" implementation help out with this?
Also, somewhat off topic: when running powertop[1] on my VDR box, I see lircd waking up the CPU from idle about 1000 times a second while VDR is connected to it:
Top causes for wakeups: 54.3% (988.1) lircd : schedule_timeout (process_timeout) 28.5% (518.4) vdr : futex_wait (hrtimer_wakeup) [...]
I already tried adding some cCondWait::SleepMs's to VDR's lirc action loop but it didn't seem to have any effect. Any ideas whether this is something that VDR could do anything about, or if it's a LIRC internal thing?
Hi,
Ville Skyttä schrieb:
I think, the LIRC protocol misses a timestamp for each button press. Or an even more favorable solution would be to put the timeout and frequency processing into LIRC and have VDR to process each key as it arrives, just like with the KBD remote.
Would using liblirc_client instead of the current "homebrew" implementation help out with this?
When liblirc_client uses the same interface of lircd, then I don't think that it will help.
Also, somewhat off topic: when running powertop[1] on my VDR box, I see lircd waking up the CPU from idle about 1000 times a second while VDR is connected to it:
Top causes for wakeups: 54.3% (988.1) lircd : schedule_timeout (process_timeout) 28.5% (518.4) vdr : futex_wait (hrtimer_wakeup) [...]
I already tried adding some cCondWait::SleepMs's to VDR's lirc action loop but it didn't seem to have any effect. Any ideas whether this is something that VDR could do anything about, or if it's a LIRC internal thing?
Well VDR's lirc action loop uses a timeout only when it needs to generate a keyup event after a key repeat event. Otherwise it blocks in cFile::FileReady's select() until a button gets pressed on the remote.
Try running irw instead of VDR and check powertop again.
Bye.
On Saturday 12 January 2008, Reinhard Nissl wrote:
Ville Skyttä schrieb:
Also, somewhat off topic: when running powertop[1] on my VDR box, I see lircd waking up the CPU from idle about 1000 times a second while VDR is connected to it:
Top causes for wakeups: 54.3% (988.1) lircd : schedule_timeout (process_timeout) 28.5% (518.4) vdr : futex_wait (hrtimer_wakeup) [...]
I already tried adding some cCondWait::SleepMs's to VDR's lirc action loop but it didn't seem to have any effect. Any ideas whether this is something that VDR could do anything about, or if it's a LIRC internal thing?
Well VDR's lirc action loop uses a timeout only when it needs to generate a keyup event after a key repeat event. Otherwise it blocks in cFile::FileReady's select() until a button gets pressed on the remote.
Try running irw instead of VDR and check powertop again.
Yep, same thing with irw so I suppose this needs to be addressed in LIRC, not VDR. Thanks.
Hi,
Nicolas Huillard schrieb:
An option would be to lower priority of all threads except this one. I guess only relative priority within VDR is important. You can also raise priority in your init scripts (nice=-N), before running VDR. This way every thread will have nice=0 priority, except the LIRC one, which will stay at nice=-N
That doesn't work as there is no collection of threads in VDR which would be necessary to catch all threads for example which are created by plugins.
Bye.
I can't get Reinhard's h.264/dvb-s2 patches and multiproto to work when running both dvb-s2 and dvb-t at the same time. Dvb-t works if I don't load the dvb-s modules and dvb-s(2) works if I don't load the dvb-t modules but it doesn't work with both. Instead I'm currently running my dvb-t vdr on my server as usual and another vdr with dvb-s2 on one of my diskless clients. However, recording hd channels over nfs and simulaneously streaming it to my other diskless client overloads my network. Therefore I'm interested to know how hard it would be to modify vdr so I can run one vdr process with, say /dev/dvb/adapter0-3 and a second one on adapter4? Where do I start looking? Is it doable?
I tried running a virtual Ubuntu on my Mandriva server and used dvb-t usb sticks on the ubuntu but usb in vmware wasn't stable enough, at least on my attempts.
/Magnus H
On Wed, 2008-01-09 at 19:57 +0100, Magnus Hörlin wrote:
other diskless client overloads my network. Therefore I'm interested to know how hard it would be to modify vdr so I can run one vdr process with, say /dev/dvb/adapter0-3 and a second one on adapter4? Where do I start looking? Is it doable?
http://linux.die.net/man/8/vdr
-D num, --device=num Use only the given DVB device (num = 0, 1, 2...). There may be several -D options (by default all DVB devices will be used).
You could also use streamdev-client + server on each instance to allow them to share resources. Not ideal but the best there is currently.
gdh
Gavin Hamill wrote:
On Wed, 2008-01-09 at 19:57 +0100, Magnus Hörlin wrote:
other diskless client overloads my network. Therefore I'm interested to know how hard it would be to modify vdr so I can run one vdr process with, say /dev/dvb/adapter0-3 and a second one on adapter4? Where do I start looking? Is it doable?
http://linux.die.net/man/8/vdr
-D num, --device=num Use only the given DVB device (num = 0, 1, 2...). There may be several -D options (by default all DVB devices will be used).
You could also use streamdev-client + server on each instance to allow them to share resources. Not ideal but the best there is currently.
gdh
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Ooops. I'm really sorry. I've used vdr for years but forgot to RTFM. Thanks, /Magnus
I have the same problem with 1x dvb-s and 1x dvb-s2. In the mean time I intend to buy a second dvb-S instead of the dvb-S2, but of course I am interested in a solution to have s ans s2 working together
Serge
-----Oorspronkelijk bericht----- Van: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] Namens Magnus Hörlin Verzonden: woensdag 9 januari 2008 19:58 Aan: VDR Mailing List Onderwerp: [vdr] Two VDR's on one machine
I can't get Reinhard's h.264/dvb-s2 patches and multiproto to work when running both dvb-s2 and dvb-t at the same time. Dvb-t works if I don't load the dvb-s modules and dvb-s(2) works if I don't load the dvb-t modules but it doesn't work with both. Instead I'm currently running my dvb-t vdr on my server as usual and another vdr with dvb-s2 on one of my diskless clients. However, recording hd channels over nfs and simulaneously streaming it to my other diskless client overloads my network. Therefore I'm interested to know how hard it would be to modify vdr so I can run one vdr process with, say /dev/dvb/adapter0-3 and a second one on adapter4? Where do I start looking? Is it doable?
I tried running a virtual Ubuntu on my Mandriva server and used dvb-t usb sticks on the ubuntu but usb in vmware wasn't stable enough, at least on my attempts.
/Magnus H
_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Thu, Jan 10, 2008 at 12:18:16PM +0100, serge pecher wrote:
I have the same problem with 1x dvb-s and 1x dvb-s2. In the mean time I intend to buy a second dvb-S instead of the dvb-S2, but of course I am interested in a solution to have s ans s2 working together
??? I use VDR with two DVB-S and one DVB-S2 here without problem...
Thanks for the info. Could you have a look at http://dvbkivabien2.info/viewtopic.php?f=7&t=12943&p=121435#p121435 where a gave more explanation about my problem. Its seems that the tuner of the S2-3200 is not detected, but I dont know what to do.
Thanks,
Serge
-----Oorspronkelijk bericht----- Van: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] Namens Gregoire Favre Verzonden: donderdag 10 januari 2008 12:39 Aan: VDR Mailing List Onderwerp: Re: [vdr] Two VDR's on one machine
On Thu, Jan 10, 2008 at 12:18:16PM +0100, serge pecher wrote:
I have the same problem with 1x dvb-s and 1x dvb-s2. In the mean time I intend to buy a second dvb-S instead of the dvb-S2, but of course I am interested in a solution to have s ans s2 working together
??? I use VDR with two DVB-S and one DVB-S2 here without problem...
On Thu, Jan 10, 2008 at 02:29:58PM +0100, serge pecher wrote:
Thanks for the info. Could you have a look at http://dvbkivabien2.info/viewtopic.php?f=7&t=12943&p=121435#p121435 where a gave more explanation about my problem. Its seems that the tuner of the S2-3200 is not detected, but I dont know what to do.
Well,
it don't seems you have a guest access to read it ?
I don't have a S2-3200, but I think the first revision has a problem (that was the main reason not to buy one) the best place to seek for information is vdrportal.de in which there are a few topics about this card.
But honestly, if you did a ./scripts/rmmod.pl load from the v4l dir of the http://jusst.de/hg/multiproto it should work out of the box :-)
I use this small script in order to update/compil it (p=4000.diff is just a patch to enable support for my card which for an unknow reason isn't included sofar in multiproto).
By the way, I have no idea if your card need a firmware or not... mine even if it's a budget one need one.
Good luck,
Will try the script this evening
Someone told me while looking at my logs on the dvbkivabien site, that the tuner of the S2-3200 was'tn detected. Do you know what I should see in lsmod if it was (what are I looking for ?).
If a use a non dvbs2/h264 patched vdr, should the s2-3200 work in only dvb-s mode or am I obliged to use a patched vdr to have any result ? (just looking to have an image for the moment, not that interested in HD for the time being).
Thanks,
Serge
-----Oorspronkelijk bericht----- Van: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] Namens Gregoire Favre Verzonden: donderdag 10 januari 2008 17:44 Aan: VDR Mailing List Onderwerp: Re: [vdr] Two VDR's on one machine
On Thu, Jan 10, 2008 at 02:29:58PM +0100, serge pecher wrote:
Thanks for the info. Could you have a look at http://dvbkivabien2.info/viewtopic.php?f=7&t=12943&p=121435#p121435 where
a
gave more explanation about my problem. Its seems that the tuner of the S2-3200 is not detected, but I dont know what to do.
Well,
it don't seems you have a guest access to read it ?
I don't have a S2-3200, but I think the first revision has a problem (that was the main reason not to buy one) the best place to seek for information is vdrportal.de in which there are a few topics about this card.
But honestly, if you did a ./scripts/rmmod.pl load from the v4l dir of the http://jusst.de/hg/multiproto it should work out of the box :-)
I use this small script in order to update/compil it (p=4000.diff is just a patch to enable support for my card which for an unknow reason isn't included sofar in multiproto).
By the way, I have no idea if your card need a firmware or not... mine even if it's a budget one need one.
Good luck,
On Thu, Jan 10, 2008 at 07:33:11PM +0100, serge pecher wrote:
Hello,
Will try the script this evening
You could maybe first start it with unload option to be sure there aren't other modules loaded about DVB, also you have to be sure DVB wasn't compiled in the kernel.
The simple script was only to update and compil the modules, use the scripts/rmmod.pl to load / unload the modules.
Someone told me while looking at my logs on the dvbkivabien site, that the tuner of the S2-3200 was'tn detected. Do you know what I should see in lsmod if it was (what are I looking for ?).
One could also simply use dmesg, like here :
dmesg |grep DVB|grep regi which here gives me :
DVB: registering new adapter (TT-Budget/WinTV-NOVA-CI PCI) DVB: registering frontend 0 (ST STV0299 DVB-S)... DVB: registering new adapter (cx88[0]) DVB: registering frontend 1 (Conexant CX24116/CX24118)... DVB: registering new adapter (cx88[1]) DVB: registering frontend 2 (Conexant CX24123/CX24109)...
So my 3 cards are detected right.
If a use a non dvbs2/h264 patched vdr, should the s2-3200 work in only dvb-s mode or am I obliged to use a patched vdr to have any result ? (just looking to have an image for the moment, not that interested in HD for the time being).
If you use multiproto driver from just.de then you have to use a patched VDR (it's a guess as I didn't try it with an vanilla VDR).
Good luck,
Hi,
serge pecher schrieb:
Could you have a look at http://dvbkivabien2.info/viewtopic.php?f=7&t=12943&p=121435#p121435 where a gave more explanation about my problem. Its seems that the tuner of the S2-3200 is not detected, but I don’t know what to do.
Well, I don't understand French.
Try this: cd /path/to/multiproto/tree make unload make load
Check the output of dmesg now or have a look at /var/log/messages (other distributions my use a different file).
Bye.
As far as I can see I get the needed modules loaded (stb6100, stb0899, lnbp21 saa7416, budget-ci) When I try make unload and make load it loads 204 modules and I get no image at all anymore in vdr, nor on the nexus-s nor on the s2-3200. I think because s2-3200 comes as adapter0 and nexus as adapter1 When I rmmod all modules and just modprobe dvb-ttpci and stv0299, it works normally. When I modprobe stb6100, stb0899 and budget-ci, I can see an image on the nexus for a few minutes and then I read in the logs "now tuned to ..." and I get a black screen.
Thanks for your assistance
serge
-----Oorspronkelijk bericht----- Van: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] Namens Reinhard Nissl Verzonden: donderdag 10 januari 2008 22:44 Aan: VDR Mailing List Onderwerp: Re: [vdr] Two VDR's on one machine
Hi,
serge pecher schrieb:
Could you have a look at http://dvbkivabien2.info/viewtopic.php?f=7&t=12943&p=121435#p121435 where
a
gave more explanation about my problem. Its seems that the tuner of the S2-3200 is not detected, but I don't know what to do.
Well, I don't understand French.
Try this: cd /path/to/multiproto/tree make unload make load
Check the output of dmesg now or have a look at /var/log/messages (other distributions my use a different file).
Bye.
Reinhard Nissl wrote:
The attached patch allows now to define timeouts and frequencies for example in Make.config, so there is no need to patch every VDR version. Furthermore, frequencies are now defined in unit 1/s instead of the unit ms (which defined the period), making values more intuitive.
I would prefer some OSD settings for LIRC (if possible) because on every VDR setup you are able to do first controls with the keyboard. So you could access the settings menu and tune the LIRC settings the way you want. A makefile settings also will not work if you use some prebuild packages. I also remember the time using LIRC when I always had to patch the lirc code - currently, I am glad being able to use DVB-IR. :)
With kind regards
Jörg
On 01/09/08 00:44, Reinhard Nissl wrote:
Hi,
I was quite annoyed how I could operate my EPIA MII-6000E using a LIRC remote. It was almost not possible to navigate through the OSD in a fast way.
The attached patch allows now to define timeouts and frequencies for example in Make.config, so there is no need to patch every VDR version. Furthermore, frequencies are now defined in unit 1/s instead of the unit ms (which defined the period), making values more intuitive.
There's now an additional frequency which defines, how fast a user is allowed to press the same button repeatedly. The originally used REPEATDELAY allowed only 2.85 button presses per second.
On slow and busy machines like my EPIA it happened often that several button presses were read by VDR in a single read, but only the first one got processed. The code now reads only a single button press from LIRC's socket, so button presses don't get lost (although presses of the same button will be skipped as the timeouts don't get reached).
To make it less likely that button presses get processed in chunks a further define allows to decrease the thread's niceness which means to boost it's priority. This feature requires VDR to be run as root.
This is my setup which follows some common settings found in mainboard bioses for keyboard repeat delay and frequency.
#vdr REMOTE=LIRC LIRC_PUSHFREQ=64 # 1/s LIRC_REPEATDELAY=250 # ms LIRC_REPEATFREQ=32 # 1/s #LIRC_REPEATTIMEOUT=500 # ms #LIRC_RECONNECTDELAY=3000 # ms LIRC_PRIORITYBOOST=1
Isn't there a way to have all this done in LIRC itself? I can hardly imagine that all other applications using LIRC do such elaborate parameter fiddling, too.
Klaus
Klaus Schmidinger wrote:
On 01/09/08 00:44, Reinhard Nissl wrote:
#vdr REMOTE=LIRC LIRC_PUSHFREQ=64 # 1/s LIRC_REPEATDELAY=250 # ms LIRC_REPEATFREQ=32 # 1/s #LIRC_REPEATTIMEOUT=500 # ms #LIRC_RECONNECTDELAY=3000 # ms LIRC_PRIORITYBOOST=1
Isn't there a way to have all this done in LIRC itself? I can hardly imagine that all other applications using LIRC do such elaborate parameter fiddling, too.
I think most other applications use the lirc library instead of directly parsing the commands.
On 02/09/08 13:53, Anssi Hannula wrote:
Klaus Schmidinger wrote:
On 01/09/08 00:44, Reinhard Nissl wrote:
#vdr REMOTE=LIRC LIRC_PUSHFREQ=64 # 1/s LIRC_REPEATDELAY=250 # ms LIRC_REPEATFREQ=32 # 1/s #LIRC_REPEATTIMEOUT=500 # ms #LIRC_RECONNECTDELAY=3000 # ms LIRC_PRIORITYBOOST=1
Isn't there a way to have all this done in LIRC itself? I can hardly imagine that all other applications using LIRC do such elaborate parameter fiddling, too.
I think most other applications use the lirc library instead of directly parsing the commands.
Then maybe that would be a good idea for VDR, too?
Klaus
-
Anssi Hannula -
Dominique Matz -
Gavin Hamill -
Gregoire Favre -
Jörg Knitter -
Klaus Schmidinger -
Ludwig Nussel -
Magnus Hörlin -
Nicolas Huillard -
Reinhard Nissl -
serge pecher -
Ville Skyttä