Hi list,
I'm planning to update my infrastructure according to the follow scheme:
http://filter-failure.eu/wp-content/uploads/2015/01/vdr-new-backend.png
The red texts are things where I'm unsure about. Especially the usage of vdr-sxfe on the RPI. I made this chart before finding out that there is rpihddevice and a recommended streamdev-usage.
This shows that I have a need for streamdev and xineliboutput (as others on this list).
Is there problem with running the xineliboutput and streamdev-server plugins at the same time on a vdr-host?
When will we start facing problems using the xineliboutput-plugin with VDR? What is most likely to break first in this case?
Thanks for any comments, -- Patrick.
On pe, 2015-04-17 at 09:25 +0200, Patrick Boettcher wrote:
Hi list,
I'm planning to update my infrastructure according to the follow scheme:
http://filter-failure.eu/wp-content/uploads/2015/01/vdr-new-backend.png
The red texts are things where I'm unsure about. Especially the usage of vdr-sxfe on the RPI.
I've been using xineliboutput (vdr-fbfe) with RPi for ~ year without problems. Hardware decoding and OSD work well with recent xine-lib.
With RPi you want to use vdr-fbfe (not vdr-sxfe). RPi HW video decoding and video output work just well without X11. Faster startup, less stuff to configure and install.
I've also used TV's remote controller to control VDR (vdr-fbfe supports HDMI-CEC with RPi).
This all makes RPi quite nice VDR client; it is small, silent and requires only two or three cables (power, HDMI, optional wired network).
I made this chart before finding out that there is rpihddevice and a recommended streamdev-usage.
This shows that I have a need for streamdev and xineliboutput (as others on this list).
Is there problem with running the xineliboutput and streamdev-server plugins at the same time on a vdr-host?
No
When will we start facing problems using the xineliboutput-plugin with VDR? What is most likely to break first in this case?
Thanks for any comments,
Patrick.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Have you tried rpihddevice plugin with VDR on the rpi? It might work even smoother than using xinelinboutput, but you'd have to find a different setup for cec i suppose.
http://projects.vdr-developer.org/git/vdr-plugin-rpihddevice.git/
On 20 April 2015 at 11:25, Petri Hintukainen phi@sdf-eu.org wrote:
On pe, 2015-04-17 at 09:25 +0200, Patrick Boettcher wrote:
Hi list,
I'm planning to update my infrastructure according to the follow scheme:
http://filter-failure.eu/wp-content/uploads/2015/01/vdr-new-backend.png
The red texts are things where I'm unsure about. Especially the usage of vdr-sxfe on the RPI.
I've been using xineliboutput (vdr-fbfe) with RPi for ~ year without problems. Hardware decoding and OSD work well with recent xine-lib.
With RPi you want to use vdr-fbfe (not vdr-sxfe). RPi HW video decoding and video output work just well without X11. Faster startup, less stuff to configure and install.
I've also used TV's remote controller to control VDR (vdr-fbfe supports HDMI-CEC with RPi).
This all makes RPi quite nice VDR client; it is small, silent and requires only two or three cables (power, HDMI, optional wired network).
I made this chart before finding out that there is rpihddevice and a recommended streamdev-usage.
This shows that I have a need for streamdev and xineliboutput (as others on this list).
Is there problem with running the xineliboutput and streamdev-server plugins at the same time on a vdr-host?
No
When will we start facing problems using the xineliboutput-plugin with VDR? What is most likely to break first in this case?
Thanks for any comments,
Patrick.
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
On Mon, 20 Apr 2015 11:33:02 +0200 Torgeir Veimo torgeir.veimo@gmail.com wrote:
Have you tried rpihddevice plugin with VDR on the rpi? It might work even smoother than using xinelinboutput, but you'd have to find a different setup for cec i suppose.
http://projects.vdr-developer.org/git/vdr-plugin-rpihddevice.git/
I think the big difference between rpihddevice and vdr-fbfe is that the vdr-fbfe does not need a local vdr-instance running on the device. vdr-fbfe is connecting over network to a vdr running on a full machine. No need for streamdev.
Thank you both for your input.
regards, -- Patrick.
On Mon, Apr 20, 2015 at 11:40:41AM +0200, Patrick Boettcher wrote:
vdr-fbfe is connecting over network to a vdr running on a full machine. No need for streamdev.
This looks interesting. Am I right assuming that the full machine will not need any video output? Can vdr-fbfe be used for editing recordings on the RPi, or is there too much latency when using 10Mb/s Ethernet to connect to an old VDR server? How many remote controller buttons do you typically get mapped via HDMI-CEC?
How about using vdr-fbfe to connect on a vdr instance running on the same RPi machine? Is it technically possible to for example pause a live SD TV stream and copy some files over the Ethernet at the same time? The single USB bus on the RPi would in that case need to handle the traffic of a hard disk adapter as well as the DVB dongle and the built-in Ethernet controller.
Marko
On Mon, 20 Apr 2015 16:05:45 +0300 Marko Mäkelä marko.makela@iki.fi wrote:
On Mon, Apr 20, 2015 at 11:40:41AM +0200, Patrick Boettcher wrote:
vdr-fbfe is connecting over network to a vdr running on a full machine. No need for streamdev.
This looks interesting. Am I right assuming that the full machine will not need any video output?
Yes, you are right. Vdr is running like a daemon.
Can vdr-fbfe be used for editing recordings on the RPi, or is there too much latency when using 10Mb/s Ethernet to connect to an old VDR server?
I'd not recommend a 10Mb/s. Fast Ethernet (100Mb/s) should be the minimum.
How about using vdr-fbfe to connect on a vdr instance running on the same RPi machine?
Yes.
Is it technically possible to for example pause a live SD TV stream and copy some files over the Ethernet at the same time?
Which scenario? VDR on RPI or on a remote? If VDR on a remote host, IIRC, pausing causes very few bandwidth as only a still image is displayed.
The pause is global to all connected clients to this vdr-remote. Yes, you can connect several clients to one xineliboutput-vdr-host but they will all have the same channel and OSD appearances displayed - IOW, they are not independent.
The single USB bus on the RPi would in that case need to handle the traffic of a hard disk adapter as well as the DVB dongle and the built-in Ethernet controller.
Yes. IMHO, it is better to use RPI only as client with no harddisk.
-- Patrick.
On Mon, Apr 20, 2015 at 03:15:08PM +0200, Patrick Boettcher wrote:
Is it technically possible to for example pause a live SD TV stream and copy some files over the Ethernet at the same time?
Which scenario? VDR on RPI or on a remote? If VDR on a remote host, IIRC, pausing causes very few bandwidth as only a still image is displayed.
VDR client+server on the same RPi. I guess it is simply too much to ask of the poor RPi.
The pause is global to all connected clients to this vdr-remote. Yes, you can connect several clients to one xineliboutput-vdr-host but they will all have the same channel and OSD appearances displayed - IOW, they are not independent.
I see, so it would not be a solution if you wanted to have independent clients connected to the same VDR (watching different recordings, for example).
Yes. IMHO, it is better to use RPI only as client with no harddisk.
It seems that vdr-fbfe could allow an inexpensive and small solution where a generic headless ARM-based NAS box acts as the server, and the RPi (attached on the back side of the TV) acts as the client. I guess that the server could simultaneously serve other clients via other plugins (such as the SmartTVweb plugin).
Marko
Am 20.04.2015 um 15:34 schrieb Marko Mäkelä:
On Mon, Apr 20, 2015 at 03:15:08PM +0200, Patrick Boettcher wrote:
Is it technically possible to for example pause a live SD TV stream and copy some files over the Ethernet at the same time?
Which scenario? VDR on RPI or on a remote? If VDR on a remote host, IIRC, pausing causes very few bandwidth as only a still image is displayed.
VDR client+server on the same RPi. I guess it is simply too much to ask of the poor RPi.
Kodi and vnsi-addon + vdr and vnsi-server-plugin are working on the same RPi, and it is a much heavier load than your setup. I can't see why this shouldn't work.
Gerald
!DSPAM:55352184204551113121336!
On ma, 2015-04-20 at 16:34 +0300, Marko Mäkelä wrote:
On Mon, Apr 20, 2015 at 03:15:08PM +0200, Patrick Boettcher wrote:
The pause is global to all connected clients to this vdr-remote. Yes, you can connect several clients to one xineliboutput-vdr-host but they will all have the same channel and OSD appearances displayed - IOW, they are not independent.
I see, so it would not be a solution if you wanted to have independent clients connected to the same VDR (watching different recordings, for example).
No. For true multi-user you need to run multiple instances of VDR. But you can still run those in the same server.
Yes. IMHO, it is better to use RPI only as client with no harddisk.
It seems that vdr-fbfe could allow an inexpensive and small solution where a generic headless ARM-based NAS box acts as the server, and the RPi (attached on the back side of the TV) acts as the client. I guess that the server could simultaneously serve other clients via other plugins (such as the SmartTVweb plugin).
Marko
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On ma, 2015-04-20 at 16:05 +0300, Marko Mäkelä wrote:
On Mon, Apr 20, 2015 at 11:40:41AM +0200, Patrick Boettcher wrote:
vdr-fbfe is connecting over network to a vdr running on a full machine. No need for streamdev.
This looks interesting. Am I right assuming that the full machine will not need any video output? Can vdr-fbfe be used for editing recordings on the RPi, or is there too much latency when using 10Mb/s Ethernet to connect to an old VDR server?
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 anything, and never with remote controller. When I edit, I do it with vdr-sxfe + keyboard from computer. But I think I've tried it with RPi couple of times and would remember if it was slow or wouldn't work.
Latency with 100Mbit/s ethernet is not noticeable. It can be even faster over network than running VDR in RPi. Overall, in _my_ VDR usage, RPI seems to perform just as well as my earlier dual-core i5. Except that RPi is invisible, silent, supports CEC, boots faster than TV, and HW decoder beats ffmpeg H.264 decoder in stability :).
Also I'm not sure how RPi will perform when fast forwarding HD recordings. This is another feature that I don't use, I skip instead of fast forward/backward.
One possible source of problems is audio decoding performance. I'm not sure if this affects DVB, but with (USB) BluRay I've noticed problems with very high bit rate video + AC3 decoding. But such high bitrates are not likely in DVB. New audio codecs are too much for RPi (DTS-HD, TrueHD - maybe even EAC3 ?). AC3 decoding uses ~ half of RPi CPU time. Here the additional CPU power of RPi 2 would be useful.
How many remote controller buttons do you typically get mapped via HDMI-CEC?
Probably not all VDR buttons. This depends on used TV and selected vdr-fbfe CEC device type. CEC defines more than enough buttons, but TV does not forward all buttons to external devices.
With Panasonic TV I have Menu, Recordings, menu navigation, channel switch, color keys, numbers and playback control keys. There are also some other keys I never use (Subtitle, Schedule, Channels, Timers, Power ?). Those all were mapped automatically, tweaking the settings would probably enable more keys.
I don't even care if all exotic shortcut keys are there; handling everything with single remote controller is so much simpler and makes VDR<->TV integration more seamless. Everything simply works without changing remote or remote controller mode/device/... Just like VDR was built in TV, not a separate feature.
CEC has also some other functions. VDR appears in connected devices menu and TV switches automatically to correct input when RPi is switched on. RPi could also power on/off TV, or the opposite (useless in my case because of RPi gets its power from TV and is switched on/off with TV).
You could probably also map TV volume control to VDR (but usually you want to do the opposite - use TV or AVR to control volume). Also VDR could control TV volume (when separate remote controller is used for VDR), but this is not implemented in vdr-fbfe.
CEC is nice addition even without RPi. Ex. Pulse Eight CEC adapter can be used with vdr-sxfe, but it costs about as much as RPi.
How about using vdr-fbfe to connect on a vdr instance running on the same RPi machine? Is it technically possible to for example pause a live SD TV stream and copy some files over the Ethernet at the same time? The single USB bus on the RPi would in that case need to handle the traffic of a hard disk adapter as well as the DVB dongle and the built-in Ethernet controller.
Probably possible, but slow. And I wouldn't except it to handle lot of parallel recordings either.
- Petri
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.
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.
On 21 April 2015 at 23:36, Harald Milz hm@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
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@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
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@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 hm@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
Seems to work with -V mmal
But I'm still getting judder on OSD update. Does hardware OSD for rpi require more than just current xine-lib? The xinelibplugin on the server side is older, since it's a vanilla yavdr installation, am unsure if that would have an impact on the clients OSD?
On 12 May 2015 at 20:59, Torgeir Veimo torgeir.veimo@gmail.com wrote:
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@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 hm@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
On Mon, Apr 20, 2015 at 11:40:41AM +0200, Patrick Boettcher wrote:
On Mon, 20 Apr 2015 11:33:02 +0200 Torgeir Veimo torgeir.veimo@gmail.com wrote:
Have you tried rpihddevice plugin with VDR on the rpi? It might work even smoother than using xinelinboutput, but you'd have to find a different setup for cec i suppose.
http://projects.vdr-developer.org/git/vdr-plugin-rpihddevice.git/
I think the big difference between rpihddevice and vdr-fbfe is that the vdr-fbfe does not need a local vdr-instance running on the device. vdr-fbfe is connecting over network to a vdr running on a full machine. No need for streamdev.
I have been happily using vdr-sfxe on an NVidia ION board on Ubuntu 12.04 for quite a while (with a sufficiently high WAF factor :-) ) . But I haven't seen vdr-{sxfe,fbfe} in Raspbian lately. Are there any ready to consume packages anywhere? Since the ION machine has been a bit unstable lately, I'd be more than willing to throw in my RPi that idles on my desk.
TIA!
On 21.04.2015 07:41, Harald Milz wrote:
I have been happily using vdr-sfxe on an NVidia ION board on Ubuntu 12.04 for quite a while (with a sufficiently high WAF factor :-) ) . But I haven't seen vdr-{sxfe,fbfe} in Raspbian lately. Are there any ready to consume packages anywhere? Since the ION machine has been a bit unstable lately, I'd be more than willing to throw in my RPi that idles on my desk.
dto fanless Zotac ION, vdr-sxfe, recently updated from 10.4 to Ubuntu 14.4 Thinking of RPi
Which kind of "instabilities"? I do have problems with high Bandwidth HD channels (eg. ARD,ZDF no problems on most others eg Servus) I am now wondering whether - this is related to new software (drivers, vdr, vdr-sxfe) - maybe I did tweak parameters much more on first setup? - or they were alway present, just didn't recognize because this client is used mostly for watching news (no HD needed) and serves a beamer that only recently got upgraded to HD.
I didn't really put effort into that since I think of going to RPi. Maybe somebody with overview could give us potential RPi converts a short list of pros and cons of the options.
@Gerlad: "Kodi and vnsi-addon + vdr and vnsi-server-plugin" Does this provide the same features and feeling like vdr-sxfe? Then OPENEÖLEC seems a simple path to go. (I would miss firefox though. Is there a usable browser within Kodi?)
Greetings Michael
On Tue, Apr 21, 2015 at 10:25:48AM +0200, M. Fiegert wrote:
On 21.04.2015 07:41, Harald Milz wrote:
I have been happily using vdr-sfxe on an NVidia ION board on Ubuntu 12.04 for quite a while (with a sufficiently high WAF factor :-) ) . But I haven't seen vdr-{sxfe,fbfe} in Raspbian lately. Are there any ready to consume packages anywhere? Since the ION machine has been a bit unstable lately, I'd be more than willing to throw in my RPi that idles on my desk.
dto fanless Zotac ION, vdr-sxfe, recently updated from 10.4 to Ubuntu 14.4 Thinking of RPi
Which kind of "instabilities"?
This is hardware related in case of my ION board. I'm looking for a new HW platform anyway. I tried rpihddevice but using another, local VDR instance would reduce the WAF factor. If vdr-fbfe works nicely on the Pi, this will be my platform.
On ma, 2015-04-20 at 11:33 +0200, Torgeir Veimo wrote:
Have you tried rpihddevice plugin with VDR on the rpi? It might work even smoother than using xinelinboutput, but you'd have to find a different setup for cec i suppose.
http://projects.vdr-developer.org/git/vdr-plugin-rpihddevice.git/
Maybe when I get tired maintaining current xine-lib based solution :)
Based on quick look at README it should have more solid HW support than vdr-fbfe. The only thing I'd like to improve in vdr-fbfe is dynamically changing video mode (interlacing, refresh rate, clock tweaking for live mode). CEC shouldn't be a problem, it should be quite easy to add libcec support with a separate VDR plugin.
I think it requires some solution to delegate timers to server ?
With vdr-fbfe I haven't noticed any delay caused by network or OSD rendering (OSD is rendered at "powerful" server and the box is in wired ethernet). But, I don't use ARGB osd or complex animated skins.
- Petri
Maybe it would be an idea to explore running vdr-fbfe with the rpihddevice plugin, using the v4l api to send data to it? I guess the current code now implements itself a lot of the stuff needed to use xinelib, which could just be delegated to the v4l device.
On 21 April 2015 at 12:06, Petri Hintukainen phi@sdf-eu.org wrote:
On ma, 2015-04-20 at 11:33 +0200, Torgeir Veimo wrote:
Have you tried rpihddevice plugin with VDR on the rpi? It might work even smoother than using xinelinboutput, but you'd have to find a different setup for cec i suppose.
http://projects.vdr-developer.org/git/vdr-plugin-rpihddevice.git/
Maybe when I get tired maintaining current xine-lib based solution :)
Based on quick look at README it should have more solid HW support than vdr-fbfe. The only thing I'd like to improve in vdr-fbfe is dynamically changing video mode (interlacing, refresh rate, clock tweaking for live mode). CEC shouldn't be a problem, it should be quite easy to add libcec support with a separate VDR plugin.
I think it requires some solution to delegate timers to server ?
With vdr-fbfe I haven't noticed any delay caused by network or OSD rendering (OSD is rendered at "powerful" server and the box is in wired ethernet). But, I don't use ARGB osd or complex animated skins.
- Petri
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-
Gerald Dachs -
Harald Milz -
M. Fiegert -
Marko Mäkelä -
Patrick Boettcher -
Petri Hintukainen -
Petri Hintukainen -
Torgeir Veimo