[vdr] vdr-api: how to check if VDR is up?
Hi, the epgsearch plugin handles some tasks as separate threads, that also use SVDRP to talk to VDR. Currently these threads are started after a fixed time (e.g. 20s) to give VDR the time to start up. A user reported that epgsearch fails in SVDRP communication, because VDR was still waiting for its devices (and therefore is not yet ready to accept SVDRP connections): Jun 3 20:07:40 vdr vdr: [3466] not all devices ready after 30 seconds These 30 seconds are only defined in vdr.c and are therefore 'invisible' to plugins. So I'm looking for 'clean' way to check if VDR is up and ready. Of course, one could do any SVDRP command, e.g. 'help', and check the result, but thats quite cumbersome. Next idea: use cPlugin::Housekeeping() to signal the threads that VDR is idle now after startup. This works, but sometimes takes up to 90s. Any idea how to get a better solution? Thanks, Christian ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] making VDR ext4-ready
On 07.06.2009 01:58, Marcel Witte wrote: So ext4 seems to be perfect for a video-partition, but to make it more perfect, it would be nice if VDR could use the fallocate()-systemcall as mentioned in the article. This would prevent fragmentation in the file system. Udo wrote: Sounds like a good plan, but unfortunately fallocate requires you to know in advance how big a file will be. This is not true for VDR recordings. And if you fallocate with too small or too big sizes, you'll end up with fragmentation or smaller chunks of unused space again. (All in all, this is probably only important for concurrent recordings anyway.) Well you can predict file size for certain extent. As VDR has the split recording option built in. That is the maximum filesize. - If you have 1h10min timer. - Allocate 1st file upto split size - Calculate average BW at the same time you are recording - You could even store this - If file is too small, allocate new file for remaining time with average BW + overhead If you have 10min timer (or short timer which will cause filesize under split size) - if you store average BW what channels are having you could allocate directly estimated size Naturally this is not 100% accurate, and would cause some big size fragmentation. For EXT4 it would be nice: - fallocate(4GB) - open file for write - close file after 3GB - automatic fdeallocate(1GB) smime.p7s Description: S/MIME cryptographic signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] repeat Vol key
Date: Sun, 7 Jun 2009 19:30:34 +0200 From: Gerald Dachs v...@dachsweb.de Subject: Re: [vdr] repeat vol key To: vdr@linuxtv.org Message-ID: 20090607193034.5ef1f...@master Content-Type: text/plain; charset=US-ASCII I use the remote that comes with the Hauppagge S2-HD (and hence connected to the card itself) lirc connects to this remote vi/dev/input/by-path/pci-:01:0a.0--event-ir This is part of my /etc/lircd.conf name NOVA-HD-S2 bits 16 eps30 aeps 100 one 0 0 zero0 0 pre_data_bits 16 pre_data 0x1 gap 19 min_repeat 1 toggle_bit 1 Am Sun, 7 Jun 2009 19:01:00 +0200 schrieb marti...@embl.de: in /etc/vdr/remote.conf I have (among others) these two entries: LIRC.Volume+VolumeUp LIRC.Volume-VolumeDown My wife complains that to increase the volume she has to press many times VolumeUp rather than simply hold it down. Is there something I can do to make her happy? Recently I have read about some simple USB IR receivers that don't send the toggle bit that lirc needs to recognize the hold of a button. I suppose you use one of them, because normally it works like your wife expects. So I believe you should exchange the IR receiver. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Build failures with gcc 4.4
Klaus Schmidinger wrote: On 04.06.2009 09:12, Ludwig Nussel wrote: ... So gcc 4.4 finally hit openSUSE as well. I use the attached patch to make vdr compile. Seems to work fine too. The code that requires those const casts is really ugly though. How about the attached change? Should apply to VDR 1.6 just as well. Looks better indeed. I've added it to the vdr package in the build service now. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] howto change time of epg grap?
hello From what I observe vdr is waiting to grap the epg content of a timed recording until this recording starts. There are a bunch of channels where this leads to unwelcome side effects: - Take a channel that is using place holder events in the now section of epg during commerical breaks between two events. - Take a channel that is broadcasting only one status signal, timed to the ending of each event. So you have the whole comerical break recorded as well. Vdr will start the recording with the status signal - this one bumps right into the beginning of the placeholder event. Thus the epg data vdr grabs is from the placeholder event, thus it is empty. I know it is the broadcasters fault, not vdr - I assume broadcasters using digital vps should *never* switch now/next epg events before the next event is indeed running. They sure can use place holder events between two scheduled events, but if they decide to do so, they should wait switching now/next event until the next event starts. If my broadcaster only could stick to this rule of thumb, there couldn't be a problem, sadly he never does. What can I do? I'd like vdr to wait a few minutes until he grabs epg data - or vdr could grab the epg data right away when I add the timer. Both ways sould be working. _ http://redirect.gimas.net/?n=M0906xWLM2009 Neu: Messenger 2009! Hier kostenlos downloaden!___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Any really working HD video output systems for VDR?
On Fri, 2009-06-05 at 23:40 +0300, Vesa wrote: -Original Message- I have not seen those kinds issues with eHD card. But I use on my setup separate video processor (DVDO VP30 with abt102) for deinterlacing and scaling to 1080P. Well, your setup is a little different than what I have. I can get jagged lines when I use eHD own deinterlacer, it seems to miss even/odd field detection sometimes. Also TV:s own deinterlacer seems to lost half of resolution when video is 576i when comparing to DVDO. Are you absolutely sure that signal is 576i on HDMI? What TV tells about video? It can be that also Mitsubishi sends 576P signal. True 576i/486i support is rare on HDMI devices, specification recommend always to use at least 576P, sd resolutions are possible but not recommended.. I am reasonably sure since it is a supported resolution in the VPR manual, and it is the listed resolution on the VPR on screen display. At this point there can be three different explanations: 1 - the internal scaler of my VPR behaves differently when it receives 576i from the s-video port and the HDMI port 2 - I'm doing something wrong with the eHd output 3 - The ehd output - in my conditions - is really worse than the ff card Will experiment further, and will let you know when/if I come to any conclusion Thanks and regards Mattia -- ---MR.- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Any really working HD video output systems for VDR?
On Fri, 5 Jun 2009 08:49:02 -0700 VDR User user@gmail.com wrote: --- snip - On a side note I just want to say that I see some posts here about peoples expectations.. I want to record X, and Y, while playing Z with no dropped frames, etc etc. I hope you guys understand that things like that are not only related to software. Your hardware is a factor and if your hardware can't do it then it can't do it and doesn't automatically mean there's a problem with your software. Your signal matters too. I can't speak for the other participants of this thread, but I consider myself an 'old hand' of vdr having started fiddling with this great piece of software since version 1.0 (2002) and I am used to what for users of a full featured dvb-s card is normal: rock solid stability, excellent video quality, no dropped frames whatsoever, up to the bandwidth limit of the card (about 20Mbit/s), great zapping time, time shifting as the norm, multiple card installations without conflicts and so on. The only thing the FF card won't do is play/replay HD content and while this is still not so important at the moment (at least in Italy) since we're used to such a great level of quality it will be hard to obtain the same results with a new generation solution. The need for time in such a discovery process, at least on my part, is fully understood, I only wish that sometimes the guys from Reel would provide a little more documentation (in english) about how they do some things in the avantgarde, but this is probably what is actually giving the avantgarde the edge over a normal vdr install, so I won't complain. Regards Mattia ---MR.--- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Any really working HD video output systems for VDR?
On Mon, Jun 08, 2009 at 09:40:04PM +0200, Mattia Rossi wrote: The need for time in such a discovery process, at least on my part, is fully understood, I only wish that sometimes the guys from Reel would provide a little more documentation (in english) about how they do some things in the avantgarde, but this is probably what is actually giving the avantgarde the edge over a normal vdr install, so I won't complain. Just ask, there are no secrets ;) There's just not enough time to guess what will be of interest... -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Any really working HD video output systems for VDR?
On Mon, Jun 8, 2009 at 8:54 PM, Georg Acherac...@in.tum.de wrote: Just ask, there are no secrets ;) There's just not enough time to guess what will be of interest... Great! Georg, can you let us know why FF/FR and pause/play handling within VDR with reelbox-3 is so laggy? It makes jumping, searching and seeking within VDR almost unusable. Is there anything we can do to fix this? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] making VDR ext4-ready
jori.hamalai...@teliasonera.com schrieb am Montag 08 Juni 2009: On 07.06.2009 01:58, Marcel Witte wrote: So ext4 seems to be perfect for a video-partition, but to make it more perfect, it would be nice if VDR could use the fallocate()-systemcall as mentioned in the article. This would prevent fragmentation in the file system. Udo wrote: Sounds like a good plan, but unfortunately fallocate requires you to know in advance how big a file will be. This is not true for VDR recordings. And if you fallocate with too small or too big sizes, you'll end up with fragmentation or smaller chunks of unused space again. (All in all, this is probably only important for concurrent recordings anyway.) Well you can predict file size for certain extent. As VDR has the split recording option built in. That is the maximum filesize. - If you have 1h10min timer. - Allocate 1st file upto split size - Calculate average BW at the same time you are recording - You could even store this - If file is too small, allocate new file for remaining time with average BW + overhead If you have 10min timer (or short timer which will cause filesize under split size) - if you store average BW what channels are having you could allocate directly estimated size Naturally this is not 100% accurate, and would cause some big size fragmentation. For EXT4 it would be nice: - fallocate(4GB) - open file for write - close file after 3GB - automatic fdeallocate(1GB) This was exactly the idea I had... You know the average bitrate and the timer- length, or if used the length of one split-file. And I think 99% of all recordings will not be aborted while recording. So this would be the best way to make use of the ext4-extends. And because of the new libc/kernel you need: You can use #defines ;) also we have a development branch (1.7.x) an until this goes stable I think ext4 is a standard-file system (Fedora, Ubuntu and openSUSE will use it as default in the next versions) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-text2skin-1.2
On Mon, 1 Jun 2009, Thomas Günther wrote: Hello! This is the first release of the VDR Text2skin plugin from http://projects.vdr-developer.org. Thank you very much, this is a great plugin. I often lost track of various patches and cvs snapshots and I'm so glad you took over. I also had various OSD problems the whole year after replacing xine with softdevice and this release solved it. Enigma, DeepBlue... all look perfect now. -- Adrian C. (anrxc) | anrxc..sysphere.org | GPG ID: D20A0618 GPG FP: 02A5 628A D8EE 2A93 996E 929F D5CB 31B7 D20A 0618 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Any really working HD video output systems for VDR?
On Mon, Jun 08, 2009 at 09:09:06PM +0100, Morfsta wrote: On Mon, Jun 8, 2009 at 8:54 PM, Georg Acherac...@in.tum.de wrote: Just ask, there are no secrets ;) There's just not enough time to guess what will be of interest... Great! Georg, can you let us know why FF/FR and pause/play handling within VDR with reelbox-3 is so laggy? It makes jumping, searching and seeking within VDR almost unusable. Ouch, I expected more technical questions ;-) At least for the reelvdr-base, I don't see any special handling for these cases. All the dirty stuff is done in the plugin and and on the DeCypher-side... Is there anything we can do to fix this? Send me a full patched vdr-package that shows this behavior... -- Georg Acher, ac...@in.tum.de http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
