vdr October 2015

vdr@linuxtv.org

18 participants
10 discussions

VDR ISDB-T support
by Christian Rodriguez 14 Sep '18

14 Sep '18

Hello everyone! I'm from Argentina, and up to last month I've been using VDR 1.7.262 with an ISDB-T USB adapter. It works really good, but the last week I've been trying to upgrade to VDR 2.2 and I've found a problem with ISDB-T cards: they are not supported. As I'm really interested in using VDR, I was digging inside the code and found a partial solution for this problem: as ISDBT is the same as DVBT, I've changed the way delivery system is queried. My changes are applied in a cloned repo at github: https://github.com/chrodriguez/vdr/commit/dadbca57c2dc55c1c53b4fa8f68b56728… That's the only change I've made. Now I can enjoy my fresh upgraded VDR installation!! I think a better refactor should be made, but for now it's working perfectly deployed as a docker container: https://registry.hub.docker.com/u/chrodriguez/vdr Thanks for this wonderfull project! -- Lic. Christian A. Rodriguez @car_unlp

4 7

Using a rasberry pi as vdr client
by Damien Bally 01 Feb '16

01 Feb '16

Hi I want to use raspberry pi as if it were a graphic card : I mean the dvb devices on a PC style server, IR receiver preferably on the server too (rpi and server in the same room) I don't know how to configure it, there is apparently 2 ways of doing it (from what I understood) + xineliboutput with vdr-fbfe (rpi plugin is closed source ? the one here : http://www.vdr-portal.de/board18-vdr-hardware/board98-arm-co/118588-rasperr…) + streamdev and rpihddevice (which additional plugins ?) The second way seems to be more complicated to configure, and I'm not sure it suits my project, but the rpihddevice is well maintained though. The first solution is perhaps much straightforward and includes a media player (?) Could you tell me more please ? Damien

6 6

Raspberry Pi, satip, MLD
by Nicolas Huillard 15 Nov '15

15 Nov '15

