VDR developer version 1.3.31 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.31.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.30-31.diff
The changes since version 1.3.30:
- Added missing German OSD texts for 'Audio language'. - The Setup/CICAM menu now only contains the devices that actually have a CI and dynamically detects the number of slots a CI provides. - Implemented cAudioRepacker for better handling of audio PES packets (thanks to Reinhard Nissl). - Modified handling of audio packets for radio channels in remux.c (thanks to Reinhard Nissl). - Updated the Danish OSD texts (thanks to Mogens Elneff). - Fixed the EPG scan, so that it doesn't use the primary device if that is currently in Transfer-Mode from itself (thanks to Marcus Hilbrich for a bug report that lead to this). - Removed the TUNER_LOCK_TIMEOUT in cDevice::AttachReceiver() since it caused more trouble than it fixed. - Fixed detecting short channel names for "Kabel Deutschland", who uses a comma as delimiter (thanks to Marco Schlüßler). - Moved cMenuEditTimer and cMenuEvent to menu.h so that plugins can use it (suggested by Thomas Günther). - The new static function cString::sprintf() can be used to easily create a formatted string. - Plugins can now implement their own SVDRP commands (based on a patch from Hardy Flor). See PLUGINS.html, section "SVDRP commands" for details. The SVDRP commands of a plugin are accessed through the new SVDRP command PLUG. See PLUGINS/src/svdrpdemo for an example of how to use this feature. - The new SVDRP command PLAY can be used to start replaying a recording (thanks to Hardy Flor). - The new SVDRP command EDIT can be used to start the editing process of a recording (based on the CUTR patch by Harald Milz).
I'm gradually trying to tie up lose ends and make a stable version 1.4 now. Now before somebody asks: yes, I'm planning to implement the ability to call the main menu function of a plugin through a key macro, even if that plugin doesn't define a main menu entry; and it will also be possible to do so from an SVDRP connection.
The maintainers of the various OSD language texts should please check VDR/i18n.c and send me any changes they find necessary.
Have fun!
Klaus
Klaus Schmidinger wrote:
- Removed the TUNER_LOCK_TIMEOUT in cDevice::AttachReceiver() since it
caused more trouble than it fixed.
Now the question is, did you think something about steerable dishes wrt recordings/eit scan ? I'm asking because... [...]
I'm gradually trying to tie up lose ends and make a stable version 1.4 now.
Bye
Klaus Schmidinger wrote:
I'm gradually trying to tie up lose ends and make a stable version 1.4 now.
This one got out of sight too:
I'm thinking about a function like
cOsdObject *cPlugin::Popup(void);
which would be called in every turn of the main loop
(from Re: [vdr] [PATCH] fix segfault in cSkins::Message, 2005-07-31)
I hope this will make it before 1.4 too.
Cheers,
Udo
Klaus Schmidinger wrote:
See PLUGINS/src/svdrpdemo for an example of how to use this feature.
... throws a warning on gcc 3.3.5: svdrpdemo.c:13: Warning: `const char*MAINMENUENTRY' defined but not used
If there are no plans to grep for this (like for VERSION) I suggest dropping the whole line so no one gets confused by the warning.
Cheers,
Udo
Klaus Schmidinger wrote: ...
I'm gradually trying to tie up lose ends and make a stable version 1.4 now.
I am not happy with the performance of VDR 1.3's 'recordings' menu. At least on my system, it takes 30 seconds or longer to bring up the 'recordings' menu after vdr has been restarted or after the .update file has been touched (This may have to do with the fact that I have 9 VDR disks which spin down when not in use for 5 minutes). Members of my family often inadvertendly start the first recording because they press OK several times after the 'recordings' menu is seemingly not reacting.
Improvements in that area can come from Ralf Müller's "Patch to avoid file system buffer trashing" and from my "Patch to get rid of redundant resume.vdr files".
It would also be nice if VDR would at least switch from the main menu to the (initially empty) 'recordings' menu immediately when the 'recordings' menu is selected.
Klaus, are any of the above 3 modifications going to make it into 1.3 before the switch to 1.4?
Thanks,
Carsten.
Udo Richter wrote:
Klaus Schmidinger wrote:
See PLUGINS/src/svdrpdemo for an example of how to use this feature.
... throws a warning on gcc 3.3.5: svdrpdemo.c:13: Warning: `const char*MAINMENUENTRY' defined but not used
If there are no plans to grep for this (like for VERSION) I suggest dropping the whole line so no one gets confused by the warning.
I am also getting the following warnings in remux.c:
remux.c:537: warning: missing braces around initializer remux.c:537: warning: missing braces around initializer remux.c:537: warning: missing braces around initializer remux.c:537: warning: missing braces around initializer remux.c:537: warning: missing braces around initializer remux.c:537: warning: missing braces around initializer remux.c: In static member function `static bool cAudioRepacker::IsValidAudioHeader(uint32_t, bool, int*)': remux.c:596: warning: missing braces around initializer remux.c:603: warning: missing braces around initializer
Anyone know whats wrong?
Regards,
C.Y.M wrote:
Udo Richter wrote:
Klaus Schmidinger wrote:
See PLUGINS/src/svdrpdemo for an example of how to use this feature.
... throws a warning on gcc 3.3.5: svdrpdemo.c:13: Warning: `const char*MAINMENUENTRY' defined but not used
If there are no plans to grep for this (like for VERSION) I suggest dropping the whole line so no one gets confused by the warning.
I am also getting the following warnings in remux.c:
remux.c:537: warning: missing braces around initializer remux.c:537: warning: missing braces around initializer remux.c:537: warning: missing braces around initializer remux.c:537: warning: missing braces around initializer remux.c:537: warning: missing braces around initializer remux.c:537: warning: missing braces around initializer remux.c: In static member function `static bool cAudioRepacker::IsValidAudioHeader(uint32_t, bool, int*)': remux.c:596: warning: missing braces around initializer remux.c:603: warning: missing braces around initializer
Anyone know whats wrong?
The attached patch should fix this.
Klaus
--- remux.c 2005/08/28 11:46:44 1.42 +++ remux.c 2005/08/28 17:02:34 @@ -522,18 +522,22 @@ };
int cAudioRepacker::bitRates[2][3][16] = { // all values are specified as kbits/s + { // MPEG 1, Layer I - 0, 32, 64, 96, 128, 160, 192, 224, 256, 288, 320, 352, 384, 416, 448, -1, + { 0, 32, 64, 96, 128, 160, 192, 224, 256, 288, 320, 352, 384, 416, 448, -1 }, // MPEG 1, Layer II - 0, 32, 48, 56, 64, 80, 96, 112, 128, 160, 192, 224, 256, 320, 384, -1, + { 0, 32, 48, 56, 64, 80, 96, 112, 128, 160, 192, 224, 256, 320, 384, -1 }, // MPEG 1, Layer III - 0, 32, 40, 48, 56, 64, 80, 96, 112, 128, 160, 192, 224, 256, 320, -1, + { 0, 32, 40, 48, 56, 64, 80, 96, 112, 128, 160, 192, 224, 256, 320, -1 } + }, + { // MPEG 2, Layer I - 0, 32, 48, 56, 64, 80, 96, 112, 128, 144, 160, 176, 192, 224, 256, -1, + { 0, 32, 48, 56, 64, 80, 96, 112, 128, 144, 160, 176, 192, 224, 256, -1 }, // MPEG 2, Layer II/III - 0, 8, 16, 24, 32, 40, 48, 56, 64, 80, 96, 112, 128, 144, 160, -1, + { 0, 8, 16, 24, 32, 40, 48, 56, 64, 80, 96, 112, 128, 144, 160, -1 }, // MPEG 2, Layer II/III - 0, 8, 16, 24, 32, 40, 48, 56, 64, 80, 96, 112, 128, 144, 160, -1 + { 0, 8, 16, 24, 32, 40, 48, 56, 64, 80, 96, 112, 128, 144, 160, -1 } + } };
cAudioRepacker::cAudioRepacker(void) @@ -590,16 +594,16 @@ else { static int samplingFrequencies[2][4] = { // all values are specified in Hz // MPEG 1 - 44100, 48000, 32000, -1, + { 44100, 48000, 32000, -1 }, // MPEG 2 - 22050, 24000, 16000, -1 + { 22050, 24000, 16000, -1 } };
static int slots_per_frame[2][3] = { // MPEG 1, Layer I, II, III - 12, 144, 144, + { 12, 144, 144 }, // MPEG 2, Layer I, II, III - 12, 144, 72 + { 12, 144, 72 } };
int mpegIndex = 1 - id;
Hi,
Klaus Schmidinger wrote:
I am also getting the following warnings in remux.c:
remux.c:537: warning: missing braces around initializer remux.c:537: warning: missing braces around initializer remux.c:537: warning: missing braces around initializer remux.c:537: warning: missing braces around initializer remux.c:537: warning: missing braces around initializer remux.c:537: warning: missing braces around initializer remux.c: In static member function `static bool cAudioRepacker::IsValidAudioHeader(uint32_t, bool, int*)': remux.c:596: warning: missing braces around initializer remux.c:603: warning: missing braces around initializer
Anyone know whats wrong?
I'm sorry for causing these warnings. The arrays were originally one dimensional, but for my recent enhancements it was more suitable to make them multi dimensional.
Thanks to Klaus for supplying the initializer fix!
Bye.
Carsten Koch wrote:
Klaus Schmidinger wrote: ...
I'm gradually trying to tie up lose ends and make a stable version 1.4 now.
I am not happy with the performance of VDR 1.3's 'recordings' menu. At least on my system, it takes 30 seconds or longer to bring up the 'recordings' menu after vdr has been restarted or after the .update file has been touched (This may have to do with the fact that I have 9 VDR disks which spin down when not in use for 5 minutes). Members of my family often inadvertendly start the first recording because they press OK several times after the 'recordings' menu is seemingly not reacting.
Improvements in that area can come from Ralf Müller's "Patch to avoid file system buffer trashing" and from my "Patch to get rid of redundant resume.vdr files".
It would also be nice if VDR would at least switch from the main menu to the (initially empty) 'recordings' menu immediately when the 'recordings' menu is selected.
Klaus, are any of the above 3 modifications going to make it into 1.3 before the switch to 1.4?
Reading the recordings list is still one of the "lose ends" ;-)
Klaus
Luca Olivetti wrote:
Klaus Schmidinger wrote:
- Removed the TUNER_LOCK_TIMEOUT in cDevice::AttachReceiver() since it
caused more trouble than it fixed.
Now the question is, did you think something about steerable dishes wrt recordings/eit scan ?
Well, I'm afraid I'll have to postpone that until after version 1.4. At some point you just have to decide what to do now and what to do later, and since I firmly believe that most VDR users don't have a motorized dish, the priority for this is not too high.
Klaus
I demand that Klaus Schmidinger may or may not have written...
[snip]
Reading the recordings list is still one of the "lose ends" ;-)
That's "loose ends" - you lose ;-)
Darren,
Not that I'm german or anything, but I learnt the word "besserwisser" :P
See http://www.dict.cc/?s=Besserwisser
Stefan
Reading the recordings list is still one of the "lose ends" ;-)
That's "loose ends" - you lose ;-)
Stefan Norberg wrote:
Darren,
Not that I'm german or anything, but I learnt the word "besserwisser" :P
See http://www.dict.cc/?s=Besserwisser
Stefan
Reading the recordings list is still one of the "lose ends" ;-)
That's "loose ends" - you lose ;-)
Nevermind - I always had trouble keeping these two apart ;-)
Klaus
Lauri Tischler wrote:
Klaus Schmidinger wrote:
I'm gradually trying to tie up lose ends and make a stable version 1.4 now.
Few lines in INSTALL about DVBDIR in case of dvb-kernel drivers would be nice.
Well, if somebody would care to write them... ;-)
Personally I'm still running kernel 2.4.20 and the DVB driver, and that will most likely be the platform I'll be using when I release version 1.4.
Klaus
Klaus Schmidinger wrote:
Lauri Tischler wrote:
Klaus Schmidinger wrote:
I'm gradually trying to tie up lose ends and make a stable version 1.4 now.
Few lines in INSTALL about DVBDIR in case of dvb-kernel drivers would be nice.
Well, if somebody would care to write them... ;-)
I think it's enough to say that if you use 2.6 Kernels the DVBDIR should be expanded to [..]/DVB/linux
Personally I'm still running kernel 2.4.20 and the DVB driver, and that will most likely be the platform I'll be using when I release version 1.4.
:) as you like ..... (NPTL, 2.6 and stuff like that you will face in future :) )
Klaus
/hgm.bg
Klaus Schmidinger wrote:
Lauri Tischler wrote:
Klaus Schmidinger wrote:
I'm gradually trying to tie up lose ends and make a stable version 1.4 now.
Few lines in INSTALL about DVBDIR in case of dvb-kernel drivers would be nice.
Well, if somebody would care to write them... ;-)
--- clip --- --- INSTALL.orig 2005-07-31 14:34:37.000000000 +0300 +++ INSTALL 2005-08-30 09:26:24.000000000 +0300 @@ -30,9 +30,21 @@ about that driver). For example, if the DVB driver was extracted into the directory /home/kls/vdr/DVB, then this package should be extracted into /home/kls/vdr/VDR. -If you have the DVB driver source in a different location -you will have to change the definition of DVBDIR in the -Makefile (see the file Make.config.template). + +If you have the DVB driver source in a different location, +copy Make.config.template into Make.config and replace in the line +'DVBDIR = ../DVB' the location '../DVB' with the real location +of your driver. + +If you are using newer ver. 2.6.x kernels with builtin drivers. +copy Make.config.template into Make.config and replace in the line +'DVBDIR = ../DVB' the location '../DVB' with the location of your +kernels sourcetree, typically '/usr/src/linux', +ie. DVBDIR = /usr/src/linux + +Modifying the standard Makefile of VDR is not enough, because +plugins also need to know the location of dvb-include-files. +
VDR requires the Linux-DVB card driver version dated 2003-08-23 or higher to work properly. ------
Lauri Tischler wrote:
+If you are using newer ver. 2.6.x kernels with builtin drivers. +copy Make.config.template into Make.config and replace in the line +'DVBDIR = ../DVB' the location '../DVB' with the location of your +kernels sourcetree, typically '/usr/src/linux', +ie. DVBDIR = /usr/src/linux
I think required kernel headers can be more distro independently found in DVBDIR=/lib/modules/`uname -r`/build providing distro is based on 2.6 kernel.
Distributions provide this link or directory and required files when following packages are installed: Fedora: kernel, kernel-devel Suse: kernel-default, kernel-source Debian: kernel-image, kernel-headers or kernel-source
Kimmo Vuorinen wrote:
Lauri Tischler wrote:
+If you are using newer ver. 2.6.x kernels with builtin drivers. +copy Make.config.template into Make.config and replace in the line +'DVBDIR = ../DVB' the location '../DVB' with the location of your +kernels sourcetree, typically '/usr/src/linux', +ie. DVBDIR = /usr/src/linux
I think required kernel headers can be more distro independently found in DVBDIR=/lib/modules/`uname -r`/build providing distro is based on 2.6 kernel.
Distributions provide this link or directory and required files when following packages are installed: Fedora: kernel, kernel-devel Suse: kernel-default, kernel-source Debian: kernel-image, kernel-headers or kernel-source
Umm.. yes, replace line DVBDIR=../DVB in all Makefiles with ---- case `uname -r` in 2.6.*) DVBDIR=lib/modules/`uname -r`/build ;; *) DVBDIR=../DVB ;; esac ---- Must be done also in plugins
Lauri Tischler wrote:
Kimmo Vuorinen wrote:
Lauri Tischler wrote:
+If you are using newer ver. 2.6.x kernels with builtin drivers. +copy Make.config.template into Make.config and replace in the line +'DVBDIR = ../DVB' the location '../DVB' with the location of your +kernels sourcetree, typically '/usr/src/linux', +ie. DVBDIR = /usr/src/linux
I think required kernel headers can be more distro independently found in DVBDIR=/lib/modules/`uname -r`/build providing distro is based on 2.6 kernel.
Distributions provide this link or directory and required files when following packages are installed: Fedora: kernel, kernel-devel Suse: kernel-default, kernel-source Debian: kernel-image, kernel-headers or kernel-source
Umm.. yes, replace line DVBDIR=../DVB in all Makefiles with
case `uname -r` in 2.6.*) DVBDIR=lib/modules/`uname -r`/build ;; *) DVBDIR=../DVB ;; esac
Must be done also in plugins
Wouldn't
case `uname -r` in 2.4.*) DVBDIR=../DVB ;; *) DVBDIR=lib/modules/`uname -r`/build ;; esac
be better? Otherwise kernel 2.7 and up would use the "old" driver again...
Klaus
Kimmo Vuorinen wrote:
Lauri Tischler wrote:
+If you are using newer ver. 2.6.x kernels with builtin drivers. +copy Make.config.template into Make.config and replace in the line +'DVBDIR = ../DVB' the location '../DVB' with the location of your +kernels sourcetree, typically '/usr/src/linux', +ie. DVBDIR = /usr/src/linux
I think required kernel headers can be more distro independently found in DVBDIR=/lib/modules/`uname -r`/build providing distro is based on 2.6 kernel.
Distributions provide this link or directory and required files when following packages are installed: Fedora: kernel, kernel-devel Suse: kernel-default, kernel-source Debian: kernel-image, kernel-headers or kernel-source
Hi, current distros should have dvb headers in /usr/include/linux/dvb, at least my has.
Andreas
Klaus Schmidinger wrote:
Lauri Tischler wrote:
Kimmo Vuorinen wrote:
Lauri Tischler wrote:
+If you are using newer ver. 2.6.x kernels with builtin drivers. +copy Make.config.template into Make.config and replace in the line +'DVBDIR = ../DVB' the location '../DVB' with the location of your +kernels sourcetree, typically '/usr/src/linux', +ie. DVBDIR = /usr/src/linux
I think required kernel headers can be more distro independently found in DVBDIR=/lib/modules/`uname -r`/build providing distro is based on 2.6 kernel.
Distributions provide this link or directory and required files when following packages are installed: Fedora: kernel, kernel-devel Suse: kernel-default, kernel-source Debian: kernel-image, kernel-headers or kernel-source
Umm.. yes, replace line DVBDIR=../DVB in all Makefiles with
case `uname -r` in 2.6.*) DVBDIR=lib/modules/`uname -r`/build ;; *) DVBDIR=../DVB ;; esac
Must be done also in plugins
Wouldn't
case `uname -r` in 2.4.*) DVBDIR=../DVB ;; *) DVBDIR=lib/modules/`uname -r`/build ;; esac
be better? Otherwise kernel 2.7 and up would use the "old" driver again...
Of course. Is bleeding edge 2.7.x allready open ?
Klaus Schmidinger wrote:
Lauri Tischler wrote:
Kimmo Vuorinen wrote:
Lauri Tischler wrote:
+If you are using newer ver. 2.6.x kernels with builtin drivers. +copy Make.config.template into Make.config and replace in the line +'DVBDIR = ../DVB' the location '../DVB' with the location of your +kernels sourcetree, typically '/usr/src/linux', +ie. DVBDIR = /usr/src/linux
I think required kernel headers can be more distro independently found in DVBDIR=/lib/modules/`uname -r`/build providing distro is based on 2.6 kernel.
Distributions provide this link or directory and required files when following packages are installed: Fedora: kernel, kernel-devel Suse: kernel-default, kernel-source Debian: kernel-image, kernel-headers or kernel-source
Umm.. yes, replace line DVBDIR=../DVB in all Makefiles with
case `uname -r` in 2.6.*) DVBDIR=lib/modules/`uname -r`/build ;; *) DVBDIR=../DVB ;; esac
Must be done also in plugins
Wouldn't
case `uname -r` in 2.4.*) DVBDIR=../DVB ;; *) DVBDIR=lib/modules/`uname -r`/build ;; esac
be better? Otherwise kernel 2.7 and up would use the "old" driver again...
Maybe to cover ancient history...
case `uname -r` in 2.[01234].*) DVBDIR=../DVB ;; *) DVBDIR=lib/modules/`uname -r`/build ;; esac
Lauri Tischler wrote:
To cover odd place for drivers uncomment first line
# DVBDIR=/very/odd/place ifndef DVBDIR case `uname -r` in 2.[01234].*) DVBDIR=../DVB ;; *) DVBDIR=lib/modules/`uname -r`/build ;; esac endif
Lauri Tischler wrote:
Lauri Tischler wrote:
To cover odd place for drivers uncomment first line
# DVBDIR=/very/odd/place ifndef DVBDIR case `uname -r` in 2.[01234].*) DVBDIR=../DVB ;; *) DVBDIR=lib/modules/`uname -r`/build ;; esac endif
Ok, and now the whole thing in Makefile syntax, please... ;-)
Klaus
Klaus Schmidinger wrote:
Ok, and now the whole thing in Makefile syntax, please... ;-)
# DVBDIR=/very/odd/place ifndef DVBDIR DVBDIR=$(shell ./getdvbdir.sh) endif
--- getdvbdir.sh --- #!/bin/bash case `uname -r` in 2.[01234].*) DVBDIR=../DVB ;; *) DVBDIR=lib/modules/`uname -r`/build ;; esac echo $DVBDIR
Lauri Tischler wrote:
Klaus Schmidinger wrote:
Ok, and now the whole thing in Makefile syntax, please... ;-)
# DVBDIR=/very/odd/place ifndef DVBDIR DVBDIR=$(shell ./getdvbdir.sh) endif
--- getdvbdir.sh --- #!/bin/bash case `uname -r` in 2.[01234].*) DVBDIR=../DVB ;; *) DVBDIR=lib/modules/`uname -r`/build ;; esac echo $DVBDIR
Ugly, very ugly - requires an extra file...
Klaus
Klaus Schmidinger wrote:
Lauri Tischler wrote:
Klaus Schmidinger wrote:
Ok, and now the whole thing in Makefile syntax, please... ;-)
# DVBDIR=/very/odd/place ifndef DVBDIR DVBDIR=$(shell ./getdvbdir.sh) endif
--- getdvbdir.sh --- #!/bin/bash case `uname -r` in 2.[01234].*) DVBDIR=../DVB ;; *) DVBDIR=lib/modules/`uname -r`/build ;; esac echo $DVBDIR
Ugly, very ugly - requires an extra file...
Yeah, I'm too dumb :( Any Makefile gurus around ?
Lauri Tischler wrote: ...
Ugly, very ugly - requires an extra file...
Yeah, I'm too dumb :( Any Makefile gurus around ?
LINUX_VERSION:=$(shell uname -r | cut -c-3)
DVBDIR:=lib/modules/`uname -r`/build ifeq ($(LINUX_VERSION), 2.4) DVBDIR=../DVB endif
ifeq ($(LINUX_VERSION), 2.2) DVBDIR=../DVB endif
...
Carsten Koch wrote:
Lauri Tischler wrote: ...
Ugly, very ugly - requires an extra file...
Yeah, I'm too dumb :( Any Makefile gurus around ?
LINUX_VERSION:=$(shell uname -r | cut -c-3)
DVBDIR:=lib/modules/`uname -r`/build ifeq ($(LINUX_VERSION), 2.4) DVBDIR=../DVB endif
ifeq ($(LINUX_VERSION), 2.2) DVBDIR=../DVB endif
Not quite..
LINUX_VERSION:=$(shell uname -r | cut -c-3) LINUX:=$(shell uname -r) DVBDIR:=/lib/modules/$(LINUX)/build ifeq ($(LINUX_VERSION), 2.4) DVBDIR=../DVB endif
ifeq ($(LINUX_VERSION), 2.2) DVBDIR=../DVB endif
Lauri Tischler wrote: ...
Not quite..
I like your version better. My version works too, though:
/tmp/m> cat Makefile LINUX_VERSION:=$(shell uname -r | cut -c-3)
DVBDIR:=lib/modules/`uname -r`/build ifeq ($(LINUX_VERSION), 2.4) DVBDIR:=../DVB endif
ifeq ($(LINUX_VERSION), 2.2) DVBDIR:=../DVB endif
all: echo $(DVBDIR) /tmp/m> make echo lib/modules/`uname -r`/build lib/modules/2.6.11.4-21.8-smp/build
Carsten.
Carsten Koch wrote:
Lauri Tischler wrote: ...
Not quite..
I like your version better. My version works too, though:
/tmp/m> cat Makefile LINUX_VERSION:=$(shell uname -r | cut -c-3)
DVBDIR:=lib/modules/`uname -r`/build ifeq ($(LINUX_VERSION), 2.4) DVBDIR:=../DVB endif
ifeq ($(LINUX_VERSION), 2.2) DVBDIR:=../DVB endif
all: echo $(DVBDIR) /tmp/m> make echo lib/modules/`uname -r`/build lib/modules/2.6.11.4-21.8-smp/build
when running make just thought that it was odd ... -Ilib/modules/`uname -r`/build/include menu.c
Also / was missing from front of lib
In 43159957.6080207@iki.fi, Lauri Tischler wrote:
Also / was missing from front of lib
I've been wondering about that all through the thread too.
Hi Gyys,
I have experienced a strange problem after upgrading to 1.3.31. The remote key repeat is so fast that I haven't succeeded to change channels reasonably. A single press of any key gives two presses. I have tried to track the problem down without any success.
Reverting to 1.3.30 and everything is working.
System: Silverstone 10M (soundgraph remote & lcd) Dvb-s FF version 1.3 Dvb-t Nova-T (cx88xx). plugins: remote, lcdproc, text2skin, epgsearch, femon,...
Any hint will be greatly appreciated.
regards, Chris
Andreas Regel wrote:
Kimmo Vuorinen wrote:
I think required kernel headers can be more distro independently found in DVBDIR=/lib/modules/`uname -r`/build providing distro is based on 2.6 kernel.
Distributions provide this link or directory and required files when following packages are installed: Fedora: kernel, kernel-devel Suse: kernel-default, kernel-source Debian: kernel-image, kernel-headers or kernel-source
Hi, current distros should have dvb headers in /usr/include/linux/dvb, at least my has.
Sure, but they necessarily aren't the same as in currently running kernel as these are provided by glibc-packages. I don't know if it matters in this case.
On Wed, Aug 31, 2005 at 04:33:25PM +0300, Chris Ariyo wrote:
I have experienced a strange problem after upgrading to 1.3.31. The remote key repeat is so fast that I haven't succeeded to change channels reasonably. A single press of any key gives two presses. I have tried to track the problem down without any success.
I assume you're using the remote control unit bundled with the Hauppauge Nova-T PCI 90002. I tried the vdr-remote plugin quite some time ago, before switching from dxr3 output to softdevice output on DirectFB.
Maybe key-release events are somehow misinterpreted as key-press events? The softdevice remote control driver doesn't report key-release events to VDR. When I tried to add them, I faced some problems (can't remember which exactly, though). The Linux cx88 remote control driver will report key-release events (see evtest output).
See also the patch I posted a few days ago, for making cInterface::Wait() ignore k_Repeat events.
Any hint will be greatly appreciated.
If you are interested in trying softdevice-dfb on the Nova-T, see my patches at http://www.funet.fi/~msmakela/software/vdr/. Current DirectFB doesn't distinguish key-press and key-repeat events.
Marko
Kimmo Vuorinen a écrit :
Lauri Tischler wrote:
+If you are using newer ver. 2.6.x kernels with builtin drivers. +copy Make.config.template into Make.config and replace in the line +'DVBDIR = ../DVB' the location '../DVB' with the location of your +kernels sourcetree, typically '/usr/src/linux', +ie. DVBDIR = /usr/src/linux
I think required kernel headers can be more distro independently found in DVBDIR=/lib/modules/`uname -r`/build providing distro is based on 2.6 kernel.
Distributions provide this link or directory and required files when following packages are installed: Fedora: kernel, kernel-devel Suse: kernel-default, kernel-source Debian: kernel-image, kernel-headers or kernel-source
I do not have that link on a Debian sarge box with a standard kernel (kernel-image-2.6.8-2-k7). This is the official latest (2.6.8-16) kernel image. On boxes where I compiled the kernel (most of them, in fact), the link exists.
In 20050831140707.GC3149@localhost.localdomain, Marko Mäkelä wrote:
On Wed, Aug 31, 2005 at 04:33:25PM +0300, Chris Ariyo wrote:
I have experienced a strange problem after upgrading to 1.3.31. The remote key repeat is so fast that I haven't succeeded to change channels reasonably. A single press of any key gives two presses. I have tried to track the problem down without any success.
I assume you're using the remote control unit bundled with the Hauppauge Nova-T PCI 90002. I tried the vdr-remote plugin quite some time ago, before switching from dxr3 output to softdevice output on DirectFB.
[Snip]
If you are interested in trying softdevice-dfb on the Nova-T, see my patches at http://www.funet.fi/~msmakela/software/vdr/. Current DirectFB doesn't distinguish key-press and key-repeat events.
I know lirc has/had that problem with devinput remotes like the Nova-T one so I patched it, but I haven't used lirc for a long time, nor VDR's remote plugin. I didn't realise VDR could access the remote via softdevice/DirectFB too.
I demand that Lauri Tischler may or may not have written...
[snip]
Is bleeding edge 2.7.x allready open ?
"Bleeding edge" is -mm these days.
Hi,
If you are interested in trying softdevice-dfb on the Nova-T, see my patches at http://www.funet.fi/~msmakela/software/vdr/. Current DirectFB doesn't distinguish key-press and key-repeat events.
Sorry I am not using the Nova-T remote, I am using the soundgraph imon remote that works with version 1.3.30.
regards, Chris
Hi,
I assume you're using the remote control unit bundled with the Hauppauge Nova-T PCI 90002. I tried the vdr-remote plugin quite some time ago, before switching from dxr3 output to softdevice output on DirectFB.
Sorry it was not clear in my post that I am using soundgraph imon usb remote that worked without any problem in all of the earlier vdr versions before 1.3.31.
-- snip --
regards, Chris
Chris Ariyo wrote:
Hi Gyys,
I have experienced a strange problem after upgrading to 1.3.31. The remote key repeat is so fast that I haven't succeeded to change channels reasonably. A single press of any key gives two presses. I have tried to track the problem down without any success.
Reverting to 1.3.30 and everything is working.
System: Silverstone 10M (soundgraph remote & lcd) Dvb-s FF version 1.3 Dvb-t Nova-T (cx88xx). plugins: remote, lcdproc, text2skin, epgsearch, femon,...
Since there was no change in VDR's remote.c, thread.c or keys.c between these two versions maybe there is something wrong with your remote plugin?
Klaus
Chris Ariyo wrote:
Sorry it was not clear in my post that I am using soundgraph imon usb remote that worked without any problem in all of the earlier vdr versions before 1.3.31.
Are you sure that you did not change something else like compiler, kernel, driver etc.?
Sorry, I can't see why the remote plugin should behave in a different way with vdr 1.3.31.
Oliver
Hi,
Oliver Endriss wrote:
Are you sure that you did not change something else like compiler, kernel, driver etc.?
I have not changed anything in particular lately. I am runing suse 9.3 kernel 2.6.11.4 and works with earlier vdr versions.
Sorry, I can't see why the remote plugin should behave in a different way with vdr 1.3.31.
regards, Chris
-
Andreas Regel -
C.Y.M -
Carsten Koch -
Chris Ariyo -
Darren Salt -
Dominique Simon -
HGM.bg (GMX) -
Kimmo Vuorinen -
Klaus Schmidinger -
Lauri Tischler -
Luca Olivetti -
Marko Mäkelä -
Nicolas Huillard -
Oliver Endriss -
Reinhard Nissl -
Stefan Norberg -
Tony Houghton -
Udo Richter