vdr March 2011

vdr@linuxtv.org

40 participants
32 discussions

[Patch] Make RGYB buttons customizeable
by Oliver Schinagl 07 Apr '11

07 Apr '11

Hey all, Ever had the trouble that your remote's color navigation key weren't the same as VDR's? Well I wrote this patch the past 4 hours which lets you configure them. By doing so, the order of the buttons in the menu changes depending on whatever you tell it to. So finally that remote can match whatever is displayed on screen. This only works for the classic and st-tng skins, as those are supplied with VDR. The Skin needs to support this feature. If there is no skin support, the setting simply gets ignored by that skin. Since only the order of the buttons in the skin are being changed any plugin configuration will be independent from this change. What I mean is that, when a plugin has configured blue to take you straight to the photo gallery, the blue button will still do this, no matter where it is on the remote. If the plugin however used the blue key to fast forward, because it is the right most key, and thus made sense logically there, it will no longer when you move the keys around. Practically, this will boil down to a handful of plugins depending on location which imo is a little weird anyway :) Also, I patched it on a Gentoo box using the latest 1.6 ebuild they have so line numbers may be a little off in the patch due to various patches Gentoo may apply. It's the only dev. box for VDR I have so forgive me on that. I'm looking forward to the review :) Oliver

6 27

[ANNOUNCE] VDR developer version 1.7.17
by Klaus Schmidinger 03 Apr '11

03 Apr '11

VDR developer version 1.7.17 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.17.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.16-1.7.17.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. 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 devices that 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. Have fun! Klaus

8 22

vdr <-> vdr-xine <-> xine-lib and vdpau and HD recordings
by Joerg Riechardt 02 Apr '11

02 Apr '11

Hi, I have a problem with skipping during a replay of a HD recording. Running xine --verbose=2 I see after pressing the yellow button (skip +60 sec) lots of video_out: throwing away image with pts xxxxxxx because it's too old (diff : yyyyy) messages. This is for a few seconds or forever, depending on system load, and causes 100% Cpu, and spoils recordings on my slow system. On faster systems you will hardly notice this. If I patch cDvbPlayer::SkipSeconds with - readIndex = Index - 1; // Action() will first increment it! + readIndex = Index; // Index - 1 causes problems in xine I no longer get those „throwing away image“ messages and the Cpu peak is only short and not that high. This happens also for starting a replay and for resuming replay after fast forward, but for those I have no vdr patch. I would very much appreciate if somebody with deeper knowledge of the interplay between vdr <-> vdr-xine <-> xine-lib would look into and comment on this. You find more information at http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/p9… (german). Without patch the video plugin gets loaded first, the audio plugin second. With patch the video plugin gets loaded second, the audio plugin first. Don´t know if that is important. Joerg

3 8

[ANNOUNCE] dynamite plugin
by L. Hanisch 29 Mar '11

29 Mar '11

