It is likely that the problem came into existence because Ubuntu has published a package update today containing a new DVB firmware file that is also in one of our firmware packages on the ISO image. Luckily, this is the first time since October 2012 that we got any reports about installation problems that were not related to problems on the user side.

We have created an updated ISO image yavdr64-0.5.0a.iso (based on Ubuntu 12.04.2)  that should fix the problem: Please find the image on our download page .

Thank you!

Finally here it comes, expected for a long time, tested by a lot of volunteers, crafted by unresting developers and contributors:

yaVDR 0.5.0

If you've followed this blog or the multiple discussions at the VDR portal you may be familiar with the various changes that have been integrated into this new release. We did our very best as time permits to make it as stable as it can. Despite all testing there're some known issues which coudn't be solved. But they aren't "bad enough" to keep us from releasing the current status.

While you are downloading the ISO-image please read the following so you don't get surprised by problems which may rise.

There are some new features and improvements in yaVDR 0.5, following is a short overview about the most important changes since yaVDR 0.4:

• Based on Ubuntu 12.04.1 64-bit with kernel 3.2.x (3.2.0-32 at the moment)
• The alternate-installer now offers the possibility to configure your wireless LAN (untested)
• LVM is not selected as default, instead the classic partitioning is used (you should adjust it, so a seperate /srv exists to make future updates easier)
• nVidia-driver 304.51
• new linux-media-dkms version
• As always the packages are originated from the yaVDR stable-PPAs
• The Upstart-scripts were heavily overworked, so take care before you blindly copy your old customizations into the new version.
• VDR version 1.7.27
• No more LiveBuffer-Patch (see [Wunschkonzert] Livebuffer-plugin )
• softhddevice is now the new default frontend (xine, xinelibputput/vdr-sxfe, PVR350 as well as TT S2-6400 and SD-FF from TT are also available, even XBMC can be chosen, but that's the most experimental of all)
• For softhddevice a new vdr-frontend.conf is introduced, which delays the attaching of the frontend if the vdr has started for a timer or through the acpiwakeup-addon until the user presses a key on the remote (or the enter key if no other window has the focus). This is needed because the attaching of the frontend triggers user activity and the vdr will use the user-inactivity timeout after the recording has finished and not the MinEventTimeout. With KEY_PROG1 you can detach the frontend again. If KEY_POWER2 is pressed the frontend will be detached after 15s, in case vdr runs at this moment and the user hasn't aborted the shutdown. The keys and some other options can be changed with a custom template at /etc/yavdr/templates_custom/etc/init/vdr-frontend.conf/03_config_softhddevice which overlays the original /usr/share/yavdr/templates/etc/init/vdr-frontend.conf/03_config_softhddevice.
• XBMC Eden PVR-Branch
• xbmc-addon-yavdrtools: coordinated shutdown management between XBMC and VDR, kind of useful if XBMC runs as the only frontend. Can be manually installed as needed (see [yaVDR 0.5-alpha1] Tester gesucht: yaVDR-Tools XBMC-Addon ).
• improved dbus2vdr-plugin (see dbus2vdr README )
• new features from the dynamite-plugin (see dynamite README )
• new version of the restfulapi-plugin
• Improvements at the configurations of remotes:
  • lircd2uinput binds all daemons with a lirc-socket (LIRC, ir-server) and can be manually configured for not included but functional daemons like activylirc or irmpserver.
  • Integration of the keymaps and evmaps for several remotes posted by diligent users at the bugtracker
  • udev-rule for home-brew (16x50 UART compatible serial port)-devices, to compensate changing lirc-device-numbers caused by some TV-drivers
  • support for yaUsbIR, just select it at the WFE (see yaUsbIr LIRC-fähiger USB IR Empfänger/Sender mit Einschalter )
  • included, pre-configured lircd.conf files for the KLS and MCE profile can be choosen easily for yaUsbIr and home-brew (16x50 UART compatible serial port)-devices at the WFE
  • standard-profile for CIR-receiver + MCE
  • support for the PS3 BD remote ( initial pairing is needed )
• automatic detection of Sundtek-DVB-cards in the network and installtion of the needed drivers during the yaVDR installation
• improved Avahi-Mounter for dynamic NFS-mounts between different yaVDR system (≥ 0.4) and servers with matching Avahi announcements of its shares
• If another yaVDR is running on the same network during the installation, its channels.conf will be copied and the streamdev-client plugin will be preconfigured in the setup.conf, which just has to be installed and activated afterwards.

Updated dokumentation:
http://www.yavdr.org/documentation/0.5/de/ (not complete yet)

Important:
This version is a "stable" intermediate result in the yaVDR development (like all previous stable-releases). There are some known problems with the automatic detection of soundcards and the first start of the vdr, which can raise with special hardware combinations.

This version uses the stable-PPAs. Users of yaVDR 0.5alpha1/beta can switch to it with changing the entries at /etc/apt/sources.list.d/yavdr.list from testing to stable and a following "sudo apt-get update && sudo apt-get dist-upgrade". An update from an earlier yaVDR-version is not possible.

Please consider the following rules, so we can benefit from your feedback (and so you will get a more "precise" yaVDR 0.5):

Rules:

• No error reporting in the announce-thread, but at the yaVDR forum with a [yaVDR 0.5] tag and a meaningful title, detailed error description, logs and a good solution of course. ;)
• you can post bugs at the yaVDR-Bugtracker - registration is needed, since we need feedback from the users when we have changed something)
• One thread per problem
• No more "Help, my XYZ doesn't work"-threads without noticeable knowledge of the thread originator or totally noob-problems, which have been discussed here at the forum - the search button has already been invented.
• No support for broken installations, mixtures with interfering PPAs, destroyed configuration files etc.

And as always: "Good Luck"

There is good news and bad news. Bad news first: On this blog, we have failed to inform you about all the exciting stuff that happened since the release of yaVDR 0.4 in October 2011. Shame on those of us who claim to be able to write regular blog postings in an adequate English... ;-) But now for the good news:

Without giving you any clue about the progress of our work on the next yaVDR version, we would like to announce the release of yavdr64-0.5.0-alpha1.iso today. The members of the yaVDR team are happy that the public can now join in with testing, improving and extending what we have been working on hard over the last eight months.

The name of the release gives it away: This is without any doubt an alpha release. It is not stable or polished or feature-complete. Brave testers or developers who fear no risks may download it via our download page and evaluate it. Inexperienced users should stick with our stable releases yaVDR 0.4 or yaVDR 0.3.2 until a stable release of yaVDR 0.5 is available.

The new features and improvements of yaVDR 0.5.0-alpha1 are:

Frontends

New default frontend softhddevice : vdr-plugin-softhddevice is a new approach of developer "Johns" (VDR portal user name) to offer a VDR frontend that supports both VDPAU and VA-API. We have chosen it to be the new standard VDR frontend of yaVDR 0.5. On the long run, this means that it may become easier to use the hardware decoding features of GPUs from Intel and AMD besides Nvidia GPUs. But there are strong indications that AMD / XvBa is the most problematic candidate to develop for. If you want to learn more about this new VDR frontend, please visit the following pages (most content is in German language):

• http://www.vdr-wiki.de/wiki/index.php/Softhddevice-plugin
• http://projects.vdr-developer.org/projects/plg-softhddevice
• http://www.vdr-portal.de/board17-developer/board21-vdr-plugins/109700-softhddevice-software-vdpau-va-api-cpu-decoder-und-ausgabe-plugin/

The other frontends that are part of yaVDR 0.4 (xine, xineliboutput/vdr-sxfe, PVR350, TT S2-6400 and SD-FF with TechnoTrend hardware) are still available and can be activated using the web frontend.

