Ok, trying again with recompiled xine-lib from hg as of current (http://anonscm.debian.org/hg/xine-lib/xine-lib-1.2/) root@raspberrypi:/usr/local/src/vdr-2.2.0/PLUGINS/src/xineliboutput# ./vdr-fbfe -V rpi -f xvdr+tcp://192.168.1.100 vdr-fbfe 2.0.0-cvs (build with xine-lib 1.2.6, using xine-lib 1.2.6) Video driver: rpi Fullscreen mode VDR Server: xvdr+tcp://192.168.1.100 [2289] [vdr-fbfe] fbfe_display_open: failed to set /dev/tty to graphics mode [2289] [vdr-fbfe] (ERROR (xine_fbfe_frontend.c,178): Inappropriate ioctl for device) [2289] [vdr-fe] fe_xine_init: xine_open_video_driver("rpi") failed Error initializing xine Available video drivers: aadxr3 mmal dxr3 raw xshm none fb Available audio drivers: oss none file [2289] [vdr-fbfe] fbfe_display_close: failed to set /dev/tty to text mode [2289] [vdr-fbfe] (ERROR (xine_fbfe_frontend.c,253): Inappropriate ioctl for device) root@raspberrypi:/usr/local/src/vdr-2.2.0/PLUGINS/src/xineliboutput# Did I just forget some switches when configuring xine-lib, or do I need a new kernel? root@raspberrypi:/usr/local/src/vdr-2.2.0/PLUGINS/src/xineliboutput# uname -a Linux raspberrypi 3.18.11-v7+ #781 SMP PREEMPT Tue Apr 21 18:07:59 BST 2015 armv7l GNU/Linux On 12 May 2015 at 16:58, Petri Hintukainen <phintuka@xxxxxxxxxxxxxxxxxxxxx> wrote: > On ti, 2015-05-12 at 16:40 +1000, Torgeir Veimo wrote: >> I just tried vdr-fbfe compiled from CVS on the RPI, and there's still >> that judder when pressing keys when the OSD menu is showing. Is this >> possible to remedy somehow? This was one of the issues that made me >> switch to softhddevice a few years ago. > > I haven't noticed this. > > Did you compile xine-lib from hg or are you using some older version ? > RPi HW OSD support is not in xine-lib 1.2.6. > > Do you run also VDR in RPi ? Maybe it uses too much resources when > rendering OSD ? > > Also, I have mpeg2 decoding key. It makes SD smoother ... > >> On 21 April 2015 at 23:36, Harald Milz <hm@xxxxxxxxxxxxx> wrote: >> > On Tue, Apr 21, 2015 at 12:41:57PM +0300, Petri Hintukainen wrote: >> >> Do you mean setting the marks (and letting remote VDR to do the actual >> >> editing) ? Or using VDR in RPi to cut recordings ? Cutting with RPi is >> >> probably very slow and consumes lot of limited I/O resources. >> >> >> >> For setting editing marks - probably, I'm not sure. I rarely edit >> > >> > Yes sure. With vdr-{sxfe,fbfe} you get a remote OSD from the server VDR, i.e. >> > you work on the server, not the RPi. No data is transferred over the net >> > except the OSD when cutting. >> > >> >> Latency with 100Mbit/s ethernet is not noticeable. It can be even faster >> > >> > For SD 100 MBit is fine. For HD it should be okay also. As far as Wifi, 54 >> > MBit is okay-ish for SD but better go for 300 on 5 GHz (to make sure the >> > wifi is near-exclusively used for the VDR link). >> > >> >> One possible source of problems is audio decoding performance. I'm not >> >> EAC3 ?). AC3 decoding uses ~ half of RPi CPU time. Here the additional >> >> CPU power of RPi 2 would be useful. >> > >> > Better use HDMI pass-through and have the AC3 receiver decode the stream. The Pi >> > has only a 2.0 analog output anyway, so there's little point in decoding on >> > the Pi. >> > >> > >> > -- >> > You will be traveling and coming into a fortune. >> > >> > _______________________________________________ >> > vdr mailing list >> > vdr@xxxxxxxxxxx >> > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr >> >> >> > > > > _______________________________________________ > vdr mailing list > vdr@xxxxxxxxxxx > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- -Tor _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
