[vdr] Improve SVDRP GRAB ...
Greetings! I would like to 'improve' (or simply extend) the SVDRP Grab command to allow for grabbing a picture from a given channel, if possible, without disturbing normal operations basic idea: get a device which is capable of tuning the specified channel (optionally shared transponder) tune to the channel/stream, and wait until data is available (or some timeout has been reached) grab a screenshot (similar to current grab) now, what I tried so far is the following (with little success :) cChannel *gChan = Channels.GetByNumber(ChanNum); cDevice *gDev = cDevice::GetDevice(gChan, 0, 1); gDev->SwitchChannel(gChan, 1); if (gDev->HasLock(5000) && gDev->HasProgramme()) Image = gDev->GrabImage(ImageSize, Jpeg, Quality, SizeX, SizeY); the problems with this approach are: the primary device changes, even if the transponder is the same the grabbed image is black, because the data is not available when the actual grab happens any suggestions how to do that properly? TIA, Herbert ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Error while Recording and loose signal
On Thu, Jul 27, 2006 at 07:34:32PM +0200, Udo Richter wrote: > daliman wrote: > >Sorry but it is not possible for me to describe this error in english. > >Maybe the google-translator work. > > > >Bei Aufzug eines Gewitters empfängt die Satanlage kein Signal mehr, > >so daß ich nur noch schwarz sehe, jedoch habe ich nach einiger Zeit > >wieder Empfang. Wenn während dieser Zeit aber eine Aufnahme läuft, > >dann beendet sich der VDR. (Restart; runvdr). > > (translated: With a thunderstorm approaching, the sat receiver receives > no signal, so that I see only black, however has I after some time > reception is back. If a recording is running during this time, then the > VDR is terminated. (Restart; runvdr). > > With a proper runvdr script, VDR should restart instantly. VDR detected > that there was no data received for the recording, and signals by error > level that the runvdr script should reload the DVB drivers and then > restart VDR, in hope that the restart of the drivers fixes the reception > issue. yes, and no ... thing is, this is something which annoys me for some time now, and maybe I dig into it to find a better solution ... for some reason channel A fails because of a thunderstorm or a covered lnc (think bird) or one of several DVB cards have a problem with the reception (cable unplugged, wrong diseqc commands issued or whatever), which leads to a vdr which is restarting every 10-15 seconds, and all other receptions will be affected ... IMHO that should be handled more gracefully ... best, Herbert > Cheers, > > Udo > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR prefers my CI DVB device for recordings and blocks it unnecessarily
On Sat, Aug 05, 2006 at 02:52:30PM +0200, Jörn Reder wrote: > > Hiho, > > I'm a happy VDR user for years and recently installed a common interface > to receive pay TV. > > I'm having problems with VDR's decision of recording devices. The 1.4 > change log states that budget cards are preferred, unfortunately my > budget card has the CI. So when a recording starts and no pay TV channel > is actually tuned, the CI device is blocked and I can't switch to a pay > TV channel anymore (whithout stopping the recording). > > Is it possible to tell VDR to prefer my FF card for recordings instead > of my CI budget device? yep, just adjust the priority calculations in device.c so that the full featured card wins over the budget one (or even better, add a new check for CI ...) imp <<= 1; imp |= device[i]->HasDecoder(); HTH, Herbert > Regards, > > Joern > > -- > .''`. Jörn Reder <[EMAIL PROTECTED]> > : :' : http://www.exit1.org/ http://www.zyn.de/ > `. `' > `-Debian GNU/Linux -- The power of freedom > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr suggestions & osd colour oddity
On Fri, Aug 04, 2006 at 04:26:19PM +0100, Chris Elsworth wrote: > On Fri, Aug 04, 2006 at 04:07:18PM +0200, Udo Richter wrote: > > Chris Elsworth wrote: > > >When viewing a channel, pressing Up/Down currently changes channel; > > >would it be possible to allow these buttons to just show channel > > >information (with now/next in) for the previous/next channels, > > >allowing one to quickly view what is on the other channels? > > > > Why don't you use the schedule from main menu for it? There's a now/next > > display mode for that. You can also switch channels from there. > > Hello Udo, > > Hm yes, that will actually do the job. I guess the only reason I ask > for the above is that I'm used to it, and found it a fairly nice way > of channel hopping (I'm migratin from Sky in the UK). > > > > >I think it would also be nice if there were more than one > > >rewind/fastforward speed, achievable by repeated pressing of the > > >appropriate button; press ff once to ff at 2x speed, again for 4x > > >speed, again for 8x speed? > > > > Setup -> Replay -> Multi speed mode > > Perfect! Don't know how I missed that one, you added it when I wasn't > looking ;) Much appreciated, thanks very much. That does exactly what > I want. > > So my only issue to sort is the miscoloured OSD now. It turns a > beautiful shade of pink when the problem occurs on my setup :) try to manually set the HUE to 0 or 100 instead of the default 50, we had (and solved?) this problem some time ago .. HTH, Herbert > thanks Udo, > -- > Chris > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] ExtRecMenu-Plugin 0.12a
On Tue, Jun 20, 2006 at 11:36:34PM +0200, Martin Prochnow wrote: > Hi folks, > > here a new version because of two critical bugs. > > - there should be no more problems if VDR is compiled with VFAT=1 or if > it runs with the option --vfat > - fixed a bug if plugin is compiled with WITHPINPLUGIN=1 > > Screenshots and download: > http://martins-kabuff.de/extrecmenu_en.html hey Martin! just a quick question: I had some problems with VDR + ExtRecmenu when I tried to move recordings across mountpoints (with the rename option), which gave the stranges results ... also I had to 'fake' an empty recording to allow for empty dirs to show up at all ... is that fixed (read: was this feature added lately) or is that still an issue? TIA, Herbert > Greets, > Martin > > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Re: [Softdevice-devel] [ANNOUNCE] vdr-softdevice-0.3.0
On Mon, Oct 09, 2006 at 01:25:18AM +0200, Stefan Lucke wrote: > Hello, > > the softdevice team (Torgeir Veimo, Martin Wache and me, Stefan Lucke) > is pleased to announce a new release of vdr's softdevice plugin. > > General info: > Softdevice plugin enables vdr to run on your desktop with > so called budget cards. You'll get vdr output via framebuffer or X11-Xv or > DirectFB or vidix to your screen. Decoding is done via ffmpeg. > > Supported vdr versions: (1.2.x,) 1.3.x and 1.4.x segfaults here (100% reproducible) with or without alpha blending (i.e. pseudo and software). the only difference is the backtrace (CopyPicBuf vs *AlphaBlend) # ./vdr -D1 -c/opt/CONFIG-1/ -P"softdevice -vo xv:" [softdevice] processing args [softdevice] argv [0] = softdevice [softdevice] argv [1] = -vo vo_argv: xv: [setup-softdevice] alsa ac3Mode set to: 0 [setup-softdevice] alsa AC3 device set to: hw:0,1 [setup-softdevice] alsa device set to: default [setup-softdevice] A/V Offset set to (0) [setup-softdevice] Cropping 2 lines from bottom [setup-softdevice] Cropping 2 columns from left [setup-softdevice] cropping mode set to 0 (none) [setup-softdevice] cropping mode toggle key set to 0 (none) [setup-softdevice] Cropping 2 columns from right [setup-softdevice] Cropping 2 lines from top [setup-softdevice] deinterlace method set to 1 lavc [setup-softdevice] mainMenu: 1 [setup-softdevice] setting alpha blend mode to software [softdevice] picture mirroring set to 0 (off) [setup-softdevice] pixel format set to (YUY2) [setup-softdevice] shouldSuspend to: 0 [setup-softdevice] syncTimerMode: sig [softdevice] UseStretchBlitset to on [setup-softdevice] vidBrightness: 50 [setup-softdevice] vidContrast: 50 [setup-softdevice] vidHue: 0 [setup-softdevice] vidSaturation: 50 [setup-softdevice] startup aspect set to (4:3 normal) [softdevice] initializing Plugin [softdevice] Initializing Video Out [softdevice] ffmpeg build(3345152) [XvVideoOut]: osd_image shmid = 24051722 [XvVideoOut]: got osd_image: width 1600 height 1200, bytes per line 3200 [XvVideoOut]: max area size 2046 x 2046 [XvVideoOut]: using area size 736 x 576 [softdevice] Subplugin successfully opend [softdevice] Video Out seems to be OK [softdevice] Initializing Audio Out [softdevice] Audio out seems to be OK [softdevice] A/V devices initialized, now initializing MPEG2 Decoder DeinitXv [XvVideoOut]: max area size 2046 x 2046 [XvVideoOut]: using area size 736 x 576 vout_pic[2304]:CopyPicBufAlphaBlend_YUV420P_YUY2 width 736 height 576 Segmentation fault (core dumped) with the following backtrace #0 yv12_to_yuy2_il_mmx2_line (dest1=0xb4723a34 "\020\200\020\200\020\200\020\200\020", dest2=0xb4723ff4 "\020\200\020\200\020\200\020\200", chromaWidth=368, yc1=0xb6103ef8 '\020' ..., yc2=0xb61041d8 "\020\020\020\020", uc=0xb6103a9c "\200\200", vc=0xb61037ac "\200\200") at utils.c:133 133 movntq(mm6,*(dest2 + 8)); (gdb) where #0 yv12_to_yuy2_il_mmx2_line (dest1=0xb4723a34 "\020\200\020\200\020\200\020\200\020", dest2=0xb4723ff4 "\020\200\020\200\020\200\020\200", chromaWidth=368, yc1=0xb6103ef8 '\020' ..., yc2=0xb61041d8 "\020\020\020\020", uc=0xb6103a9c "\200\200", vc=0xb61037ac "\200\200") at utils.c:133 #1 0xb675503a in CopyPicBufAlphaBlend_YUV420P_YUY2 (dst=0x8383ce8, src=0xb61043c0, width=736, height=576, OsdPy=0xb65ca008 '\020' ..., OsdPu=0x8bc6338 '\200' ..., OsdPv=0x8be0148 '\200' ..., OsdPAlphaY=0xb6562008 "", OsdPAlphaUV=0x8bf9f58 "", OsdStride=736, cutTop=2, cutBottom=2, cutLeft=2, cutRight=2) at PicBuffer.c:570 #2 0xb6755591 in CopyPicBufAlphaBlend (dst=0x8383ce8, src=0xb61043c0, OsdPy=0xb65ca008 '\020' ..., OsdPu=0x8bc6338 '\200' ..., OsdPv=0x8be0148 '\200' ..., OsdPAlphaY=0xb6562008 "", OsdPAlphaUV=0x8bf9f58 "", OsdStride=736, cutTop=2, cutBottom=2, cutLeft=2, cutRight=2) at PicBuffer.c:700 #3 0xb6752874 in cXvVideoOut::YUV (this=0x8383680, buf=0xb61043c0) at video-xv.c:1820 #4 0xb674e1c9 in cVideoOut::DrawStill_420pl (this=0x8383680, buf=0xb61043c0) at video.c:468 #5 0xb674d79a in cVideoOut::Action (this=0x8383680) at video.c:133 #6 0x080ea83a in cThread::StartThread (Thread=0x8383adc) at thread.c:244 #7 0xb7f37c40 in start_thread () from /lib/tls/libpthread.so.0 #8 0xb7dbb0ee in clone () from /lib/tls/libc.so.6 note: the softdevice-cvs20060623 version I used before works perfectly fine in the same vdr/setup (although I h ad to #define the FFMPEG_VERSION to make it work) any ideas? TIA, Herbert > Plugin's homepage is located at: http://softdevice.berlios.de/ > > Special hint: > For cle266 hardware decoding support via DirectFB, you'll need a fresh > version from todays DirectFB's cvs. > Further you'll need libcle266mpegdec which is available from: >http://sourceforge.net/projects/cle266mpegdec/ > > Changelog since last release: > 2006-10-09: softdevice-0.3.0 > 2006-10-03: >- fix hang after long pause. > 2006-10-01: >- enable cropping for video-shm. >- Remove some unneeded c
Re: [vdr] next developper version
On Fri, Aug 11, 2006 at 10:13:22PM +0200, Klaus Schmidinger wrote: > Udo Richter wrote: > >VDR User wrote: > >>Klaus, any particular reason you're not releasing the TODO list? > > > >Probably to keep expectations down. If feature X is on the todo list, > >then it might be implemented next week. Or next month. Or next year. Or > >in 5 years. Or never. > >But people will for sure ask every week 'when will feature X be > >ready?'... ;) > > That pretty much sums it up ;-) > > I simply want to have the freedom to work on whatever seems like > fun at any given time. With a public TODO list we would end up > discussing when which feature will come and why this one is > more important than that one... well, I think that is one of your freedoms as free software developer, to decide what you do with your time, and if somebody disagrees with your priorities (which will for sure happen, sooner or later) that person can go ahead and implement that feature in a personal tree and submit it for inclusion ... I don't think that a public TODO list would change that, nor the expectations folks have, it would just give an idea what _you_ personally consider interesting areas to work on. but if you think that such a list would restrict your 'freedom' in working on whatever seems like fun to you, I'm perfectly fine with that too ... have fun! Herbert > Klaus > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