XBMC as a frontend is also available, but still seems to be the most experimental frontend of them all. The XBMC version that ships with alpha1 is based on the Eden PVR branch.

Changes in the foundation

yaVDR 0.5.0-alpha1 is based on Ubuntu 12.04 64 bit (Precise Pangolin) with Kernel 3.2.x (currently 3.2.0-24). As with our previous stable release, no 32 bit ISO image is planned. Also, no upgrade from yaVDR 0.4 (Natty Narwhal) to yaVDR 0.5 is possible. A fresh installation is required.

For the installation of yaVDR we continue to make use of the alternate installer of Ubuntu. There are some changes that should make the installation easier:

• WLAN configuration : yaVDR users now have the opportunity to set up a WLAN connection during the installation process (untested).

• Partitioning : Logical Volume Management (LVM) ist not the default setting any more regarding partitioning the hard drive. Instead, the classic way is offered. Two hints on partitioning:
  • The experience shows that users who have never used LVM before should not use it with yaVDR for the first time. It involves a learning curve and makes things more complicated.
  • The folder /srv should be assigned to an own big partition to store the recordings separately from the system. This makes upgrades much easier.

The upstart scripts were refactored to a great extend. User-mods of yaVDR 0.4 may not work any more with yaVDR 0.5. Please check first how the upstart scripts have changed before pasting any modications into them.

The Launchpad package repositories used by this alpha version are testing-vdr, testing-yavdr, testing-xmbc and main. Whenever a final stable release of yaVDR 0.5 will be available, the repositories will then become the ones with "stable" in  their name.

Updated VDR core

The first alpha of yaVDR 0.5 ships with VDR developer version 1.7.27 .

Device bonding (also known as LNB sharing), satellite channel routing (also known as SCR, Unicable, EN50494) are now part of the VDR core. With yaVDR 0.4, those features were only incorporated into VDR core using 3rd party patches. The consequence is that the new configuration file scr.conf succeeds the now obsolete configuration file unicable.conf that was introduced in yaVDR 0.4.

Livebuffer support was dropped: We have decided to drop the support for the livebuffer patch that was introduced in yaVDR 0.4 because maintaining it involves an extraorbitant amount of work. The patch for the VDR core has to be refactored for each and every new VDR developer version. At the same time it is unclear what features the users really expect from a Livebuffer. Please check this German language discussion if you are interested to learn more about it: http://www.vdr-portal.de/board16-video-disk-recorder/board55-vdr-plugins/111788-wunschkonzert-livebuffer-plugin/

Fresh DVB drivers

If the DVB drivers shipped with kernel 3.2 don't contain the drivers you need, you may want to use our updated linux-media-dkms package: This package backports the latest development improvements regarding DVB drivers to be used with kernel 3.2. Driver packages known from earlier yaVDR versions (v4l-dvb-dkms, s2l-liplianin-dkms) are discontinued and now obsolete.

VDR plugin updates

• Improved plugin vdr-plugin-dbus2vdr: Please check https://github.com/yavdr/vdr-plugin-dbus2vdr/blob/master/README for further information.
• New features within vdr-plugin-dynamite: Please check https://github.com/yavdr/vdr-plugin-dynamite/blob/master/README for further information.
• New version of vdr-plugin-restfulapi
• ...

Improved support for remote controls and receivers

• lircd2uinput binds all daemons with lirc socket (LIRC, ir-server). It may also be manually configured for daemons like activylirc or irmpserver (those daemons are not shipped with yaVDR but are reported to work with it)
• eventlircd: Integration of new keymaps and evmaps for various remote controls. A big thank you to all users of yaVDR who created those configuration files and sent them to us!
• udev rule for Home-brew devices (16x50 UART compatible serial port) to compensate for the change of  LIRC device IDs caused by some drivers
• Support for yaUsbIr which can be easily enabled in the Web frontend. yaUsbIr is a new LIRC-enabled USB IR receiver/sender that supports to power up an HTPC. For more information on this receiver, please read this German language discussion .
• alpha1 ships with pre-configured lircd.conf configuration files for the profiles KLS and MCE. Those files can be easily selected via the yaVDR Web frontend to be used with a yaUsbIr or Home-brow receiver (16x50 UART compatible serial port)
• alpha1 ships with a standard profile for CIR-receivers + MCE
• Support for the Playstation3 PS3 BD Remote added. Initial pairing via terminal is necessary: See http://www.yavdr.org/documentation/0.5/de/ch02s03.html for further details.

New features regarding Zeroconf and Avahi in the Local Area Network

• Sundtek DVB device detection added: Sundtek DVB devices that are available on the local area network on a different machine are detected automatically. Sundtek drivers are installed automatically on device detection.
• Improved Avahi-Mounter for dynamic zeroconf mounting of NFS shares. Works with all yaVDR versions as of yaVDR 0.4. Other servers/NAS devices can also be included in this scenareo if their shares are announced via Avahi in the same way.

Updated documentation

Updated German language documentation: www.yavdr.org/documentation/0.5/de/ (still a bit incomplete)

How to report a bug

Please post bug reports on our bugtracker: https://bugs.yavdr.com/ . Thank you!

Have fun with yaVDR64-0.5.0-alpha1!

We are proud to announce yaVDR 0.4 after 12 months of hard work and two pre-releases.

Some basic facts about yaVDR 0.4 have been around for a while and are discussed in detail in some of our previous blog postings. A short summary should be sufficient:

• yaVDR 0.4 is based on Ubuntu 11.04 (Natty Narwhal).
• The ISO image is only available in 64bit flavour. However, our packages are also available as 32bit versions within our Launchpad repositories.
• If you want to upgrade from an earlier yaVDR release to yaVDR 0.4 you will need to do a complete reinstall from scratch. You have to migrate your settings manually. This is often easier than it sounds.
• You can download the yaVDR 0.4 ISO image from our downloads page.

But these were just the boring basics. Let's have a look at all the interesting details...

One of the new features causing the most confusion for VDR veterans should be discussed first:

Zero-Conf for remote controls / receivers via eventlircd

The eventlircd daemon (which is being developed by Paul Bender for the MiniMyth distro ) offers a modern approach to handle IR receivers and remote controls. With eventlircd it is for example possible to plug-in an USB infrared receiver into your HTPC at any time and instantly use the matching remote control. This goes without the need to restart either LIRC, VDR or the VDR-Frontend. If there is a configuration for the specific IR receiver available in our package yavdr-remote , it just works. In theory, you can also add more than one USB receiver and use two or more remote controls at the same time (please decide yourself how useful this is in real life).

eventlircd enables us to offer Zero-Conf in the area of remote controls whenever the receivers are detectable via udev: This applies to all USB receivers. Only receivers connected to the serial port are not detectable and in those cases LIRC can still be enabled in the yaVDR web frontend in addition to eventlircd (that is always running anyway).

The new approach means changing an old habit: It is not necessary and not recommended any more to change VDRs mapping file remote.conf! Instead, other files have to be changed. This is documented in the eventlircd chapter of seahawks brand-new and very nice yaVDR documentation (that is currently only available in German language yet).

Updated VDR core and new VDR plugins

yaVDR ships with the currently latest VDR developer version 1.7.21 and includes patches to enable some additional features like Livebuffer and Unicable support (also known as Satellite Channel Routing (SCR) or Single cable distribution : SCR will most likely be implemented in one of the next VDR developer versions by Klaus Schmidinger). It also includes a couple of new VDR plugins that were developed by our team members.

Introducing the dynamite plugin (aka vdr-plugin-dynamite)

