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 ML10000 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
On Saturday 15 October 2011 10:04:49 Nicolas Huillard wrote:
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 ML10000 client which ended up on the same shelf + another still-used client).
I have two issues with this setup :
- 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.
I use a hand-crafted soltution for this purpose. My system does not use a display manager. Instead, I use "mingetty --autologin tv" to automatically log into a text console with a user named "tv". tv's .bashrc then fires up irexec which comes with lirc. irexec is configured in a way that it waits for a particular button on the remote control (one that does not conflict with VDR) to be pressed, then runs startx. startx uses the .xinitrc config file. There I start up a compositing window manager like compiz, followed by vdr-sxfe.
Now you can watch TV.
To finally suspend the output, I *somehow* configured vdr-sxfe to quit when a remote control button is pressed (a different one than the one that starts X). I guess it was similar to this solution: http://mms.mymediasystem.net/index-7.html I can look this up when I have physical access to my VDR next time (by the end of the week).
Long story short, what you get is the following: Your system boots into a slick text console, waits for button A to be pressed. This fires up X and vdr-sxfe. When you press button B, vdr-sxfe quits, so does X. You get back to your text console, waiting for button A to be pressed.
You can easily modify this solution in a way that X is started automatically on boot (i.e. with nodm) and keeps running all the time.
HTH, Stefan
-
Nicolas Huillard -
Stefan Bauer