[vdr] Can't get lock on BBC news
Hi, freesat: Can't get a lock on BBC News 24 since yesterday is it just me? I have also lost the channel 4 group of channels although femon reports lock. Have these channels changed their transponder (again)? Cheers Tony -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] multiproto_plus is ancient
VDR User wrote: On Thu, Jul 10, 2008 at 4:13 AM, Lauri Tischler [EMAIL PROTECTED] wrote: What 'FF mod card' are you referring to ? There's a hardware hack to allow the full transport stream to be passed by the Nexus. By default it doesn't so when there's heavy load, a lot of packets are dropped. I have basic Hauppauge NEXUS-S FF card and a pair of Hauppauge NOVA-T cards, in near future I will get some S2 capable card. So, what tree should I use for VDR 1.7.xx ? For a stock Nexus-s, you can use any tree. V4L with the vdr api wrapper patch, or *multiproto*. Hmmm.. compile error CC [M] /usr/src/multiproto/v4l/em28xx-audio.o In file included from /usr/src/multiproto/v4l/em28xx-audio.c:39: include/sound/core.h:281: error: 'SNDRV_CARDS' undeclared here (not in a function) /usr/src/multiproto/v4l/em28xx-audio.c:58: error: array index in initializer not of integer type /usr/src/multiproto/v4l/em28xx-audio.c:58: error: (near initialization for 'index') make[3]: *** [/usr/src/multiproto/v4l/em28xx-audio.o] Error 1 make[2]: *** [_module_/usr/src/multiproto/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-2.6.24-19-generic' make[1]: *** [default] Error 2 make[1]: Leaving directory `/usr/src/multiproto/v4l' ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] multiproto_plus is ancient
Lauri Tischler wrote: VDR User wrote: On Thu, Jul 10, 2008 at 4:13 AM, Lauri Tischler [EMAIL PROTECTED] wrote: What 'FF mod card' are you referring to ? There's a hardware hack to allow the full transport stream to be passed by the Nexus. By default it doesn't so when there's heavy load, a lot of packets are dropped. I have basic Hauppauge NEXUS-S FF card and a pair of Hauppauge NOVA-T cards, in near future I will get some S2 capable card. So, what tree should I use for VDR 1.7.xx ? For a stock Nexus-s, you can use any tree. V4L with the vdr api wrapper patch, or *multiproto*. Hmmm.. compile error CC [M] /usr/src/multiproto/v4l/em28xx-audio.o In file included from /usr/src/multiproto/v4l/em28xx-audio.c:39: include/sound/core.h:281: error: 'SNDRV_CARDS' undeclared here (not in a function) /usr/src/multiproto/v4l/em28xx-audio.c:58: error: array index in initializer not of integer type /usr/src/multiproto/v4l/em28xx-audio.c:58: error: (near initialization for 'index') make[3]: *** [/usr/src/multiproto/v4l/em28xx-audio.o] Error 1 make[2]: *** [_module_/usr/src/multiproto/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-2.6.24-19-generic' make[1]: *** [default] Error 2 make[1]: Leaving directory `/usr/src/multiproto/v4l' otoh the v4l-dvb tree compiles just fine but multiproto does not. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] multiproto_plus is ancient
Hi, On Fri, Jul 11, 2008 at 01:14:56PM +0300, Lauri Tischler wrote: VDR User wrote: On Thu, Jul 10, 2008 at 4:13 AM, Lauri Tischler [EMAIL PROTECTED] wrote: What 'FF mod card' are you referring to ? There's a hardware hack to allow the full transport stream to be passed by the Nexus. By default it doesn't so when there's heavy load, a lot of packets are dropped. I have basic Hauppauge NEXUS-S FF card and a pair of Hauppauge NOVA-T cards, in near future I will get some S2 capable card. So, what tree should I use for VDR 1.7.xx ? For a stock Nexus-s, you can use any tree. V4L with the vdr api wrapper patch, or *multiproto*. Hmmm.. compile error CC [M] /usr/src/multiproto/v4l/em28xx-audio.o In file included from /usr/src/multiproto/v4l/em28xx-audio.c:39: include/sound/core.h:281: error: 'SNDRV_CARDS' undeclared here (not in a function) /usr/src/multiproto/v4l/em28xx-audio.c:58: error: array index in initializer not of integer type /usr/src/multiproto/v4l/em28xx-audio.c:58: error: (near initialization for 'index') make[3]: *** [/usr/src/multiproto/v4l/em28xx-audio.o] Error 1 make[2]: *** [_module_/usr/src/multiproto/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-2.6.24-19-generic' make[1]: *** [default] Error 2 make[1]: Leaving directory `/usr/src/multiproto/v4l' You need this patch: http://linuxtv.org/hg/v4l-dvb/raw-diff/b0815101889d/v4l/compat.h Please take a look at http://www.linuxtv.org/pipermail/linux-dvb/2008-February/023819.html Maybe the patch should be directly merged into the multiproto tree... Regards, Artem -- Artem Makhutov Unterort Str. 36 D-65760 Eschborn ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Control VDR with RF remote
Hi, Does anybody use RF remote control with VDR instead of IR? How to configure such remotes? Thanks in advance. -- Cheers, Michael ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Vdr-xine OSD question
I am running vdr + vdr-xine plugin + coreavc + xine being output at 1080i to an HDTV as the only display. Is there a simple way to lock the OSD to the resolution of the output device such that the OSD is not rescaled when switching between SD and HD sources? I played with X-overlay, but that was not what I was after. If not, could it be done in the source somewhere or is the OSD anti-aliased and overlayed on the video before being sent to the output device (xine, in my case)? I've looked around quite a bit on the net but I guess my google-foo is failing me on this one. I just miss the rock-solid OSD of the FF card setup... Thanks! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vdr-xine OSD question
2008/7/11 Todd Luliak [EMAIL PROTECTED]: I am running vdr + vdr-xine plugin + coreavc + xine being output at 1080i to an HDTV as the only display. Is there a simple way to lock the OSD to the resolution of the output device such that the OSD is not rescaled when switching between SD and HD sources? I played with X-overlay, but that was not what I was after. If not, could it be done in the source somewhere or is the OSD anti-aliased and overlayed on the video before being sent to the output device (xine, in my case)? I've looked around quite a bit on the net but I guess my google-foo is failing me on this one. I just miss the rock-solid OSD of the FF card setup... Thanks! In an effort to create something to solve such issues with xineliboutput plugin I came up with an idea of this HUD type OSD. Basically it means that OSD is rendered to a separate transparent surface on top of video and then these are blended together by the display hardware. This way the size of the OSD is bound to the size of the used window rather than the size of the video stream. In other words no OSD scaling will be necessary even though the video size changes. The HUD implementation has been integrated into the CVS of xineliboutput plugin. To operate it requires support for xorg render extension and presence of composite display manager such as xcompmgr. It also requires powerful display adapter and drivers with support for these modern extensions. Maybe you can try it to see if it produces results that you are hoping for? Regards, -- Antti Seppälä [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