Dynamite makes it possible to add or remove DVB devices while VDR core is running. Before unplugging a device, it has to be detached in the plugins settings via the VDR OSD. Dynamite can be very convenient in different ways:

• During boot time: If one of your DVB devices is slower than others and gets initialized later than the rest, the start of VDR core doesn't have to be delayed until all DVB devices are present. Instead, VDR core is started at the earliest possible time and the DVB devices may turn up a little later if they like. Once a DVB device is initialized, it will automatically be added to the list of usable devices. Before we had Dynamite in the days of yaVDR 0.3, we used a tool called dvbmon to delay the start of VDR core until all expected DVB devices were initialized. This tool is now obsolete.
• During runtime: Let's say you have a couple of USB DVB devices. In case you want to record more TV shows than usual in parallel, you can plug-in an additional USB DVB device to increase the number of concurrently recordable transponders. In the opposite way, you can configure a DVB device that is not needed to be "detached" and use it with a different HTPC without stopping VDR (these scenarios might be more likely in a developer or tester environment where you have more than one HTPC in one room). Even if devices are still physically connected to the system they were "detached" from, they are no longer used by VDR until they are (manually or by udev) re-attached.
• In scenarios where the DVB devices are in a different room from the HTPC running yaVDR: You have a DVB device in room A with network streaming capability (for example a Sundtek stick connected to a broadband router running Linux or a HDHomeRun device). In theory, it is now possible to add those devices to a running yaVDR HTPC in room B as soon as they are being switched on / made available. (For Sundtek devices, this is already being done using Avahi.)
• Power saving: It is possible to automatically set unused devices to an "idle" mode after a (configurable) timeout. This means, that the underlying cDvbDevice class of VDR closes all open handles so the driver can shutdown the device or initiate power saving mechanisms. If the user switches to a channel (or a recording starts) for which the device is needed it will be reactivated automatically by VDR.

Talking to the VDR via dbus plugins - An alternative to SVDRP

Two new VDR plugins developed by yaVDR team members ( vdr-plugin-dbus2vdr , vdr-plugin-dbus ) allow the communication with VDR without using the old and limited way of SVDRP - and more.

What else is new? Zero-Conf wherever possible...

One of our development goals for yaVDR 0.4 was: Introduce Zero-Conf (meaning automated configuration) where it makes sense. 

• Automated sound settings configuration: Promised sound on first boot. All sound outputs should have sound (analog, S/PDIF, HDMI)
• Automatic detection of DVB-hardware on installation. When starting the yaVDR installation, it is no longer necessary to decide which driver package to install. It is done automatically in case your DVB hardware is in the list of devices we have created. Just make sure your device is connected during installation.
• The Avahi Mounter organizes zero-conf media shares in the local area network based on NFS: With yaVDR 0.4, Avahi Mounter is installed by default. If you have more than one VDR, the recordings of each VDR will be accessible on the other VDR. Avahi Mounter will automatically mount NFS shares from a machine that was just booted up and it will also automatically unmount NFS shares from machines that were told to shut down. More information on this topic can be found in this blog posting and this tutorial .

Updated DVB driver packages

s2-liplianin-dkms and v4l-dvb-dkms are still available as alternatives to the standard v4l-dvb modules shipped with the Linux kernel provided by Ubuntu Natty.

Experimental support for FullFeatured DVB cards

This also includes the brand new TechnoTrend Premium S2-6400 Twin DVB-S2. Big limitation: GPU rendered applications like XBMC or Firefox (basically everything that runs on top of Xorg) is inaccessible when running yaVDR with a FullFeatured frontend. This is how far we can and want to support FullFeatured DVB devices that represent a completely different approach to our GPU based VDPAU "philosophy".

What's new in yaVDRs web frontend?

yaVDR 0.4 ships with a completely redesigned, friendlier web frontend with more useful settings to play with, including a comfortable channel list editor with an online connection to our new yaVDR Channelpedia service. The web frontend includes a couple of new features like a Wake On LAN (WOL) client that makes it possible to start other PCs in the local network using the VDR OSD and your remote control.

New boot and shutdown animations, new default OSD theme

It also includes a newly designed plymouth-based boot animation and shutdown animation. The default OSD theme is set to the theme "NarrowHD".

Behind the scenes

We reorganized our daily project work in different ways to become quicker and more efficient and have more fun:

• End of over-templating: In yaVDR 0.3, we used the yaVDR templating system for a vast number of configuration files. This has been reduced to a necessary minimum. All configuration files that we need to change once and never again are now part of package yavdr-base.
• New package structure of yaVDR packages (before, we only had yavdr-essential, yavdr-starup and yavdr-utils. Now, we have many more packages that represent the backbone of the distribution.)
• Refactored upstart scripts.
• yaVDR's own sourcecode was moved from SVN (origo) to GitHub ( https://github.com/yavdr )
• Additionaly, our improved buildscripts help us to quickly upload new source packages to Launchpad - suddenly we have the feeling that it would be - in theory - possible to provide packages for each new Ubuntu release. The six month release cycle of Ubuntu is always always seem to cause productive stress within our team. Last year, we skipped Ubuntu Maverick due to the workload. Now, we are already looking forward to move to a predecessor of Natty.
• vdr-plugin-restfulapi opens the door to new attractive state-of-the-art HTML5 web applications. This plugin will be covered in an own blog posting at some point in the future.

Countless other things

A high number of updated packages including XBMC, VDR plugins, Nvidia driver, etc.

Where we are not completely satisfied

There is always something that is not perfect. Let's just name it and get it out of the way:

• XBMC PVR development status: Since we have released yaVDR 0.1 in early 2010, we always made sure to advertise that XBMC is part of our distribution. And that we ship an experimental PVR enabled version. But we always shipped an experimental and unstable version. We also started to offer the setting "XBMC as a TV frontend" in the yaVDR web frontend. But we are still far away from a stable PVR enabled XBMC version in yaVDR. This is nobody's fault - it is just the way how software development works. One day, there will be a nice stable XBMC with PVR features.

• Boot-up duration: Boot times are still very good but not as good as with yaVDR 0.3. With dynamite there should be nothing in the way for a quick boot, but Ubuntu Natty seems to boot slower than its predecessors or successors. This motivates us to move on and experiment with the successors.

Please download the ISO yavdr64-0.4.0-pre2.iso from our download page .

What has changed since pre1?

• Now ships with VDR developer version 1.7.21 (pre1 was shipping with 1.7.18)
• New XBMC version (now based on pipelkas code) including a switch from vdr-plugin-vnsi to vdr-plugin-xvdr. In XBMC, the PVR addon necessary is now called xvdr. XBMC + PVR is still a huge construction site and for now we are switching to packages built from the code within the Git repositories of pipelka (being aware of the controverse opinions regarding vnsi/xvdr): https://github.com/pipelka/xbmc-addon-xvdr and https://github.com/pipelka/xbmc
• Improved detection of necessary DVB drivers for DVB hardware present in system during installation.
• More remote controls work out-of-the-box (thanks to eventlircd and the configuration files we provide) as soon as the USB receiver is connected to the HTPC (hotplug possible).
• Incompatible change to pre1 regarding remote control setup in Web Frontend: eventlircd is now always enabled, LIRC may be enabled in addition if a remote control / receiver is used that belongs to the list of undetectable receiver devices (mainly receivers connected to the serial port)
• Many updated packages

People updating from pre1 to pre2 via apt-get upgrade / dist-upgrade may experience some problems (XBMC, remote configuration). If you want to seriously help the yaVDR team, please install pre2 from scratch.

Due to a downtime of VDR Portal, we invite you to join our own improvised support forum.

Update: VDR Portal is online again.

