vdr

vdr@linuxtv.org

2 participants
6731 discussions

[Patch] crashes with old recordings without info file
by Mika Laitio 03 Apr '11

03 Apr '11

I have some old recordings made on 2005 which does not have info file. This caused vdr 1.7.17 to crash because in tools.c line 1194 there is no check whether the file parameter passed is NULL or not. Real cause for the crash is in the vdrrip plugins which should handle the case where the info file does not exist on setLengthVDR method on movie.c. Anyway, it's propably good idea also to has the NULL check's in vdr's own code. Patches attached for tools.c and recording.c. #0 0x00007ffff640e8ff in getdelim () from /lib64/libc.so.6 #1 0x00000000004fcd48 in getline (this=0x7fffffffde30, f=0x0) at /usr/include/bits/stdio.h:118 #2 cReadLine::Read (this=0x7fffffffde30, f=0x0) at tools.c:1194 #3 0x00000000004cc383 in cRecordingInfo::Read (this=0xc29bc0, f=0x0) at recording.c:419 #4 0x00007fffef0397a0 in cMovie::setLengthVDR() () from ./PLUGINS/lib/libvdr-vdrrip.so.1.7.17 #5 0x00007fffef03af00 in cMovie::cMovie(char const*, char const*) () from ./PLUGINS/lib/libvdr-vdrrip.so.1.7.17 #6 0x00007fffef0367d7 in cMenuVdrripMovie::cMenuVdrripMovie(char const*, char const*) () from ./PLUGINS/lib/libvdr-vdrrip.so.1.7.17 #7 0x00007fffef03807d in cMenuVdrripEncode::ProcessKey(eKeys) () from ./PLUGINS/lib/libvdr-vdrrip.so.1.7.17 [lamikr@tinka Prisma:_Einstein_ja_kaiken_teoria]$ ls -la 2005-04-21.20\:58.50.99.rec/ total 1338080 drwxr-xr-x 2 76 76 4096 2008-05-17 17:48 ./ drwxr-xr-x 3 76 76 4096 2008-05-17 17:46 ../ -rw-r--r-- 1 76 76 1369418800 2008-05-17 17:48 001.vdr -rw-r--r-- 1 76 76 727968 2008-05-17 17:48 index.vdr -rw-r--r-- 1 76 76 4 2008-05-17 17:48 resume.vdr -rw-r--r-- 1 76 76 441 2008-05-17 17:48 summary.vdr

2 2

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

Re: [vdr] [Patch] Make RGYB buttons customizeable
by Rolf Ahrenberg 02 Apr '11

02 Apr '11

On Fri, 1 Apr 2011, VDR User wrote: > Ignoring remotes that don't follow the RGYB scheme doesn't make them > any less 'tv oriented' or go away. I can't imagine it's much of a > leap to make the colored button position customizable and is probably > something that's better to have then not. What good argument against > allowing the user to customize the layout according to their actual > remote button layout could there be? None that I can think of. I'd > guess Klaus will consider any patches submitted to him which don't > cause problems. Regardless, users always have the option to patch the > feature in if it doesn't become a part of VDR's core. The RGYB color enumeration is defined in the video teletext standard and every TV/STB set implementing the teletext feature DOES use the mentioned color button order. I guess the teletext is used mainly in Europe, so there might be different conventions elsewhere, but the VDR is a STB for DVB standard that documents the teletext too. IMO, you really should switch the OSD button colors in skin plugins instead of patching the core VDR. There will be some glitches with learning the remotes, but these can be fixed with some extra documentation (Press 'Red/leftmost color' button). These remotes with "wrong" color button orders are really a small minority here mainly targeted to some odd mediacenters or PS3 - at least here in the northern Europe. BR, -- rofa

5 4

[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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr