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:
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:
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:
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:
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'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.
Luca Olivetti wrote:
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 ;-)
Klaus Schmidinger wrote:
--- 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:
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
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
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: ...
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.
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
On Wed, Aug 31, 2005 at 04:33:25PM +0300, Chris Ariyo wrote:
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
In 20050831140707.GC3149@localhost.localdomain, Marko Mäkelä wrote:
[Snip]
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.
Chris Ariyo wrote:
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