VDR developer version 1.3.30 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.39.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.29-30.diff
The changes since version 1.3.29:
- Improved responsiveness inside CAM menus. - Added handling of the 'Close MMI' tag to avoid error log messages with CAMs that actually use it. - Now waiting at startup until all DVB devices are ready. This includes having all CAMs initialized and ready to decrypt, so that no more "channel not available" happens if VDR is started with the current channel being an encrypted one, or a timer on such a channel hits right after starting VDR. - Fixed cVideoRepacker to better handle errors in data (thanks to Reinhard Nissl). - Fixed cDvbTuner to avoid lockups on NPTL systems (thanks to Marcel Wiesweg). - Added 'Service' functions to the plugin interface (thanks to Udo Richter). See PLUGINS.html, section "Custom services" for details. - Replaced the get/put_unaligned() macros from <asm/unaligned.h> with own inline functions to avoid problems on platforms that don't provide these (thanks to David Woodhouse for his help).
Originally I didn't intend to release a new version this weekend, but since there are two rather important fixes, here goes anyway...
Have fun!
Klaus
Klaus Schmidinger wrote:
- Added 'Service' functions to the plugin interface (thanks to Udo
Richter). See PLUGINS.html, section "Custom services" for details.
Back-ports of this feature to VDR 1.2.0 - 1.3.29 are available here:
http://urichter.cjb.net/vdr?h=customservices
Cheers,
Udo
Am Sun, 21 Aug 2005 16:43:23 +0200 schrieb Klaus Schmidinger Klaus.Schmidinger@cadsoft.de:
- Now waiting at startup until all DVB devices are ready. This includes
having all CAMs initialized and ready to decrypt, so that no more "channel not available" happens if VDR is started with the current channel being an encrypted one, or a timer on such a channel hits right after starting VDR.
Does this mean that vdr waits until the dvb-driver is ready (firmware loading finished) ?
To speed up the vdr start, i started the dvb driver separate from my runvdr. But when i started the dvb driver with & in Background, the driver is not ready when the vdr starts and i get no picture.
I would like that vdr waits for the dvb driver even if the driver started with & in Background.
Cheers, Christoph
Christoph Hermanns wrote:
Am Sun, 21 Aug 2005 16:43:23 +0200 schrieb Klaus Schmidinger Klaus.Schmidinger@cadsoft.de:
- Now waiting at startup until all DVB devices are ready. This
includes having all CAMs initialized and ready to decrypt, so that no more "channel not available" happens if VDR is started with the current channel being an encrypted one, or a timer on such a channel hits right after starting VDR.
Does this mean that vdr waits until the dvb-driver is ready (firmware loading finished) ?
No, it just means that VDR waits until devices with CAMs have completed setting up the communication with the CAM. Of course, the driver has to be fully loaded before VDR can access the devices.
To speed up the vdr start, i started the dvb driver separate from my runvdr. But when i started the dvb driver with & in Background, the driver is not ready when the vdr starts and i get no picture.
I would like that vdr waits for the dvb driver even if the driver started with & in Background.
I guess it's a matter of coincidence whether or not the driver will be completely up and running when VDR tries to access the devices. You should always wait until the driver is ready before starting VDR.
Klaus
On Mon, Aug 22, 2005 at 01:38:51PM +0200, Klaus Schmidinger wrote:
I guess it's a matter of coincidence whether or not the driver will be completely up and running when VDR tries to access the devices. You should always wait until the driver is ready before starting VDR.
On my gentoo I have this in the vdr init scripts :
until [ -e /dev/dvb/adapter0/frontend0 ] && [ -e /dev/dvb/adapter1/frontend0 ] && [ -e /dev/dvb/adapter2/frontend0 ]; do sleep 1 done
then vdr start :)
Gregoire Favre wrote:
On Mon, Aug 22, 2005 at 01:38:51PM +0200, Klaus Schmidinger wrote:
I guess it's a matter of coincidence whether or not the driver will be completely up and running when VDR tries to access the devices. You should always wait until the driver is ready before starting VDR.
On my gentoo I have this in the vdr init scripts :
until [ -e /dev/dvb/adapter0/frontend0 ] && [ -e /dev/dvb/adapter1/frontend0 ] && [ -e /dev/dvb/adapter2/frontend0 ]; do sleep 1 done
then vdr start :)
The main problem with udev is modprobe returns while udev keeps working asynchronously. Is "frontend0" the last device created? The last one is probably the one you want to check for.
Best Regards.
-
Anssi Hannula -
C.Y.M -
Christoph Hermanns -
Gregoire Favre -
Klaus Schmidinger -
Udo Richter