The website of VDR Portal ( http://www.vdr-portal.de ) has had an unexpected downtime for nearly the last 24 hours (and still ongoing). We hope that there are no serious problems and that the administrators of VDR Portal don't have too much trouble with getting the forum up and running again. These are the moments where one realizes how important VDR Portal is for our work. Thanks to all the people behind VDR portal for their good work! :)

Because we don't have any information about how quickly the forum will be back online again, we habe decided to divert you to a temporary support forum for yaVDR users so that they don't feel lost in cyberspace. Once the VDR portal is up and running again we will close the temporary support forum and keep it for any other emergencies.

You can find the forum here: http://forum.yavdr.com

This is an improvised solution. Anyways: Have fun!

P.S.: Déjà vu? Yes: Nearly the whole text above was copied from a 2010 yaVDR blog posting. It has been used previously on this blog when VDR Portal was down in 2010... ;-)

Two days ago, Klaus Schmidinger has announced the release of VDR developer version 1.7.21. As always, we are excited about the new version and want to thank Klaus for his steady work on VDR core.

The yaVDR team has already started to use the new developer version to create updated experimental VDR packages in our PPA unstable-vdr . Packages for Ubuntu Lucid (yaVDR 0.3) and Ubuntu Natty (yaVDR 0.4) are now available, but most of them are untested. It is possible that we will update our PPA testing-vdr with the predecessor version: Our VDR 1.7.20 packages that are only a couple of days old now need a new home.

Let's have a look at the changes in VDR 1.7.21.

Klaus describes the changes since VDR 1.7.20 as follows:

• Fixed detecting frames for channels that split frames into several payloads (reported by Derek Kelly).
• Now initializing Setup.InitialChannel to an empty string to avoid problems in case there is no setup.conf .
• The start time of an edited recording is now set to the time of the first editing mark (thanks to Udo Richter). This obsoletes the CUTTIME patch.
• Direct access to the members start, priority, lifetime, and deleted of cRecording as well as to position and comment of cMark is now deprecated. Plugin authors should switch to the new access functions for these members. For now the macro __RECORDING_H_DEPRECATED_DIRECT_MEMBER_ACCESS is defined in recording.h , which exposes these members, so that existing plugins will still compile. Comment out this #define to check whether a particular plugin needs to be modified. This #define may be removed in a future version.
• The new functions cRecording::NumFrames() and cRecording::LengthInSeconds() return the number of frames and length (in seconds) of a recording (suggested by Steffen Barszus).
• The subtitle PIDs are now stored in the channels.conf file as an extension to the TPID field (thanks to Rolf Ahrenberg).
• The new function cDevice::ProvidesEIT() is used to determine whether a device can provide EIT data and will thus be used in cEITScanner::Process() to receive EIT data from the channels it can receive (suggested by Rolf Ahrenberg). Note that by default it is assumed that a device can't provide EIT data, and only the builtin cDvbDevice returns true from this function.
• The Audio and Subtitles options are now available through the Green and Yellow keys in the Setup/DVB menu (thanks to Rolf Ahrenberg). This is mainly for remote controls that don't have dedicated keys for these functions.
• The SVDRP command HITK now accepts multiple keys (up to 31).
• The Recordings menu now displays the length (in hours:minutes) of each recording (thanks to Rolf Ahrenberg). Note that the "new" indicator has been moved from the recording time to the length column. This new format is also used by the SVDRP command LSTR , so in case you have an application that parses the LSTR output, you will need to adjust it to the new format.
• The dvbsddevice plugin now supports the new option --outputonly , which disables receiving on SD FF devices and uses the device only for output (thanks to Udo Richter).
• Fixed detecting frames on radio channels (reported by Chris Mayo).
• Revoked the changes to cFrameDetector that have been introduced in version 1.7.19. Detecting frames in case the Picture Start Code or Access Unit Delimiter extends over TS packet boundaries is now done by locally skipping TS packets in cFrameDetector .

An overview of earlier VDR developer versions of the 1.7 branch can be found here .

How much fun do you normally have while re-sorting your channel list? Digital TV providers offer their customers hundreds of TV channels and radio stations. At some point almost every person who receives digitial TV has to fiddle with re-sorting some of these channels. This can cause major frustration because the on-screen menus of Set Top Boxes or TVs with built-in receivers often seem to be designed without the urge to win usability awards. Have you ever tried to move a channel from position 2847 to position 7 using the remote control? And after that, to move another channel from position 2846 to position 8? It's as much fun as playing Tetris while the blocks are only dropping by one line per minute.

Even within the open source PVR world it's a challenge to offer a solution with decent usability. But this is going to change soon: Upcoming yaVDR 0.4 will assist you with your channel list in quite a clever way. Let's have a look at the all new channel list editor in the yaVDR web frontend and its built-in access to Channelpedia, the new VDR channel list directory.

While the new channel editor will help you to sort and group your channels quickly and efficiently (it even includes drag and drop and a clipboard), Channelpedia tries to save you from the need to find or create an initial channel list for your DVB provider. Prior to Channelpedia, you had to do a manual channel scan of your DVB provider by using

• either w_scan on the command line
• or vdr-plugin-wirbelscan via the On-Screen Display of VDR.
• Or you had to search for a current VDR channel list on the web.

Any of these ways would take you up to 30 minutes.

Channelpedia now tries to offer you up-to-date channel lists that are also pre-sorted by a set of pre-defined rules to make it easier for you to find the channels you are looking for. Channelpedia is a web application written in PHP and can be extended by new DVB providers. The quality of the Channelpedia service relies on different VDR users who volunteer to let their own channel list being uploaded to Channelpedia on a regular basis.

If you are interested to see a demo about the channel editor and the Channelpedia access, please have a look at the following video. You might want to increase the quality setting to HD and put the video to Fullscreen mode to make it easier to read the text within the video.

You can try all of this already at home by testing the current alpha version of yaVDR 0.4 that is available for download from this website.

If you want to learn more about Channelpedia, please check the following links:

• Channelpedia website: http://channelpedia.yavdr.com/
• Channelpedia project management / bugtracker: https://bugs.yavdr.com/projects/channelpedia
• Channelpedia sourcecode at GitHub: https://github.com/yavdr/channelpedia/

Have fun!

A week ago, Klaus Schmidinger has announced the release of VDR developer version 1.7.20. As always, we are excited about the new version and want to thank Klaus for his steady work on VDR core.

VDR 1.7.20 will replace the VDR 1.7.18 packages in yaVDR in the near future.

Because there were known problems with VDR 1.7.19 the yaVDR team has skipped packaging that version. With 1.7.20 being out and fixing those issues, we are currently working on new packages of VDR core and all VDR plugins for Ubuntu 11.04 (Natty Narwhal / yaVDR 0.4.0-pre1) and also for Ubuntu 10.04 (Lucid Lynx, yaVDR 0.3). Those packages are highly experimental at the moment. Therefore they are part of our unstable-vdr PPA. As soon as we think they are ready to be tested by a broader audience, we will copy them over to the PPA testing-vdr and replace the 1.7.18 packages in there. This will make 1.7.20 available as a regular package update for testers of yaVDR64-0.4.0-pre1. We have not decided yet if or when the Lucid packages will hit our stable-vdr PPA (being the PPA yaVDR 0.3 pulls the VDR package updates from).

But first, let's have a close look at the new stuff included in VDR 1.7.20. Klaus describes the changes since VDR 1.7.19 as follows:

