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
<phint...@users.sourceforge.net> 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 <h...@seneca.muc.de> 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@linuxtv.org
>> > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>
>>
>>
>
>
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
--
-Tor
_______________________________________________
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
