[vdr] xineliboutput suspend + OSD HUD on SandyBridge
Hi, I have a new VDR+ server system, based on SandyBridge i3 CPU. This server is located under the TV set, thus mixes the server (always-on headless) + client (HD display) roles (previous setup was a Via EK8000 server + Via ML1 client which ended up on the same shelf + another still-used client). I have two issues with this setup : 1) I don't know the best way to suspend the output of xineliboutput (vdr-sxfe loaded within nodm which auto-reloads it upon crash) : the xineliboutput README refers to the suspendoutput plugin (http://phivdr.dyndns.org/vdr/vdr-suspendoutput/) which last release is dated 12-Feb-2009. Since I use the e-tobi repository (marvellous, many thanks Tobias), which does not include it, I wonder if there is a better way to suspend the video decoding output. 2) the HUD OSD display works with --hud=xshape, but each OSD refresh (changing time, recording location) removes the previous OSD, replacing it with only the changed portion. --hud=opengl crashes vdr-sxfe because OpenGL is probably not quite ready with SandyBridge. OSD without HUD works, but is obviously ugly on the 1920x1080 display. I pulled xineliboutput 1.0.7+cvs20110918.1632-1 from e-tobi : maybe this CVS version is right in the middle of some change ? Other versions (all binaries from e-tobi) : vdr 1.7.21-1~ctvdr1 vdr-plugin-femon 1.7.10-4 vdr-plugin-live 0.2.0-15 vdr-plugin-skinsoppalusikka 1.7.4-1 vdr-plugin-streamdev-server 0.5.1-4 vdr-plugin-xineliboutput1.0.7+cvs20110918.1632-1 Core i3 video-related, from Debian backports : linux-image-2.6.39-bpo.2-amd64 2.6.39-3~bpo60+1 libdrm-intel1 2.4.26-1~bpo60+1 libgl1-mesa-dri 7.10.3-4~bpo60+1 xserver-xorg 1:7.6+8~bpo60+1 xserver-xorg-core 2:1.10.4-1~bpo60+1 xserver-xorg-video-intel 2:2.15.0-3~bpo60+1 -- NH ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] timerconflict handling between VPS events
hi list I noticed vdr 1.7.16 does handle timer conflicts differently if one of two conflicting timers is a VPS event. Take for example two timers: timer #1 1623-1707 with timer priority 48 timer #2 1655-1736 with timer priority 52 If both timers are *NOT* VPS events vdr does follow the timer priority, thus the change from timer #1 to timer #2 will happen @16:55 precisely. Now try the same with timer #2 set up as a VPS event (VPS margin two minutes, VPS time is correct) As expected I do have the following line in syslog @16:53: timer 2 (1655-1736 VPS) entered VPS margin ... but the change does not happen before 17:07 - can somebody explain to me why? I expected a VPS timer with higher priority would change channel @VPS margin and wait for the event to happen. Can this be implemented, or are there concerns about this sort of timer handling? Regards, Lou ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] timerconflict handling between VPS events
On 15.10.2011 17:21, Tuxoholic wrote: hi list I noticed vdr 1.7.16 does handle timer conflicts differently if one of two conflicting timers is a VPS event. Take for example two timers: timer #1 1623-1707 with timer priority 48 timer #2 1655-1736 with timer priority 52 If both timers are *NOT* VPS events vdr does follow the timer priority, thus the change from timer #1 to timer #2 will happen @16:55 precisely. Now try the same with timer #2 set up as a VPS event (VPS margin two minutes, VPS time is correct) As expected I do have the following line in syslog @16:53: timer 2 (1655-1736 VPS) entered VPS margin ... but the change does not happen before 17:07 - can somebody explain to me why? I expected a VPS timer with higher priority would change channel @VPS margin and wait for the event to happen. Can this be implemented, or are there concerns about this sort of timer handling? This is a known poblem and I'll look into it after I have implemented the LNB sharing. The problem is that a VPS timer needs a device to be tuned to the channel it shall record, in order to be able to observe the running status of the event. As it is now, it does so only if there is a device that is currently not recording. I guess a fix will be to have VDR force the device with the lowest priority into tuning to that channel, at the cost of interrupting an ongoing recording. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] What are recommended versions for a dxr3 setup ?
Hi, Is there a way to use dxr3 plugin with experimental e-tobi packages for debian squeeze ? i suppose i need to compile dxr3 plugin because it is not in the e-tobi repository. But how can i do this compilation ? Thank you Guy Le 11/10/2011 19:20, Mikko Tuumanen a écrit : I got a dvb card, installed it in my vdr box and it didn't work. So I decided to compile the driver, but alas, I had accidentially deleted the kernel compile tree. So it seems it's time to upgrade everyting: kernel, vdr, dxr3 driver and dxr3plugin. But what are the recommended versions at the moment? What is the latest kernel that dxr3 driver works on? And where should get the dxr3 driver from? Is the vdr-dxr3-0.2.12 in vdr-developer.org the latest and greatest version of the plugin or should I pull from git or hg somewhere? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