• Added some missing ' const ' to tChannelID (reported by Sundararaj Reel).
• The isnumber() function now checks the given pointer for NULL (thanks to Holger Dengler).
• Now checking Setup.InitialChannel for NULL before using it (reported by Christoph Haubrich).
• cSkins::Message() now blocks calls from background threads (thanks to Michael Eiler for reporting a crash in such a scenario).
• Fixed the return value of the svdrpsend.pl script in case of an error (thanks to Jonas Diemer).
• Increased MAXCAIDS to 12 (thanks to Jerome Lacarriere).
• Fixed handling DiSEqC codes (thanks to Mark Hawes for reporting the bug, and Udo Richter for suggesting the fix).
• Added a mechanism to defer timer handling in case of problems (reported by Frank Niederwipper).
• Fixed distortions that happened when splitting recording into several files (was a side effect of "Fixed detecting frames in case the Picture Start Code or Access Unit Delimiter extends over TS packet boundaries" in version 1.7.19). cRecorder::Action() now buffers TS packets in case the frame type is not yet known when a new payload starts. This adds no overhead for channels that broadcast the frame type within the first TS packet of a payload; it only kicks in if that information is not in the first TS packet.
• Fixed handling the channelID in cMenuEditChanItem (thanks to Udo Richter).
• cStringList::Sort() can now be called with a boolean parameter that controls case insensitive sorting (suggested by Sundararaj Reel).
• Now scanning new transponders before old ones, to make sure transponder changes are recognized (thanks to Reinhard Nissl).
• Implemented static cIndexFile::IndexFileName() .
• The length (as number of frames) of a recording's index file can now be determined by a call to cIndexFile::GetLength() (suggested by Christoph Haubrich).
• Fixed some crashes in subtitle display (thanks to Rolf Ahrenberg).
• Made DELETENULL() thread safe (reported by Rolf Ahrenberg).
• The pic2mpg script of the 'pictures' plugin now generates HD images (thanks to Andre Weidemann for his support in using convert/ffmpeg). The old SD version is still available as pic2mpg-sd .
• Added a mutex to protect cOsd::Osds from simultaneous access from different threads (reported by Rolf Ahrenberg).
• The cutter now sets the 'broken link' flag for MPEG2 TS recordings (thanks to Oliver Endriss).
• Fixed language code entry for Portuguese.
• The new command line options --filesize (suggested by Marco Göbenich) and --split can be used together with --edit to set the maximum video file size and turn on splitting edited files at the editing marks. These options must be given before --edit to have an effect.
• cTimeMs is no longer initialized to the current time if the value given to the constructor is negative (avoids the "cTimeMs: using monotonic clock..." log message before VDR's starting log message).

An overview of earlier VDR developer versions of the 1.7 branch can be found here .

This is not a stable or polished or feature-complete release. Brave testers or developers who fear no risks may download it via our download page and test it. Inexperienced users should stick with yaVDR 0.3 until the stable release of yaVDR 0.4 is out.

We already tried to answer some basic questions regarding what will be new in yaVDR 0.4 within the blog posting It's time to talk about yaVDR 0.4 . Please read this posting first if you haven't done so yet. Especially if you haven't heard yet about our switch-over to 64 bit.

Testers, please file any bug reports at https://bugs.yavdr.com/projects in English language (yes, it's that dodgy site with a SSL certificate that makes the browser complain). Please check the already existing bug reports before you create duplicates.

Of course, a lot of questions remain open at this stage. We will try to answer them as our time permits and hopfully get around to create a "Known Issues" document. If you can't wait, please consider to post questions regarding the new features and concepts at VDR Portal.

Some basic information regarding this release

• All (pre-)releases of yaVDR 0.4 are based on Ubuntu 11.04 (Natty Narwhal) 64 bit. The ISO image is called yavdr 64 -0.4.0-pre1.iso to indicate that.
• Installation: As always, this is not a Live CD . As always, the text based alternative installer of Ubuntu is being re-used by yaVDR. You can also install any yaVDR release in a virtual machine for testing purposes.
• Upgrade: There is no way to upgrade from yaVDR 0.3 to a (pre-) release of yaVDR 0.4. But it should be possible to update from one yaVDR 0.4 pre-release to the next (by doing apt-get update / apt-get dist-upgrade) and from a pre-release to the final version of yaVDR 0.4. If not, we will inform you.
• Underlying package repositories (Launchpad PPAs): yavdr64-0.4.0-pre1.iso contains Natty packages from those PPAs having testing in their name (testing-vdr, testing-yavdr, testing-xbmc) and also from the new PPA called main . Package updates will also be pulled from these PPAs (and of course as always from Ubuntu's official standard repos). All further pre-releases will also use the testing PPAs. But a future final release of yaVDR 0.4 will then use the stable PPAs instead of the testing PPAs. As always, packages containing our latest development changes (that may contain big problems!) are being built and tested in our unstable PPAs, separated from the testing and stable PPAs. We can copy packages from any of our PPAs to another. The order will always be: From unstable to testing, from testing to stable.
• to be continued

Known Issues

• Issues with keyboard layout selection in Ubuntu alternative installer: https://bugs.yavdr.com/issues/402 , https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/656777
• Current development versions of PVR-enabled XBMC branches don't allow to install any XBMC addons any more. A workaround that we decided not to introduce to our packages is explained here .

If you understand some German: There is a German language announce thread regarding this pre1-release on VDR Portal. We will take care that all important information will also be made available in English.

Have fun!

Klaus Schmidinger has announced the release of VDR developer version 1.7.19 yesterday. As always, we are excited about the new version and want to thank Klaus for his steady work on VDR core.

Klaus describes the new stuff in 1.7.19 as follows:

This version introduces functions to determine the "signal strength" and "signal quality" through cDevice . If you are using a DVB card that contains an stb0899 frontend chip (like the TT-budget S2-3200) you may want to apply the patches from  ftp://ftp.tvdr.de/vdr/Developer/Driver-Patches  to the LinuxDVB driver source in order to receive useful results from that frontend.

Since apparently the various frontend drivers return different maximum values in their FE_READ_SIGNAL_STRENGTH and FE_READ_SNR functions (some deliver a value in the range 0x0000...0xFFFF, while others return values as "dB/10" or "dBm/10" - the latter with an offset to make the value positive, since the parameter is unsigned), the functions cDvbTuner::GetSignalStrength() and cDvbTuner::GetSignalQuality() use the device's "subsystem ID" to map these values into the range 0...100, which is the normalized return value of these functions.

Take a look at these two functions and maybe remove the comment characters from the lines

//#define DEBUG_SIGNALSTRENGTH
//#define DEBUG_SIGNALQUALITY

in dvbdevice.c to get some debug output if your device doesn't return any directly useful values and may have to be added appropriately to the 'switch (subsystemId)' statement.

The channel display of the 'sttng' skin uses these values to implement a signal strength/quality display.
 
The changes since version 1.7.18:

• Fixed cString's operator=(const char *String) in case the given string is the same as the existing one (thanks to Dirk Leber).
• Avoiding a gcc 4.6 compiler error in the skincurses plugin (thanks to Tobias Grimm).
• TsGetPayload() now checks if there actually is a payload in the given TS packet (reported by Dirk Leber).
• Now sorting the source file names in the call to xgettext , to make sure the results are not dependent on the sequence of the files. Plugin authors may want to change the line containing the xgettext call in their Makefile accordingly by changing "$^" to "`ls $^`" .
• The primary device is now only avoided for recording if it is an old SD full featured card. This is done through the new function cDevice::AvoidRecording() .
• Subtitle PIDs are now also decrypted (thanks to Reinhard Nissl).
• Fixed a possible race condition in cDiseqc::Execute() (reported by Marco Göbenich). The return value of cDiseqcs::Get() is now const , so plugin authors may need to adjust their code if they use this function.
• The new functions cDevice::SignalStrength() and cDevice::SignalQuality() can be used to determine the signal strength and quality of a given device (thanks to Rolf Ahrenberg for some input on how to use BER and UNC values to generate a "quality" value).
• The 'sttng' skin now displays two colored bars at the bottom of the channel display, indicating the strength (upper bar) and quality (lower bar) of the received signal. The number to the left of these bars indicates the actual device the current channel is being received with.
• Fixed detecting frames in case the Picture Start Code or Access Unit Delimiter extends over TS packet boundaries (reported by Johan Andersson). In order to fix this, the semantics of cFrameDetector had to be changed a little. See cRecorder::Action() and cIndexFileGenerator::Action() on how to use the new cFrameDetector::NewPayload() function.
• The frame detector now only starts collecting PTS values after it has seen the first I-frame, otherwise it might get MaxPtsValues values and stop analyzing even though the incoming data is still garbage (reported by Derek Kelly).
• The info file of a recording is now only overwritten with a new fps value if that new value is not the default value (thanks to Derek Kelly for reporting a problem with the fps value being overwritten in case a recording was interrupted and resumed, and the fps value could not be determined after resuming recording).
• The initial channel is now stored by the channel ID in the setup.conf file, in order to avoid problems in case channels are reordered or deleted (reported by Lars Bläser).
• Added support for "content identifier descriptor" and "default authority descriptor" to 'libsi' (thanks to Dave Pickles).

Warning: In a follow-up posting, Klaus has described a known issue of this VDR developer version that was found shortly after the release:

"I'm afraid this change causes a short distortion in video and audio when VDR switches from one .ts file to the next during replay. I have yet to investigate and fix this, just wanted to warn people who make important recordings with this new version - which, of course, nobody should do, since it is a developer version ;-)"

yaVDR 0.4 is slowly taking shape: We would like to give you an overview about all important changes and new features that we plan to put into yaVDR 0.4. This will happen in a series of blog postings, starting off today with focus on the cornerstones of yaVDR 0.4.

To make it more exciting to read, I'm pretending that somebody is conducting an interview with the yaVDR developers. (There should be an open source software that automatically comes up with the right interview questions to make it easier to write such stuff.)

Q: yaVDR 0.3 has been released in the second half of October 2010 and yaVDR 0.4 seems to be in reach. What have you been working on over the last six months?

A: This is not easy to summarize. For yaVDR 0.4 we have made more than one thousand changes to our source code repository (only SVN, not counting the commits that only went to our new git repositories). And this is only the source code of the yavdr-distro-packages that care for booting up, providing the web-frontend and the templating engine and such. It doesn't include the work done on packaging new versions of VDR core and plugins.

Q: What were your goals for yaVDR 0.4?

A: Our goals for yaVDR 0.4 were: Simplifying configuration, less hassle with manual configuration. More stability. Up-to-date Ubuntu base.

Q: Can you try to summarize the new features of upcoming yaVDR 0.4 in one sentence?

A: Well, we will try to do that, but only because we know that we will discuss the features in detail within upcoming blog postings.

The new features of yaVDR 0.4 will most likely be:

• A completely redesigned, friendlier yaVDR web-frontend with more useful settings to play with, including a comfortable channel list editor with an online connection to our new yaVDR Channelpedia service (an online database for different channel lists),
• A modern approach to handle remote controls via eventlircd (some remote controls should even work out-of-the-box),
• Simplified sound configuration (we promise sound after first boot),
• DVB-Device Hotplugging and unplugging without the need to restart VDR core,
• An alternative way to communicate with VDR to overcome the limitations of SVDRP,
• An updated VDR core (1.7.18) and updated VDR plugins, VDR addons and yaVDR addons plus updated DVB-driver-branches,
• Experimental support for FullFeatured DVB cards including the brand new TechnoTrend Premium S2-6400 Twin DVB-S2.
• Updated PVR-enabled XBMC version
• ...

Not everything might make it into the stable version of yaVDR 0.4, but this is basically what we have been working on and what we are currently still fiddling with.

Q: Will yaVDR 0.4 still be based on Ubuntu Linux? If so, on what version?

A: Yes, all yaVDR versions ever released have been based on Ubuntu Linux. There are no plans to change that. yaVDR 0.4 will be based on the currently latest Ubuntu release 11.04 (Natty Narwhal) with Linux kernel 2.6.38. The release notes of Natty can be found within the Ubuntu wiki: https://wiki.ubuntu.com/NattyNarwhal/ReleaseNotes

Q: Will you still offer VDR in form of Ubuntu packages on Launchpad.net?

A: Yes. Natty packages (32bit and 64bit) will be available on Launchpad too. At the point where we decide to publish yaVDR 0.4 as a stable release, the Natty VDR packages will turn up in our stable PPAs (stable-vdr, stable-xbmc, ...). The existing packages for Ubuntu Lucid Lynx will also stay there next to the Natty packages.

Q: Until now, you have offered yaVDR ISO images only for the 32bit platform although you always offered 64bit packages within your PPAs. Is this going to change?

A: Yes, this is going to change with yaVDR 0.4: We will switch over to the 64bit platform. That means we will release a 64bit ISO image. At the same time we will stop to offer a 32bit ISO image. There aren't any reasons any more to stick to 32bit in 2011. The hardware that people are recommended to use with yaVDR is ready for 64bit. Looking at the VDR Livebuffer patch that we are trying to integrate in yaVDR 0.4, there is a first serious use case for more than 4 GB of RAM in a HTPC. A 64bit kernel offers access to the full memory and makes switching over to a PAE kernel unnecessary. A PAE kernel also only offers a maximum of 4 GB per process.

Q: Why don't you offer ISO images for both platforms instead of just for the 64bit platform?

A: One important reason for the fact that we only offered one ISO image per release are our own time limitations: Offering two ISO images increases the amount of testing, bugfixing and support for us exponentially. The developers of the yaVDR team invest an substantial amount of their spare time in this project, but there are limits: We have to sleep, we have to work and we need to have time to spend with our families. That's why we have decided to keep it that way: For yaVDR 0.4, there will only be one ISO image - but from now on based on the 64bit platform. Users that are forced to stick to a 32bit Linux due to ancient hardware are welcome to install our packages manually on their 32bit Ubuntu installation.

Q: How do you decide which Ubuntu versions to use for new yaVDR versions? Do you throw a dice?

A: Well, the release rhythm of Ubuntu is twice a year. Although we seem to put out yaVDR releases more than once a year, we don't synchronize our release dates with the Ubuntu release dates. Our development team is too small for organizing this kind of thing and too focussed on solving PVR related issues that are more important for us and our users. For yaVDR 0.2 we choose Ubuntu 10.04 Lucid Lynx (LTS) and we stayed with that version for yaVDR 0.3. The reasons we tried to explain in our blog posting "Is Maverick our cup of tea?". Because of this decision we "skipped" Ubuntu 10.10 and we didn't even offer packages for Ubuntu 10.10 in our PPAs.

But from our perspective it makes sense now to move on and use the latest Ubuntu release to benefit from more current versions of essential software packages that are important for a Linux PVR. For example, a new Linux kernel version usually offers improved DVB driver support, a new ALSA version will save users with certain modern soundchips a lot of hassle (no need to rely on backports), also a new upstart version allows us to make use of new upstart features.

Q: Is there a relation between the yaVDR release numbers used and Ubuntu release numbers?

A: Well, not really. Our users simply have to look at this table to see what is going on:

Q: If the yaVDR developer team is too small to follow the Ubuntu release cycle: Why don't you just extend the team?

A: The yaVDR team has already grown since we started founding the team in autumn 2009. Gerald, the founder of yaVDR has recruted 5 other team members in late 2009 (the two Holgers, Steffen, Henning, Arno) from the German language VDR portal. During 2010, four more people have joined the team (Volker, Marco, Kersten, Lars). Besides the developers, we have a very reliable and growing group of helping hands around the core team that help us with testing and support. This is very valuable for us.

Extending the team should always be a very slow process so that there is time to get used to each other. Good cooperation is very important and as we rarely have meetings with all team members in real life due to the fact that we live in different locations, we can't just double the number of team members to become more productive. It wouldn't work. The development process can be very dynamic and chaotic at times. But this mixture is what makes the work within the team very exciting and motivating for us.

Q: If the Ubuntu release cycle is too fast for you: Why don't you use Debian as a basis for yaVDR?

A: TomG and e-tobi have been offering excellent VDR Debian packages for many years now (see our download page for more information). So there are already very experienced people working on packages for Debian. We chose Ubuntu because many software components (like the Linux kernel, ALSA, drivers, multimedia libs, etc) are being updated more often and we therefore have less work with offering backported packages for certain components. Also, the Launchpad.net platform that Canonical offers is an excellent platform for simplifying our package related work. Sadly, Launchpad.net doesn't offer to also build Debian packages yet.

The Debian project as such also has the big advantage that packages for the ARM platform are easily available from official repositories so that special hardware like the Dockstar, Pogoplug, Sheevaplug and so on can also act as a miniature VDR. This also adds to the importance of VDR Debian packages.

Q: How can the users of yaVDR 0.3 upgrade to yaVDR 0.4, once it is released?

A: Users of yaVDR 0.3 won't be able to automatically upgrade to yaVDR 0.4. They have to install yaVDR 0.4 from scratch. We know that this will cause frustration with many of our users with yaVDR 0.3. But a fresh installation is necessary.

Q: Why is that? Why don't you invest in a smooth upgrade experience?

A: There are three reasons:

• The lack of yaVDR packages for Ubuntu Maverick (10.10) which are needed to fill the gap between yaVDR 0.3 and yaVDR 0.4.
• For the ISO image, we have decided to make 64bit the default and we will only offer the yaVDR 0.4 ISO image for the 64bit platform. There is no upgrade path from 32bit to 64 bit.
• There were essential changes in several areas between yaVDR 0.3 and yaVDR 0.4.

Q: How can you afford to not offer a smooth upgrade experience?

A: We are aware that our users might expect a VDR distribution based on Ubuntu to be upgradable as smooth as it would be with an ordinary Ubuntu. But like we have tried to explain above, our time is limited and we decided to invest our time to fix other substantial problems. So there was no time to make sure that an update from yaVDR 0.3 (Lucid) via Ubunutu Maverick (no yaVDR packages exist) to yaVDR 0.4 (Ubuntu Natty) works. Until now, we focus on offering a good quality product for one modern platform and not average quality on all possible platforms. This may change in the future: yaVDR may become more popular and there may be more helping hands available with the right knowledge. Please keep in mind that yaVDR is a relatively young project (founded in autumn 2009) and that we are only talking about version 0.4.

Q: By the way: How popular is yaVDR now?

A: We can only guess. There have been more than 13.000 downloads of the yaVDR 0.3 ISO image now, and more than 18.000 downloads of all earlier yaVDR ISO images. The Launchpad PPA download statistics indicates that there are more than 6.000 installations of yaVDR 0.3 out there worldwide that obtain package updates from our PPAs via apt-get.

Q: So people have to reinstall. How will the yaVDR installer look in yaVDR 0.4? Which options does the installer offer?

A: We have always relied on the text based installer provided by Ubuntu with very small modifications and we will again for yaVDR 0.4. If you want to get familiar with the installer that will be used by yaVDR 0.4 please download the ubuntu-11.04-alternate ISO and check its installer:
http://www.ubuntu.com/download/ubuntu/a ... e-download
On the Ubuntu wiki you can find information about some known installation issues:
https://wiki.ubuntu.com/NattyNarwhal/Re ... st-install

Q: Do you expect all these users to move to yaVDR 0.4 quickly even if they have to reinstall?

A: Many of our users like to experiment and are happy to take small risks. Or, to put in some irony: Some of our users seem to be very experienced with reinstalling yaVDR . There is a trend towards reinstall-on-first-problem-discovered, and that goes of course without bothering to look at the log files which are also conveniently accessible from the yaVDR web frontend. It depends if the new features can convince our users.

Q: Will there be bug fixes for yaVDR 0.3 for users who don't want to install yaVDR 0.4? Will there be a yaVDR 0.3.1 maintainance release?

A: This is unclear at the moment. It depends on our available resources and our motivation after the release of yaVDR 0.4. Experience shows that we like to move forward and don't like to look back. There has never been a maintaince release of yaVDR after a new version was released.

Q: Are there ways to make sure yaVDR stable releases are better tested before they are published?

A: For yaVDR 0.4 we have decided to publish at least one ISO image as an official public alpha version. So users who don't want to test this alpha version can wait until the yaVDR 0.4 stable release is being published. the alpha version is also important for our voluntary translators: They can use the alpha version to translate the web frontend labels to different languages.

But we never claimed that our releases are perfect and without bugs. Most of the software components in the VDR universe (including drivers) are not tagged as stable versions. We always present a compilation  of unstable software components. This situation can't be changed easily. Maybe it will change over time.

Q: When is yaVDR 0.4 being released?

A: After we have got all big issues fixed within the alpha and beta releases we will publish.

Q: Well, when is yaVDR 0.4 alpha1 being released?

A: If things go as we expect them to go, 0.4 alpha1 is being released in May 2011.

More detailed information regarding the new features of yaVDR 0.4 will be available for you within the next blog postings that we will release soon.

Klaus Schmidinger has announced the release of VDR developer version 1.7.18. As always, we are excited about the new version and want to thank Klaus for his steady work on VDR core.

Klaus describes the changes in 1.7.18 like this:

• Changed -O2 to -O3 in Make.config.template (reported by Matti Lehtimäki).
• Added a missing 'default' case in cPixmapMemory::DrawEllipse().
• Fixed some direct comparisons of double values.
• Fixed detecting frames on channels that broadcast with separate "fields" instead of complete frames.
• Made updating the editing marks during replay react faster in case the marks file has just been written (with a patch from Udo Richter).
• Fixed horizontal scaling of subtitles (reported by Reinhard Nissl).
• Stripped the note "The data returned by this function is only used for informational purposes (if any)" from the description of cDevice::GetVideoSize(). The VideoAspect is now used to properly scale subtitles.
• Fixed cUnbufferedFile::Seek() in case it is compiled without USE_FADVISE (thanks to Juergen Lock).
• Fixed the Language header of the Serbian translation file (thanks to Ville Skyttä).
• Added anti-aliasing when upscaling bitmaps, which improves the display of SD subtitles when replayed on an HD OSD (thanks to Reinhard Nissl for his help in debugging).
• Renamed cBitmap::Scale() to Scaled(), because it doesn't modify the bitmap itself, but rather returns a scaled copy.
• Fixed the description of cReceiver in PLUGINS.html, regarding detaching a receiver from its device before deleting it (reported by Winfried Köhler). This change in behavior was introduced in version 1.5.7.
• Fixed scaling subtitles in case the OSD size is exactly the same as the display size of the subtitles.
• Added a missing initialization to sDvbSpuRect (reported by Sergiu Dotenco).
• Replaced "%lld" and "%llX" print format specifiers with "PRId64" and "PRIX64" to avoid compiler warnings with gcc 4.5.2 (thanks to Sergiu Dotenco). On a personal note: I find it a step in the totally wrong direction that there have been macros introduced to work around this problem in the first place. There should have been "real" format specifiers defined that address this. These macros are nothing but an ugly workaround.
• Added Cancel(3) to ~cTrueColorDemo() in the "osddemo" plugin (thanks to Reinhard Nissl).
• Added a missing font deletion in cTrueColorDemo::Action() in the "osddemo" plugin (thanks to Reinhard Nissl).
• Fixed a buffer overflow in cFont::Bidi() (thanks to Reinhard Nissl).
• Added HD stream content identifiers to vdr.5 (thanks to Christoph Haubrich).
• Made cRecordingInfo::Read(FILE *f) private to avoid calls to it from outside cRecordingInfo or cRecording (reported by Mika Laitio).
• The dvbhddevice plugin is now part of the VDR distribution archive (thanks to Andreas Regel).
• Removed an obsolete local variable in dvbsdffosd.c (thanks to Paul Menzel).
• Fixed a possible NULL pointer dereference in osddemo.c (reported by Paul Menzel).
• Now using pkg-config to get fribidi, freetype and fontconfig cflags and libs (thanks to Ville Skyttä).
• The Makefile now also installs the include files (thanks to Ville Skyttä).
• Added handling of "ANSI/SCTE 57" descriptors (thanks too Rolf Ahrenberg).
• Avoiding an unecessary call to Recordings.ResetResume() (thanks to Reinhard Nissl).

Information about earlier VDR developer versions of the 1.7 branch can be found in this overview .

genka, the administrator of VDR Portal has surprised the VDR community with a long promised board software update and a new board skin today. Some fine-tuning is still needed but the big picture is visible: The old-fashioned design of VDR Portal is gone and was replaced with a more modern look and feel and an improved user interface.

There will be a little learning curve involved for those members who have used VDR Portal for years and years and now have to adopt to the new navigation and structure, but in a few days time everybody should have grasped how to do things again.

One problem currently exists: The URL structure of the board has changed and personal bookmarks, Google search results and links from other websites will currently result in a "404 File not found" page. We hope that there will be a solution for this problem soon. UPDATE: This problem has been fixed.

The VDR Portal is the most important discussion place for the VDR community and has been for years. Sadly, there is no English language counterpart to it at the moment. But as often stated, English language postings are welcome in the yaVDR sub-forum which is now accessible via this URL:

www.vdr-portal.de/board60-linux/board14-betriebssystem/board96-yavdr/

Klaus Schmidinger has announced the release of VDR developer version 1.7.17, introducing a TrueColor OSD to VDR. As always, we are excited about the new version and want to thank Klaus for his steady work on VDR core.

Klaus describes the changes in 1.7.17 compared to its predecessor like this:

"This version introduces support for TrueColor OSD. Note, though, that output plugins need to be enhanced in order to support actual TrueColor display (if the device they control can handle TrueColor). Also, skins that want to make use of TrueColor may need to be adapted to the new interface using cPixmap.

The changes since version 1.7.16:

• Updated the Estonian OSD texts (thanks to Arthur Konovalov).
• Fixed following symbolic links in RemoveFileOrDir() (cont'd) (thanks to Steffen Barszus).
• Changed the description of cDevice::GetSTC() to make it mandatory for devicesthat can replay.
• Removed the check for positive STC values from cDvbSubtitleConverter::Action().
• Added cString::operator=(const char *String) (suggested by Antti Seppälä).
• Some spelling fixes (thanks to Ville Skyttä).
• Passing package name and version to xgettext (thanks to Ville Skyttä).
• Made 'dist' target dependent on up to date *.po (thanks to Ville Skyttä).
• Added Language and fixed Language-Team header of *.po (thanks to Ville Skyttä).
• Updated the Lithuanian OSD texts (thanks to Valdemaras Pipiras).
• Fixed detecting frames on channels that broadcast with 50 or 60 fps. This avoids artifacts during fast forward/rewind when replaying recordings from such channels. To fix the index of existing recordings from such channels, just delete the 'index' file of the recording and VDR will generate a new one the next time you play it. You should also change the line "F 25" to "F 50" in the 'info' file of that recording.
• Added support for "registration descriptor" to 'libsi' and using it in pat.c (thanks to Rolf Ahrenberg).
• Fixed unjustified log entries about changed channel pids (reported by Derek Kelly).
• Added an include of VDR's 'Make.global' to libsi's Makefile (thanks to Rolf Ahrenberg).
• Removed displaying the "contents" information from the "Classic VDR" and "ST:TNG Panels" skins, because it is often wrong and nothing but irritating.
• Added typecasts to avoid gcc 4.5 warnings in switch statements on eKeys variables where additional 'k_...' flags are used.
• Fixed inclusion of <stdarg.h> (thanks to Henning Heinold).
• Changed "frame duration" to "frame rate" in vdr.5 (reported by Tobias Grimm).
• Removing a cRemote from the Remotes list in case its initialization failed (thanks to Dominik Strasser).
• Added LDFLAGS to the linker calls in the Makefiles (thanks to Joerg Bornkessel and Paul Menzel).
• Now updating the 'frames per second' data in the list of recordings when a new recording is started that has a frame rate other than the default.
• The include path to the freetype2 header files is now retrieved via a call to 'pkg-config --cflags freetype2' (suggested by Andreas Oberritter).
• The OSD now has full TrueColor support. There can be several "pixmaps" that can be overlayed with alpha blending. All existing skins should work out of the box with the TrueColor OSD - the only exception being cOsd::GetBitmap(). Since the TrueColor OSD doesn't use bitmaps, this function will return a dummy bitmap, which may not be what the plugin expects. As long as this bitmap is only used for setting the palette, there is no problem. However, any other operations on this bitmap will have no effect. See the description of the cPixmap functions in osd.h for details about the new functionalities.
  • The "ST:TNG Panels" skin has been enhanced to automatically use the TrueColor OSD if available.
  • The "osddemo" plugin has been extended to show some of the possibilities of the TrueColor OSD if it is run on a system that actually provides TrueColor support. Thanks to Reinhard Nissl for some valuable input, help with debugging, and an implementation of the AlphaBlend() function.
• Updated the Slovakian language texts (thanks to Milan Hrala).
• Added Serbian language texts (thanks to Milan Cvijanovic).
• Fixed reallocating memory in the "pictures" plugin (reported by Paul Menzel, with input from Oliver Endriss).
• Fixed reallocating memory in cTsToPes::PutTs() (suggested by Oliver Endriss).
• Now checking the result of all realloc() calls.
• Fixed setting up the 'Recordings' menu in case there are several recordings with exactly the same name (reported by Marcus Hilbrich).
• Setting the audio type of language descriptors to 0x00 in the PAT/PMT generator (thanks to Anssi Hannula).
• Changed the compiler optimization flag to -O3, which gives quite a performance boost in the AlphaBlend() function.
• While replaying, the editing marks are now updated every 10 seconds (based on a patch from Manuel Reimer).
• Now reducing the thread and I/O priority cCuttingThread::Action() to make the foreground process more responsive (suggested by Frank Neumann).
• Removed checking for minimum line length of 21 characters in the LIRC receiver code (reported by Gerald Dachs).
• Updated the Romanian OSD texts (thanks to Lucian Muresan).
• Now storing the original display size when handling DVB subtitles (thanks to Reinhard Nissl).
• The original display size of subtitles is now used to scale them properly when displaying them on an HD OSD."

The yaVDR team will, as always, immediately start to experiment with new VDR version. Information about earlier VDR developer versions of the 1.7 branch can be found in this overview .