Re: [vdr] xinelibout --hud + xcompmgr = tearing
Alex Betis wrote: I gave the nice xinelibout hud another try, but have to revert back since running composite manager creates tearing while watching movies. I've tries with xcompmgr with -n option. Does anybody know how to fix that? Or maybe there is another lightweight composite manager available? Without xcompmgr running there is no tearing at all. This is a known limitation of (at least) the NVidia drivers. Quoting the NVidia README: --snip-- The Composite extension also causes problems with other driver components: [...] On X.Org 7.1 and higher, the driver will properly redirect video into offscreen pixmaps. Note that the Xv adaptors will ignore the sync-to-vblank option when drawing into a redirected window. --snip-- Regards, Jörn -- Joern Reder - http://www.exit1.org/ - http://search.cpan.org/~jred/ pgpld7NvxNdFN.pgp Description: PGP signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Regression from a fix in VDR 1.4.1: Needless blocking of CAM DVB cards
Udo Richter wrote: I've attached a debug patch for impact logging. It dumps the reasons why VDR used a certain device to the console. (replace printf with isyslog if you prefer the log files.) [...] Thanks for this patch, but I don't know when I can test it. I downgraded my production vdr to 1.4, because I had more critical issues with 1.6 regarding pay TV. With vdr 1.6 I often lost my CAM card completely being unable to receive encrypted channels at all, even when no recording was started. I have no idea which conditions led to this. A vdr restart solved it temporarily, but programming pay TV timers was a lottery and the woman acceptance factor fell down to 0.0 (but my AF as well... :) So I need to compile a vanilla 1.6 to run besides my production 1.4. Probably I find some time to do this around x-mas. I'll post the results. Regards, Jörn -- .''`. Jörn Reder jo...@zyn.de : :' : http://www.exit1.org/ `. `' `-Debian GNU/Linux -- The power of freedom pgp53ib9i6boq.pgp Description: PGP signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Regression from a fix in VDR 1.4.1: Needless blocking of CAM DVB cards
Udo Richter wrote: Jörn Reder wrote: With vdr 1.4 this worked perfectly, now with 1.6 VDR always prefers my Budget CI card for recordings so I can't view any Pay TV when a recording is active. The rules that were added with 1.4.1-4 are still present, so they probably got over-ruled by something else. Ok - thanks for checking this that quickly ;) Can you confirm that this problem occurs without loading any plugins? At least osdteletext is known to cause channels to be blocked. Yes. I just tested it with a plain VDR without any plugins loaded. I can reproduce it this way: - watching a non pay TV channel (e.g. ARD) - manually start a recording on it (go to menu, hit RED button) - now switching to a pay TV channel is impossible In that case with vdr 1.4 I could see that vdr switched the card when starting the non pay TV recording (short black screen). Now the live viewing isn't interrupted, which is nice, but keeping the CAM card free is more important in my opinion ;) Thanks, Jörn -- .''`. Jörn Reder [EMAIL PROTECTED] : :' : http://www.exit1.org/ `. `' `-Debian GNU/Linux -- The power of freedom pgpkv0qBxg37d.pgp Description: PGP signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] S2API for vdr-1.7.0(1.7.1) quick hack
What's the sense of this quoting garbage? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Trouble with mplayer plugin / audio
Hiho,
I'm using vdr 1.4.7 and mplayer plugin from e-tobi on Debian Etch with a
full featured Hauppauge Nexus-S card and having trouble with audio
during video playback.
When I configure mplayer to decode audio with the Nexus by setting
AO=mpegpes:card=1
in /etc/vdr/plugins/vdrmplayer.sh.conf, movie playback doesn't work at
all. I get a black screen, TV audio mutes but movie playback doesn't
start. The mplayer process is there, but seems to do nothing:
/usr/bin/mplayer -vo mpegpes:card=1 -ao mpegpes:card=1 \
-vf scale=704:331,expand=704:576:-1:-1:1,lavc=5000:25 \
-framedrop -cache-min 10 -slave -nolirc -subpos 80 \
-sub-bg-color 0 -sub-bg-alpha 30 -quiet -osdlevel 0 \
/movies/foo.avi
When I press Exit (a few times) on my remote, vdr resumes to TV
playback, but often I need to restart vdr for proper operation.
Otherwise I can't tune all channels resp. I'm getting messages of
channels not available.
I stopped vdr and tried the command line above (only removed -slave
option): this works pretty well. I get proper video and audio playback.
For me it seems, that vdr still occupies the DVB (audio) device when the
plugin starts mplayer for video playback. Is that possible?
I tried playing audio via the onboard soundchip by setting
AO=alsa
and this works so far. But audio and video are getting seriously out of
sync, so this is no reasonable workaround for the problem (besides that
switching my amplifier to the other audio line is somewhat annoying ;)
Something I'm doing wrong?
Any help is appreciated. If you need more configuration information
please ask for it.
Thanks,
Jörn
--
sub i($){print$_[0]}*j=*ENV;sub w($){sleep$_[0]}sub _($){i$p:$c ,w+01
,$_=$_[0],tr;i-za-h,;a-hi-z ;,i$_,w+01,i\n}$|=1;$f='HO';($c=$j{PWD})=~
s+$j{$f.ME}+~+;$p.=$j{USER}\@.`hostname`;chop$p;_kl,$c='~',_zu,.
-zn,*,_#,epg,lw,gwc,mfmkcbm,cvsvwev,uiqt,kwvbmvb?,i$p:$c ;w+107
pgphTbSU9trfq.pgp
Description: PGP signature
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Trouble with mplayer plugin / audio
Jörn Reder wrote: I'm using vdr 1.4.7 and mplayer plugin from e-tobi on Debian Etch with a full featured Hauppauge Nexus-S card and having trouble with audio during video playback. I missed posting exact version numbers: vdr 1.4.7-4ctvdr1 vdr-plugin-mplayer 0.10.1-6 mplayer 1.0-rc1svn20070225-0.3etch1 Kernel 2.6.18-5-k7 Hmm, looks mplayer could be more recent, probably I'll try to upgrade it... Regards, Jörn -- LINUX - Linux Is Not gnU linuX pgpmgSKMD3vKj.pgp Description: PGP signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Re: VDR prefers my CI DVB device for recordings and blocks it unnecessarily
Udo Richter wrote: It makes no sense that a CAM budget card is always used to record a free channel, which makes it impossible to view and/or record encrypted channels at the same time. A CAM is a valuable resource, wasting it is obviously a bad idea. What if the FF card is the only one with the CAM? Doesn't matter. If a CAM is not needed for a particular recording, than any card not having a CAM should be preferred, regardless whether it's a budget or FF card. Regards, Joern -- Think before you code. And while you're doing it probably won't hurt. ;) pgptQFOSppTSN.pgp Description: PGP signature ___ 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
Klaus Schmidinger wrote: Please try the attached patch. With this change avoiding full featured or primary cards gets less priority than using the device with the lowest priority or the lowest number of CA methods. Thanks for your patch, I played around with it. The ActualDevice() test has a very high priority, so if I start a recording on the fly, my CI device is still preferred. For testing purposes I commented out the ActualDevice() test, then your patch worked for me. I don't understand the device[i]-ProvidesCa(Channel) test, because it checks for the currently requested channel. I dunno any internals (so please be patient with me ;), but from reading the source code it looks that the first if condition in the device loop device[i]-ProvidesChannel(Channel, Priority, ndr) already checks if the device is basically capable of decoding the requested channel, this must include a test for decryption capability (if the channel is encrypted), not?. So why another ProvidesCA() test? All devices in this if block should pass it anyway. What about adding a high priority test like hasCAM() (ideally with weighting the number of channels the device is able to decrypt) to avoid blocking a CA device unnecessarily? Regards, Joern -- Think before you code. And while you're doing it probably won't hurt. ;) pgpxSLFyR2XzM.pgp Description: PGP signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