Hi all, I still have a problem with my new setup: * Raspberry Pi B (256MB system + 256MB video) * MLD 5.0.0 testing distribution (http://www.minidvblinux.de/) on a 4GB class 6 SD card, using VDR 2.2.0.203-207 * vdr-plugin-rpihddevice (from MLD 1:2015.08.24-37+2.2.0.203) * Octopus Net (firmware 1.0.55) : Linux VLC shows TV channels without problems * vdr-plugin-satip (from MLD 2015.09.19-20+2.2.0.203) * recordings on an NFS share (works for playing, didn't test recording) * the Raspberry is powered from one of the 5V output from the Octopus, which provides enough power for the CI interface, which seems Playing live TV works great, until some point a few dozen minutes later, where some errors start to appear in /var/log/messages: Oct 25 10:51:59 vdrpi user.err vdr: [17414] ERROR: 1 ring buffer overflow (940 bytes dropped) Oct 25 10:52:01 vdrpi user.info vdr: [17414] SATIP: Detected 1 RTP packet errors [device 0] Oct 25 10:52:05 vdrpi user.err vdr: [17414] ERROR: 496 ring buffer overflows (652736 bytes dropped) Oct 25 10:52:11 vdrpi user.err vdr: [17414] ERROR: 584 ring buffer overflows (768544 bytes dropped) Oct 25 10:52:17 vdrpi user.err vdr: [17414] ERROR: 584 ring buffer overflows (768544 bytes dropped) Oct 25 10:52:23 vdrpi user.err vdr: [17414] ERROR: 580 ring buffer overflows (763280 bytes dropped) Oct 25 10:52:28 vdrpi user.err vdr: [17413] rpihddevice: [libav] Header missing Oct 25 10:52:28 vdrpi user.err vdr: [17413] rpihddevice: failed to decode audio frame! Oct 25 10:52:31 vdrpi user.err vdr: [17426] ERROR: TS packet not accepted in Transfer Mode Oct 25 10:52:31 vdrpi user.debug vdr: [17413] rpihddevice: set HDMI audio output format to 2ch PCM, 48.0kHz Oct 25 10:52:38 vdrpi user.err vdr: [17426] ERROR: TS packet not accepted in Transfer Mode Oct 25 10:52:38 vdrpi user.debug vdr: [17413] rpihddevice: set HDMI audio output format to 2ch PCM, 48.0kHz Some earlier errors were: Oct 24 18:02:59 (none) user.err vdr: [11447] SATIP-ERROR: Connection timeout - retuning [device 1] Oct 24 18:03:00 (none) user.err vdr: [11442] ERROR: 584 ring buffer overflows (768544 bytes dropped) Oct 24 18:03:04 (none) user.err vdr: [11447] SATIP-ERROR: Connection timeout - retuning [device 1] Oct 24 18:03:06 (none) user.err vdr: [11442] ERROR: 584 ring buffer overflows (768544 bytes dropped) Those errors lasted for hours, until I stopped VDR. It's usually not fixed until I power cycle the pi. I don't know were to look from here. Options are: * the satip plugin may not be the latest one (but the version number is unclear and the MLD forum is all german-speaking, which is a problem for me) * the ethernet interface may miss packets even though it does not report any packet loss (I changed the cable -quality and length- without success) * the power provided to the rpi may be enough, but I don't know about temperatures (the video core reports 54°C, but the ethernet chip may be too hot) * maybe the Octopus does not provide a proper stream, or the problem comes from the VDR core or the rpihddevice output... Since I'm new to rpihddevice, satip and MLD, and didn't stress previous Raspberry Pïs before, even though I use VDR since a dozen years at least, I'm really lost here. Latest test: a few second after switching some channel, the image froze, sound looped, and the pi was not reachable anymore through SSH, even though the octopus still reported the live stream and the network LEDs on the pi was still blinking. Hardware problem, network driver problem ? TIA, -- NH

3 4

Frequency as float in channels.conf
by Zsolt Barat 30 Oct '15

30 Oct '15

Dear List, I need to change the frequency value in channels.conf to a float value xxxxx.75. But since only INT values are allowed here I wonder how to achieve this. Any advice? Thanks and regards Zsolt

1 0

DXR3 cards
by Andy Carter 30 Oct '15

30 Oct '15

I have two DXR3 cards if anyone has a need for one. Avitus brand, 32bit PCI I've had them a long time, not used in years but kept just in case. No guarantee they are working now - but no reason why not :) Post to UK/EU only Andy

1 0

Softhddevice, 10 dupes per second
by Teemu Suikki 28 Oct '15

28 Oct '15

Hi! I was recently using Yavdr with no real problems, but now I decided to build my own VDR system on top of Linux Mint. Main reason was that Yavdr stable still doesn't have vdr 2.2.0.. I've got everything working nicely, but I have weird "duped frames" problem with softhhddevice. Video and audio are fine and nicely in sync, and usually you can't see anything wrong. But fast moving objects sometimes have "tearing" and jerky movement. Also if I open Softhddevice stats from the VDR main menu, I see that "duped" field increases steadily maybe 9-10 per second! "dropped" and "missed" stays at zero usually. There is nothing special on the log. Sometimes I get logs like this: Oct 26 01:09:42 puucee vdr: video: slow down video, duping frame Oct 26 01:09:42 puucee vdr: video: 22:17:22.060 +55 311 0/\ms 23+7 v-buf Oct 26 01:10:29 puucee vdr: video: slow down video, duping frame Oct 26 01:10:29 puucee vdr: video: 22:18:09.380 +53 285 0/\ms 26+7 v-buf But as you can see, these are almost a minute apart, and the actual "duped" count increased by several hundreds already during that time. So this logged "duping" is normal a/v sync, what I see is something different. This is VDR 2.2.0, and quite recent softhddevice from yavdr ppa: 1:0.6.1rc1.git20150924.1231-0yavdr0~trusty And the very same hardware worked just nicely with full yavdr install, with vdr 2.0.x and some old version of softhddevice. Oh, and I have nvidia GT210. -- Teemu Suikki http://www.z-power.fi/

5 6

Unable to compile media_build_experimental drivers on Debian stable
by Matthias Lötzke 19 Oct '15

19 Oct '15

Hello All, I has been using http://linuxtv.org/hg/~endriss/media_build_experimental for quite some time now. Until recently I never encountered a problem. Now I can't build any more: > make -C /home/matthias/tmp/media_build_experimental/v4l > make[1]: Entering directory '/home/matthias/tmp/media_build_experimental/v4l' > scripts/make_makefile.pl > ./scripts/make_myconfig.pl > perl scripts/make_config_compat.pl /lib/modules/3.16.0-4-amd64/source ./.myconfig ./config-compat.h > creating symbolic links... > xargs: ln: Too many levels of symbolic links ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Makefile:264: recipe for target 'links' failed > make[1]: *** [links] Error 126 > make[1]: Leaving directory '/home/matthias/tmp/media_build_experimental/v4l' > Makefile:28: recipe for target 'all' failed > make: *** [all] Error 2 > build failed at ./build line 491. I am using Debian stable with Kernel 3.16.0-4-amd64. Some hundreds maybe thousands of symlinks are being created where the build fails. Any solution or hint would be highly appreciated. Best regards Matthias

2 3

[ANNOUNCE] rpihddevice plugin 1.0.0
by Thomas Reufer 19 Oct '15

19 Oct '15

Hi all rpihddevice-1.0.0 is now available! Description: VDR HD output device for Raspberry Pi. The plugin makes use of the Raspberry Pi's VideoCore GPU and provides a lightweight implementation for a VDR output device. Features: - MPEG-2 and H264 high-profile video codec up to 1080p30 - MPEG-1 Layer II, (E)AC-3, AAC and DTS audio codec at 32kHz, 44.1kHz or 48kHz with 2.0 (Stereo) or 5.1 channels - HDMI multi channel LPCM audio output - HDMI digital audio pass-through - Analog stereo audio output - Box (letter-box/pillar-box), Crop and Stretch video display modes - True color OSD with GPU support - Video scaling and grabbing support Download: http://projects.vdr-developer.org/attachments/download/1966/vdr-rpihddevice… Homepage: http://projects.vdr-developer.org/projects/plg-rpihddevice Recent changes: 2015-10-18: Version 1.0.0 ------------------------- - new: - updated Hungarian translations (thanks to Füley István) - updated Finnish translations (thanks to Rolf Ahrenberg) - added Italian translations (thanks to Gerlando Falauto) - added French translations (thanks to Cyril Jaquier) - added plugin options to specify video and OSD layers - fixed: - don't crop OSD images to pixmap size to allow scaled drawing - treat zero as valid PTS value - perform save / restore region direct on pixmaps for accelerated OSDs - wait for the OVG thread to be ready when creating an accelerated OSD - set field sync when output interlaced material at interlaced display mode Have fun, Thomas

6 7

[ANNOUNCE] VDR developer version 2.3.1
by Klaus Schmidinger 10 Oct '15

10 Oct '15

VDR developer version 2.3.1 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.1.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-2.2.0-2.3.1.diff MD5 checksums: 391c2ed60e2f7d24563fe3ed5854bc4f vdr-2.3.1.tar.bz2 983fd4bad7d19cd98301d54173107129 vdr-2.2.0-2.3.1.diff WARNING: ======== This is a *developer* version. Even though *I* use it in my productive environment, I strongly recommend that you only use it under controlled conditions and for testing and debugging. *** PLEASE BE VERY CAREFUL WHEN USING THIS DEVELOPER VERSION, ESPECIALLY *** IF YOU ENABLE THE NEW SVDRP PEERING! KEEP BACKUPS OF ALL YOUR TIMERS *** AND OBSERVE VERY CLOSELY WHETHER EVERYTHING WORKS AS EXPECTED. THIS *** VERSION INTRODUCES SOME MAJOR CHANGES IN HANDLING GLOBAL LISTS AND *** LOCKING, SO ANYTHING CAN HAPPEN! YOU HAVE BEEN WARNED! The main focus of this developer version is on the new locking mechanism for global lists, and the ability to handle remote timers. Any plugins that access the global lists of timers, channels, schedules or recordings, will need to be adjusted (see below for details). Please do initial tests with plain vanilla VDR and just the output plugin you need. Known bugs/problems: - After deleting the last recording in a sub folder, the cursor may not be positioned correctly. - Instant recordings and pausing live video don't (yet) use the default SVDRP host for recording. The changes since version 2.2.0: - The new function cOsd::MaxPixmapSize() can be called to determine the maximum size a cPixmap may have on the current OSD. The 'osddemo' example has been modified accordingly. Plugin authors may want to use this function in case they use pixmaps that are larger than the full OSD size. The default implementation sets this limit to 2048x2048 pixel. - The Setup/CAM menu now displays which device an individual CAM is currently assigned to (suggested by Frank Neumann). - Added detection of 24fps (thanks to Thomas Reufer). - Added a note about the VDR User Counter and VDR's facebook page to the README file. - The dvbhddevice plugin is no longer part of the VDR source archive. You can get the latest version of this plugin from the author's repository at https://bitbucket.org/powARman/dvbhddevice. - The dvbsddevice and rcu plugins are no longer part of the VDR source archive. You can get the latest versions of these plugins from ftp://ftp.tvdr.de/vdr/Plugins. - Added a section about Output Devices to the INSTALL file. - Fixed setting the source value of newly created channels, in case the NIT is received from a different, but very close satellite position (reported by Daniel Ribeiro). The code for handling different NITs has been removed from nit.c, because according to the DVB standard table id 0x40 carries only the NIT of the actual network. - Added some comment to cPixmap about the relation between OSD, ViewPort and DrawPort (suggested by Thomas Reufer). - Improved syncing on sections when parsing the NIT and SDT. - Fixed scaling subtitles (their areas could sometimes extend outside the actual OSD). - Reduced the priority of the "video directory scanner" thread (suggested by Thomas Reufer) and checking cIoThrottle::Engaged() when it is running. - The script that gets called for recordings is now also called right before a recording is edited, with the first parameter being "editing" (suggested by Dieter Ferdinand). - The new setup option "OSD/Default sort mode for recordings" can be used to define how recordings shall be sorted by default (either by time or by name, with "by time" being the default). If a particular sort mode has been selected for a folder by pressing '0', the default no longer applies to that folder. Repeating timers no longer write a ".sort" file into a recordings folder to have the recordings sorted by time. - The command line option -D now accepts the value '-' (as in -D-), which prevents VDR from using any DVB devices (suggested by Dietmar Spingler). - The -V and -h options now list the plugins in alphabetical order (suggested by Dietmar Spingler). - Fixed a compiler warning in font.c. - Commented out the line #define DEPRECATED_VIDEOSYSTEM in device.h. If a plugin doesn't compile with this version of VDR, you can uncomment this line as a quick workaround. In the long run the plugin will need to be adapted. - The function cOsd::GetBitmap() is now 'protected'. If a plugin doesn't compile with this version of VDR, you can uncomment the line //#define DEPRECATED_GETBITMAP in osd.h as a quick workaround. In the long run the plugin will need to be adapted. - The -u option now also accepts a numerical user id (suggested by Derek Kelly). - The SVDRP port now accepts multiple concurrent connections. You can now keep an SVDRP connection open as long as you wish, without preventing others from connecting. Note, though, that SVDRP connections still get closed automatically if there has been no activity for 300 seconds (configurable via "Setup/Miscellaneous/SVDRP timeout (s)"). - The SVDRP log messages have been unified and now always contain the IP and port number of the remote host. - SVDRP connections are now handled in a separate "SVDRP server handler" thread, which makes them more responsive. Note that there is only one thread that handles all concurrent SVDRP connections. That way each SVDRP command is guaranteed to be processed separately, without interfering with any other SVDRP commands that might be issued at the same time. Plugins that implement SVDRP commands may need to take care of proper locking if the commands access global data. - VDR now sends out a broadcast to port 6419/udp, which was assigned to 'svdrp-disc' by the IANA. VDRs listening on that port will automatically initiate an SVDRP connection to the broadcasting VDR, and in turn send out a broadcast to make other VDRs connect to them. That way all VDRs within the local network will have permanent "peer-to-peer" SVDRP connections between each other. The configuration in the svdrphosts.conf file is taken into account when considering whether or not to respond to an SVDRP discover broadcast. - The new SVDRP command PING is used by automatically established peer-to-peer connections to keep them alive. - The new function GetSVDRPServerNames() can be used to get a list of all VDRs this VDR is connected to via SVDRP. - The new function ExecSVDRPCommand() can be used to execute an SVDRP command on one of the servers this VDR is connected to, and retrieve the result. The helper functions SVDRPCode() and SVDRPValue() can be used to easily access the codes and values returned by ExecSVDRPCommand(). - The cTimer class now has a new member named 'remote', which holds the name of the remote server this timer will record on. If this is NULL, it is a local timer. - Timers from other VDRs that are connected to this VDR via SVDRP are now automatically fetched and stored in the global Timers list. In order for this to work, all of the channels used by timers on the remote VDR must also be defined on the local VDR (however, not necessarily in the same sequence). Automatic channel syncing will be implemented later. - The main menu of the LCARS skin now displays a small rectangle on the left side of a timer if this is a remote timer. The color of that rectangle changes if the timer is currently recording on the remote VDR. - Accessing the global Timers list now has to be protected by proper locking, because SVDRP commands are now executed in a separate thread. The introduction of this locking mechanism required the following changes: + The new classes cStateLock and cStateKey are used to implement locking with quick detection of state changes. + cConfig::cConfig() now has a parameter that indicates whether this list requires locking. + The global lists of Timers, Channels, Schedules and Recordings are no longer static variables. They are now pointers that need to be retrieved through a call to cTimers::GetTimersRead/Write(), cChannels::GetChannelsRead/Write(), cSchedules::GetSchedulesRead/Write() and cRecordings::GetRecordingsRead/Write(), respectively. + References from/to link channels are now removed in cChannels::Del() rather than cChannel::~cChannel(), to make sure the caller holds a proper lock. + cChannel::HasTimer() has been removed. This information is now retrieved via cSchedule::HasTimer(). + Several member functions of cChannel, cTimer, cMarks and cRecording have been made 'const', and some of them are now available as both 'const' and 'non-const' versions. + The cChannel::Set...() functions are now 'bool' and return true if they have actually changed any of the channels's members. + cChannels::SetModified() has been renamed to cChannels::SetModifiedByUser(). + cChannels::Modified() has been renamed to cChannels::ModifiedByUser(), and now has a 'State' parameter that allows the caller to see whether a channel has been modified since the last call to this function with the same State variable. + The macros CHANNELSMOD_NONE/_AUTO/_USER have been removed. + cMarks now requires locking via cStateKey. + cSortedTimers now requires a pointer to the list of timers. + cEvent::HasTimer() no longer scans the list of timers to check whether an event is referenced by a timer, but rather keeps score of how many timers reference it. This was necessary in order to avoid having to lock the list of timers from within a cEvent. + The new class cListGarbageCollector is used to temporary store any objects deleted from cLists that require locking. This allows pointers to such objects to be dereferenced even if the objects are no longer part of the list. + cListBase::Contains() can be used to check whether a particular object is still contained in that list. + Outdated events are no longer "phased out", but rather deleted right away and thus taken care of by the new "garbage collector" of the list. + Deleted cRecording objects are no longer kept in a list of "vanished" recordings, but are rather taken care of by the new "garbage collector" of the list. + cSchedules::ClearAll() has been removed. The functionality is now implemented directly in cSVDRPServer::CmdCLRE(). + tEventID has been changed to u_int16_t in order to make room for the new member numTimers in cEvent. + cSchedule now has a member Modified(), which can be used with a State variable to quickly determine whether this schedule has been modified since the last call to this function with the same State variable. + cSchedulesLock has been removed. Locking the list of schedules is now done via the cList's new locking mechanism. + The 'OnlyRunningStatus' parameters in cEpgHandler::BeginSegmentTransfer() and cEpgHandler::EndSegmentTransfer() are now obsolete. They are still present in the interface for backward compatibility, but may be removed in a future version. Their value is always 'false'. + The constant tcMod is no longer used in cStatus::TimerChange(). The definition is still there for backward compatibility. Plugins that access the global lists of Timers, Channels, Recordings or Schedules will need to be adapted as follows: + Instead of directly accessing the global variables Timers, Channels or Recordings, they need to set up a cStateKey variable and call the proper getter function, as in cStateKey StateKey; if (const cTimers *Timers = cTimers::GetTimersRead(StateKey)) { // access the timers StateKey.Remove(); } and cStateKey StateKey; if (cTimers *Timers = cTimers::GetTimersWrite(StateKey)) { // access the timers StateKey.Remove(); } See timers.h, thread.h and tools.h for details on this new locking mechanism. + There are convenience macros for easily accessing these lists without having to explicitly set up a cStateKey and calling its Remove() function. These macros have the form LOCK_*_READ/WRITE (with '*' being TIMERS, CHANNELS, SCHEDULES or RECORDINGS). Simply put such a macro before the point where you need to access the respective list, and there will be a pointer named Timers, Channels, Schedules or Recordings, respectively, which is valid until the end of the current block. + If a plugin needs to access several of the global lists in parallel, locking must always be done in the sequence Timers, Channels, Recordings, Schedules. This is necessary to make sure that different threads that need to lock several lists at the same time don't end up in a deadlock. + Some pointer variables may need to be made 'const'. The compiler will tell you about these. - cSectionSyncer has been improved to better handle missed sections. - Added a missing initialization of 'seen' in cChannel's copy constructor. - Background modifications of channels, timers and events are now displayed immediately in the corresponding menus. - cEIT now checks the version of the tables before doing any processing, which saves a lot of locking and processing. - If a timer is newly created with the Red button in the Schedule menu, and the timer is presented to the user in the "Edit timer" menu because it will start immediately, it now *must* be confirmed with "Ok" to set the timer. Otherwise the timer will not be created. - Recordings and deleted recordings are now scanned in a single thread. - The new SVDRP command POLL is used by automatically established peer-to-peer connections to trigger fetching remote timers. - You can now set DumpSVDRPDataTransfer in svdrp.c to true to have all SVDRP communication printed to the console for debugging. - Added a missing 'const' to cReceiver::Receive(), to protect the given Data from being modified. - The SVDRP commands that deal with timers (DELT, LSTT, MODT, NEWT, NEXT and UPDT) as well as any log messages that refer to timers, now use a unique id for each timer, which remains valid as long as this instance of VDR is running. This means that timers are no longer continuously numbered from 1 to N in LSTT. There may be gaps in the sequence, in case timers have been deleted. - The Timers menu now displays the name of the remote VDR in front of the timer's file name, if this is a remote timer. - The new options "Setup/Miscellaneous/SVDRP peering", ".../SVDRP host name" and ".../SVDRP default host" can be used to configure automatic peering between VDRs in the same network. Peering is disabled by default and can be enabled by setting "SVDRP peering" to "yes". - The function cTimer::ToText() no longer returns a newline character at the end of the string. The newline is now added by the caller as necessary. This was changed because cTimer::ToText() is now also needed in a context where the terminating newline can't be used. Consequently, cChannel::ToText() and cMark::ToText() have been modified accordingly. - All timer related response strings from SVDRP commands now use the channel ID instead of channel numbers. - The "Edit timer" menu now has a new parameter "Record on", which can be used to select the VDR on which this timer shall record. Timers can be freely moved between connected VDRs by simply selecting the desired machine in this field. - The SVDRP command DELT no longer checks whether the timer that shall be deleted is currently recording. - The character 0x0D is now stripped from EPG texts (reported by Janne Pänkälä). - The EPG scanner no longer moves the dish if there is a positioner. - The 'newplugin' script now creates the 'po' subdirectory for translations (thanks to Thomas Reufer). - Skins can now implement cSkinDisplayMenu::MenuOrientation() to display horizontal menus (thanks to Stefan Braun). - Fixed a possible stack overflow in cListBase::Sort() (thanks to Oliver Endriss). - Changed the description of the --chartab option in the INSTALL file to refer to "DVB SI table strings" instead of "EPG data". - The width and height of the OSD are now limited to the actual maximum dimensions of the output device, taking into account the top and left offset. - The new setup option "Recording/Record key handling" can be used to define what happens if the Record key on the remote control is pressed during live tv (suggested by Dietmar Spingler). - Empty adaptation field TS packets are now skipped when recording (thanks to Christopher Reimer, based on the "AFFcleaner" by Stefan Pöschel). Have fun! Klaus

2 1

Which DVB-S / DVB-S2 cards are recommended?
by Christian Rodriguez 02 Oct '15

02 Oct '15

Hello! I'm new to satellite systems, so I would like to buy a cheap card, considering decrypting streams. The question is about which hardware is recommended to run with VDR, that can decode encrypted traffic Thanks in advance! -- Lic. Christian A. Rodriguez @car_unlp

8 10

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr October 2015