Hi, Some friends asked me to modify vdr/write a plugin, because their boxes boot so fast that most of the hardware is not initialized by the time vdr can start. They had to delay it or had to restart vdr when they think the hardware is ready. But since some pci-cards are 'fast enough' they would like to attach the 'slow' cards later while using the 'fast' cards for watching, recording etc. as soon as possible. So 'dynamite' was born (just some kind of wordplay with 'dynamic' and it sounds more 'bombastic' and effective in advertising than 'dyndev' or whatever). :-) It's clear that this can't be done without patching the device handling inside vdr, so attached is my patch against vdr 1.7.17. It is designed in such a way that the original behaviour of vdr is not changed if the dynamite plugin is not loaded. I know that it is pretty invasive but it is as small as I could to do it. My knowledge of the inner relations of the various classes is certainly limited but I spent hours and hours on reading the source. And it is tested by a brave crew of volunteers. Nonetheless I would like to hear some remarks from the vdr-experts out there. In the following lines I will try to explain what this patch-plugin-combination is able to do and how it's done. It's a bit lengthy but it's important to me and I know it wouldn't get integrated at all if I don't give a wider overview about the concepts and ideas behind this. Features: - attach/detach devices While vdr is running you can dynamically attach/detach (unused) receiving devices to/from it. This could be a DVB-USB-stick or a very slow initialising piece of hardware (firmware load etc.). New devices are detected via udev, detaching should be made manually. If a frontend is in use udev is not sending a corresponding signal, there are just some messages from the usb subsystem, for example. The mapping to the right frontend and detaching it automatically is not trivial (in other words: it's on the TODO list). Also OSD integration is completely missing but will be added in the future. For attaching/detaching there are SVDRP commands (and Service calls for other plugins): PLUG dynamite ATTD /dev/dvb/adapter0/frontend0 PLUG dynamite DETD /dev/dvb/adapter0/frontend0 For a complete list of commands please read the README[1]. - set device on idle You can set a device to 'idle' mode. It will be ignored by the EIT scanner and closes all its handles. This is handy if you have enough tuners and want so save some power or preserve some frontends from being 'always on'. This is also a 'manual' feature, some kind of automatism is planned (some kind of timeout or similar). Of course it will be 'reanimated' automatically if a recording is starting or someone wants to look live-tv. - GetTSPacket timeout It is possible to set a 'GetTSPacket' timeout on the devices. If a device delivers no data for some time it can be automatically detached. This is intended for devices which has known unstable drivers. After detaching such a device a script is started so the driver can be reloaded and the device can be attached again to the vdr (this could happen on its own if the created frontend is signaled by udev). It avoids restarts of vdr and interrupting recordings on other devices. How this all is achieved: The class cDevice is extended by two fields: parentDevice and subDevice. The dynamite plugin provides a class derived from cDevice which passes all calls to its methods to its subDevice if one is attached. Otherwise it returns the appropriate values so vdr does think it can't receive anything (like the dummydevice output-plugin which can play everything). On the other side there are some methods in cDevice which have to be "parentDevice-aware", since they are called from other derived devices or classes inside vdr. Since parentDevice (and subDevice) are always NULL if dynamite isn't loaded, it's easy to preserve the original behaviour. To get the cDynamicDevice between the vdr and the device-creating plugins dynamite is doing two things: - it registers a cDvbDeviceProbe-object and moves it to the front of the list - the patch adds a second list 'cDynamicDeviceProbe' for 'dynamite-aware' plugins (like pvrinput as an example) On startup when vdr iterates through the dvb-devices dynamite captures all devices and adds a cDynamicDevice for every one to the global vdr-device-array. It asks all other cDvbDeviceProbes if they would like to create a device and attaches this as a subDevice. If no cDvbDeviceProbe is left it creates a core cDvbDevice on its own. After this it creates enough cDynamicDevice objects to flood the vdr-device-array. This ensures that vdr and other plugins always communicate with the devices through dynamite (like CAM, CI etc.) and so there is enough room for devices which will be attached later. If you use plugins which create (non-dvb-)devices which can't be handled by dynamite (like xine, iptv, streamdev etc.) they have to be loaded *before* dynamite. Actually it's best to load dynamite as the *last* plugin because then it can ensure that its cDvbDeviceProbe will be the first one. The dirtiest part of the patch is the modification of the constructor of cDevice. If the new 'parentDevice' parameter would be made non-optional, I don't have to use this ugly global placeholder... If it really gets integrated in vdr (I don't abandon hope on this), that would definitly gets cleaned up. But that would force changes on many plugins so I chose 'the dirty way'. Plugins which would like to use the functionallity of dynamite had to alter their device detection in their startup phase: - if dynamite is loaded just register a cDynamicDeviceProbe object and use the helper function QueueDynamicDeviceCommand from cDynamicDeviceProbe to queue the strings it needs to create the device objects. - if dynamite is not present create the devices like before - make sure you close all handles on destruction at the latest Look at pvrinput[3] as an example (cPvrDevice::Initialize at device.c:269 and at the end of that file) pvrinput uses strings like '/dev/video0' to identify the device it has to create. But these 'attach'-strings doesn't necessarily need to be real device paths. It's just a parameter to the Attach method of your cDynamicDeviceProbe object - so your fantasy limits the possibilities. :-) In the dynamite source you'll find a cDynamiteDeviceProbe which reacts on strings like 'dummydevice0' or 'dummydevice1'. It helped me while developing the SVDRP commands since I had only one DVB-T stick at my dev-vdr. You can activate it with a commandline argument. There are some caveats if you would like to use other patches together with dynamite if they also extend cDevice. Every new method has to be investigated if it should return its own value or the one of the parentDevice or subDevice (if it's present). And every new virtual method has to be added to cDynamicDevice at the dynamite plugin. If I had 'the power' I would integrate the functionality of cDynamicDevice completly into cDevice and leave the controlling at the plugin - but I'm realistic enough to know, that that would need a lot of convincing for my part... :-) As an example I added a reworked version of the lnb-sharing-patch to my repository[2]. Also I include some methods added by the patches yaVDR uses since this is my preferred distribution. So, anything left to say? It took me a while to write all this stuff down so for now I don't know if I had forgotten something important or not. I'm looking forward for comments. Of course I'm never responsible for broken or missed recordings (as no one is)! :-) Thanks for reading! Regards, Lars. -- P.S.: If you have a Sundtek stick and are interested in dynamite, please check out the sundtek-plugin[4]. It monitors devices via the libmedia/mediasrv and can even react on unplugging a device which is in use. -- [1] http://projects.vdr-developer.org/projects/plg-dynamite/repository/revision… [2] git://projects.vdr-developer.org/vdr-plugin-dynamite.git [3] http://projects.vdr-developer.org/projects/plg-pvrinput [4] https://github.com/flensrocker/vdr-plugin-sundtek

6 10

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.17
by Tim 29 Mar '11

29 Mar '11

Am Samstag, 19. März 2011, um 13:02:02 schrieb Klaus Schmidinger: > >> - Fixed detecting frames on channels that broadcast with 50 or 60 fps. > I just made a recording from "arte HD" with VDR 1.7.17 and everything > worked fine. It played correctly (on a TT-S2 6400 prototype), the current > and total times displayed by the progress display were correct and I was > able to place and move an editing mark with the picture getting updated > just fine. For me the frame detection works fine, but still the wrong framerate is written to the info file (always F 25 is written there). Maybe some nasty patch is breaking this for me, but i don't find it. Is this really working correct for you? Can you give me a hint where the information is transferred from the cFrameDetector to cRecordingInfo? regards, Tim

3 4

remote frontend does not respond to keyboard after update
by Gero 27 Mar '11

27 Mar '11

Hello, I actually updated the vdr to recent developer version (from e-tobi) and now the remote frontend "vdr-sxfe" looks like sending different key codes to vdr. Changing chanels by cursor keys is the only that stil works. Before the update, vdr-sxfe sent XKeySym-codes to vdr, so it was easy to distinct between local and remote frontend by having diffent set of keycodes. I looked back the change history but could not find anything about those changes. May be I missed something. Does this keycode changes happened by intention, and/or is there a way to recover usage of XKeySym codes. kind regards Gero

1 0

[ANNOUNCE] naludump patch 0.1
by Udo Richter 24 Mar '11

24 Mar '11

Hi list, I've uploaded the final patch version of the h.264 NALU fill removal for VDR 1.7.16. The patch deletes NALU fill data from h.264 streams while recording. The overall stream structure isn't modified, only complete TS packets of NALU fill data are dropped. On HD TV channels that use fixed video bandwidth, this can save 40-60% file size without loosing any data. The patch must be enabled at settings -> recordings, and can be activated/deactivated individually for each recording by adding the keyword NALUDUMP or NALUKEEP to the recording name. Also available is the standalone tool that processes ts files. The new version uses the same buffering as the patch, and should otherwise produce identical output compared to the 0.0.1 tool. Get it at: http://www.udo-richter.de/vdr/naludump.html (de) http://www.udo-richter.de/vdr/naludump.en.html (en) Cheers, Udo

3 5

rotor-ng
by Arturo Martinez 22 Mar '11

22 Mar '11

Excellent news! I am sure the entire rotor vdr community will be very glad to hear that! At the moment I use diseqc.conf with goto position commands for each sat position to move the dish With rotor-ng does diseqc use have to be switched off in vdr and the plugin takes care of everything or does it parse diseqc.conf? Message: 1 Date: Mon, 21 Mar 2011 23:15:11 +0000 From: Morfsta<morfsta(a)gmail.com> Subject: Re: [vdr] rotor-ng in development [was [ANNOUNCE] vdr-actuator-1.2.0 plugin] To: VDR Mailing List<vdr(a)linuxtv.org> Message-ID: <AANLkTimUPe+jotg9J9V3pN5QG4iOJVG9_v8-m0Zest7h(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 20, 2011 at 10:08 PM, Timothy D. Lenz<tlenz(a)vorgon.com> wrote: > > I only have a Nexus-s for sat card and right now my rotor alignment is all > > screwed up. Relays went bad and had to replace them. I left the rotor > > elevation setting untouched but now it over shoots more and more the farther > > it goes as if the elevation is wrong. Haven't had time to look into it. Well, it seems I found the problem. The HAUPPAUGE NOVA-S2-HD card (HVR4000 lite / CX24116 frontend) won't lock onto DVB-S2 channels with FEC_AUTO or ROLLOFF_AUTO set. So, I modified the plugin to allow selectable values for FEC and ROLLOFF and now it works fine. I can now lock and scan DVB-S and DVB-S2 channels (QPSK and 8PSK) directly from the plugin menu and move the dish to find and store satellites with diseqc and signal strength meter. Ideal for feedhunting now! When I get a bit more time I'll tidy up the plugin and release it as it should now act as a pretty good satellite channel scanner irrespective of whether you have a rotor within VDR. I haven't tested the entire satellite transponder scanning functionality yet for DVB-S/S2, that will be the next task but hopefully it won't need many changes.

4 4

rotor-ng in development [was [ANNOUNCE] vdr-actuator-1.2.0 plugin]
by Morfsta 21 Mar '11

21 Mar '11

On Mon, Oct 11, 2010 at 1:32 PM, Morfsta <morfsta(a)gmail.com> wrote: > This really is sorely missing from VDR. Its a nice project which I > might look at if I ever get a spare moment! First I would have to > update my VDR from 1.7.0 with multiproto as lack of good support for > vdr-rotor has been holding me back from upgrading to S2API and later > development versions of VDR. Well, it took awhile but I have updated to yavdr 0.3 with S2API and a NV card and it is pretty stable now. The old rotor plugin is pretty unstable with yavdr (and perhaps later versions of VDR in general) and it seemed that no-one wanted to fix it, so I finally got around to modifying the actuator plugin to work with my disecq rotor (well actually a V-BOX hooked up to a 24V actuator). I can now get rid of the rotor plugin completely and drive my dish to the right positions and find / tune satellites with the modified actuator plugin, which IMHO works and looks better. It also allows me to scan DVB-S channels right from the plugin too. I'd like to release it at some point when I've tidied it up (perhaps as rotor-ng or something), but one issue I have is with DVB-S2 signal tuning and scanning on my Hauppauge Nova HD-S2 card - does anyone have this functionality working either with this card or another card with the actuator plugin's scanner? When I tune to a DVB-S2 channel (QPSK or 8PSK) within the plugin I get nothing, but when I tune in VDR the plugin shows full lock etc. I'd like to get this functionality working before releasing it and I thought it might be a problem with the card not supporting ROLLOFF_AUTO but that doesn't make any difference. Any help would be great. Thanks, Morfsta

3 3

[PATCH] VDR 1.7.17: fix frame detection
by Klaus Schmidinger 20 Mar '11

20 Mar '11

The attached patch reactivates some of the frame detecting code that was already in VDR 1.7.16, and adds a method of determining whether the current video stream consists of separate "fields" instead of complete frames. If this is the case, it puts two subsequent fields together to one frame in the index file. I know that the way this is detected (by counting the number of "frames" between two I-frames) is "guesswork", but until I see a case where this fails I'd say it still beats having a complete H.264 parser in there ;-) Please test the patch (which is against VDR 1.7.17) by recording all kinds of streams (SD and HD) available to you and verify that, when replaying such a recording - the current and total time in the replay progress display is correct. - fast forward/rewind works properly - setting an editing mark, jumping to it and moving it around updates the picture accordingly The patch activates 'DebugFrames', so whenever a recording starts VDR prints something like this to stderr: /50 /50 /50 /50 /30 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /10 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /30 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /10 Delta = 1800 FPS = 50.00 FPPU = 1 NF = 32 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /30 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /50 /10 * If you encounter a channel where one of the above tests fails, please send me the data VDR has printed to stderr when the recording started. Maybe it can help to further fine tune this. Please do all testing with newly created recordings that have been done with a VDR that has this patch applied. Klaus

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr March 2011