Hi,
I am currently using xineliboutput, and I'm using it with "--local=none" everywhere so I can attach and detach from anywhere in the LAN, even from the PC VDR is running on. It's working quite nicely this way.
Upside: No local configuration on any PC, no concurrency issues with timers, channel updates etc.. just call "vdr-sxfe <host>" and you're in the game. Downside: Multiple connected clients at the same time get the same programme, OSD, etc. [skippy/hanging video for adapting to the different client speeds, OSD sizing issues for different client resolutions]
Is there an equivalent solution which I read to be a more recent/better supported alternative? AFAIK softhddevice is similar to xineliboutput but lacks remote features, behaves like xineliboutput with "--local=sxfe --noremote", but I could be wrong. This doesn't look like a viable alternative to my current network architecture.
While streamdev and VNSI/XVDR solve some of the issues, most notably the multi-client dependency, they create new ones. No native OSD with VNSI/XVDR, VDR configuration synchronization hassle with streamdev.
Is there any other thin-client streaming solution with native VDR OSD available?
Any other suggestions?
Thanks, - Matthias
Hi,
I'm in the same situation, and most of my friends, using vdr the same way, too.
The only software, I currently know which works similar, is VOMP client/server. It is also independant and could be run standalone on Linux and Windows. But it is IMHO only a "worst-case-replacement" for sxfe.
I also don't want to have a complete vdr environment running, for only watching TV on my laptops or any other remote station.
Thanks, Günter
---
Am 14.04.2015 um 08:59 schrieb Matthias Wächter:
Hi,
I am currently using xineliboutput, and I'm using it with "--local=none" everywhere so I can attach and detach from anywhere in the LAN, even from the PC VDR is running on. It's working quite nicely this way.
Upside: No local configuration on any PC, no concurrency issues with timers, channel updates etc.. just call "vdr-sxfe <host>" and you're in the game. Downside: Multiple connected clients at the same time get the same programme, OSD, etc. [skippy/hanging video for adapting to the different client speeds, OSD sizing issues for different client resolutions]
Is there an equivalent solution which I read to be a more recent/better supported alternative? AFAIK softhddevice is similar to xineliboutput but lacks remote features, behaves like xineliboutput with "--local=sxfe --noremote", but I could be wrong. This doesn't look like a viable alternative to my current network architecture.
While streamdev and VNSI/XVDR solve some of the issues, most notably the multi-client dependency, they create new ones. No native OSD with VNSI/XVDR, VDR configuration synchronization hassle with streamdev.
Is there any other thin-client streaming solution with native VDR OSD available?
Any other suggestions?
Thanks,
- Matthias
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-- This message was scanned by ESVA and is believed to be clean. Click here to report this message as spam. http://esva.nk-hosting.de:10080/cgi-bin/learn-msg.cgi?id=D68AC160087.AB80D
-- This message was scanned by ESVA and is believed to be clean.
Am 2015-04-14 08:59, schrieb Matthias Wächter:
While streamdev and VNSI/XVDR solve some of the issues, most notably the multi-client dependency, they create new ones. No native OSD with VNSI/XVDR, VDR configuration synchronization hassle with streamdev.
use softhddevice + vdr + streamdev-client on the clients and connect to a streamdev-server on the main vdr.
Gerald
Am 14.04.2015 um 09:56 schrieb Gerald Dachs:
Am 2015-04-14 08:59, schrieb Matthias Wächter:
While streamdev and VNSI/XVDR solve some of the issues, most notably the multi-client dependency, they create new ones. No native OSD with VNSI/XVDR, VDR configuration synchronization hassle with streamdev.
use softhddevice + vdr + streamdev-client on the clients and connect to a streamdev-server on the main vdr.
Gerald
Well, that works so far, but it is not an effective substitute for the functionality of vdr-sxfe, at least not for what I use it mainly. All functions run on the remote machine, and only the screen is transferred to the local machine.
-Günter
-- This message was scanned by ESVA and is believed to be clean.
Am 2015-04-15 00:55, schrieb Niedermeier Günter:
Am 14.04.2015 um 09:56 schrieb Gerald Dachs:
Am 2015-04-14 08:59, schrieb Matthias Wächter:
While streamdev and VNSI/XVDR solve some of the issues, most notably the multi-client dependency, they create new ones. No native OSD with VNSI/XVDR, VDR configuration synchronization hassle with streamdev.
use softhddevice + vdr + streamdev-client on the clients and connect to a streamdev-server on the main vdr.
Gerald
Well, that works so far, but it is not an effective substitute for the functionality of vdr-sxfe, at least not for what I use it mainly. All functions run on the remote machine, and only the screen is transferred to the local machine.
This solution, or the already mentioned possibility with Kodi and vnsi/xvdr, are the only supported ways currently. If this is not good for you, then start coding.
Gerald
On Wed, Apr 15, 2015 at 3:56 AM, Gerald Dachs vdr@dachsweb.de wrote:
While streamdev and VNSI/XVDR solve some of the issues, most notably the multi-client dependency, they create new ones. No native OSD with VNSI/XVDR, VDR configuration synchronization hassle with streamdev.
use softhddevice + vdr + streamdev-client on the clients and connect to a streamdev-server on the main vdr.
Well, that works so far, but it is not an effective substitute for the functionality of vdr-sxfe, at least not for what I use it mainly. All functions run on the remote machine, and only the screen is transferred to the local machine.
This solution, or the already mentioned possibility with Kodi and vnsi/xvdr, are the only supported ways currently. If this is not good for you, then start coding.
Proper server/client has been on the user wishlist for ages. There's no reason to be rude to someone looking for something better. If those solutions were all that great then there wouldn't be any reason to ask. Of all the people who are scolded with `code it yourself then`, how many actually can? Probably very very very few, so why bother with such useless comments?
Am 2015-04-15 16:43, schrieb VDR User:
On Wed, Apr 15, 2015 at 3:56 AM, Gerald Dachs vdr@dachsweb.de wrote:
While streamdev and VNSI/XVDR solve some of the issues, most notably the multi-client dependency, they create new ones. No native OSD with VNSI/XVDR, VDR configuration synchronization hassle with streamdev.
use softhddevice + vdr + streamdev-client on the clients and connect to a streamdev-server on the main vdr.
Well, that works so far, but it is not an effective substitute for the functionality of vdr-sxfe, at least not for what I use it mainly. All functions run on the remote machine, and only the screen is transferred to the local machine.
This solution, or the already mentioned possibility with Kodi and vnsi/xvdr, are the only supported ways currently. If this is not good for you, then start coding.
Proper server/client has been on the user wishlist for ages. There's no reason to be rude to someone looking for something better. If those solutions were all that great then there wouldn't be any reason to ask. Of all the people who are scolded with `code it yourself then`, how many actually can? Probably very very very few, so why bother with such useless comments?
Nonsense, I have not been rude. I have even some examples where I told this to other users that started coding afterwords. That made it a very useful comment.
To not say it and miss a change to get it done is useless.
Gerald
On Wed, Apr 15, 2015 at 8:03 AM, Gerald Dachs vdr@dachsweb.de wrote:
Proper server/client has been on the user wishlist for ages. There's no reason to be rude to someone looking for something better. If those solutions were all that great then there wouldn't be any reason to ask. Of all the people who are scolded with `code it yourself then`, how many actually can? Probably very very very few, so why bother with such useless comments?
Nonsense, I have not been rude. I have even some examples where I told this to other users that started coding afterwords. That made it a very useful comment.
To not say it and miss a change to get it done is useless.
Who, and what have they coded? Project names?
Thanks
Am 15.04.2015 um 18:37 schrieb VDR User:
On Wed, Apr 15, 2015 at 8:03 AM, Gerald Dachs vdr@dachsweb.de wrote:
Proper server/client has been on the user wishlist for ages. There's no reason to be rude to someone looking for something better. If those solutions were all that great then there wouldn't be any reason to ask. Of all the people who are scolded with `code it yourself then`, how many actually can? Probably very very very few, so why bother with such useless comments?
Nonsense, I have not been rude. I have even some examples where I told this to other users that started coding afterwords. That made it a very useful comment.
To not say it and miss a change to get it done is useless.
Who, and what have they coded? Project names?
So, you name me a liar? Would it change something if I would name projects?
Gerald
!DSPAM:552e984a166098533532618!
On Wed, Apr 15, 2015 at 9:56 AM, Gerald Dachs vdr@dachsweb.de wrote:
To not say it and miss a change to get it done is useless.
Who, and what have they coded? Project names?
So, you name me a liar? Would it change something if I would name projects?
I'm genuinely curious who you talked into learning to code, and what projects they've done. Should've been easy enough to do. But, I expected nothing more than the completely predictable response you gave. I doubt anyone did. People love making claims like that but hate backing them up ... you know, for some reason.
Am 15.04.2015 um 22:49 schrieb VDR User:
On Wed, Apr 15, 2015 at 9:56 AM, Gerald Dachs vdr@dachsweb.de wrote:
To not say it and miss a change to get it done is useless.
Who, and what have they coded? Project names?
So, you name me a liar? Would it change something if I would name projects?
I'm genuinely curious who you talked into learning to code, and what projects they've done.
He didn't say that he taught someone to code, but made them start to code on something someone need.
I think there are some misunderstandings here. :)
Gerald and me met on a VDR user meeting and he convinced me to start on "something" that would make it possible to start vdr before all dvb-devices are initialised. That was the start of the dynamite-patch/plugin. And I think, this is a feature that vdr should learn. As soon as time permits I will rework on it doing all the things "more right" and implementing it more straight forward from what I've learned. And without a plugin, just as a patch that can be activated with a commandline switch.
No more sleep-loops in boot scripts... :)
Lars.
Should've been easy enough to do. But, I expected nothing more than the completely predictable response you gave. I doubt anyone did. People love making claims like that but hate backing them up ... you know, for some reason.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Am 15.04.2015 um 18:37 schrieb VDR User:
On Wed, Apr 15, 2015 at 8:03 AM, Gerald Dachs vdr@dachsweb.de wrote:
Proper server/client has been on the user wishlist for ages. There's no reason to be rude to someone looking for something better. If those solutions were all that great then there wouldn't be any reason to ask. Of all the people who are scolded with `code it yourself then`, how many actually can? Probably very very very few, so why bother with such useless comments?
Nonsense, I have not been rude. I have even some examples where I told this to other users that started coding afterwords. That made it a very useful comment.
To not say it and miss a change to get it done is useless.
Who, and what have they coded? Project names?
restfulapi and dynamite are two of them. And he encouraged me to start with dbus2vdr.
Nothing with client/server-streaming yet, but who knows what the future will bring. :)
Lars.
Am 2015-04-15 22:54, schrieb Lars Hanisch:
Am 15.04.2015 um 18:37 schrieb VDR User:
On Wed, Apr 15, 2015 at 8:03 AM, Gerald Dachs vdr@dachsweb.de wrote:
Proper server/client has been on the user wishlist for ages. There's no reason to be rude to someone looking for something better. If those solutions were all that great then there wouldn't be any reason to ask. Of all the people who are scolded with `code it yourself then`, how many actually can? Probably very very very few, so why bother with such useless comments?
Nonsense, I have not been rude. I have even some examples where I told this to other users that started coding afterwords. That made it a very useful comment.
To not say it and miss a change to get it done is useless.
Who, and what have they coded? Project names?
restfulapi and dynamite are two of them. And he encouraged me to start with dbus2vdr.
Restfulapi and dynamite were the projects I had in mind, thanks Lars. And restfulapi was a starter for even two more fellows. And just in case that you will tell now that nobody needs that, then you talk only for yourself. Dynamite is used by all yaVDR users. Restfulapi is now part of OpenELEC.
Are you man enough to confess that you are wrong? I doubt that, you will surely find some excuses.
Gerald
Restfulapi and dynamite were the projects I had in mind, thanks Lars. And restfulapi was a starter for even two more fellows.
I've never heard of Restfulapi. Dynamite I've at least heard of but until Lars post, had no clue what it did.
And just in case that you will tell now that nobody needs that, then you talk only for yourself.
I haven't made any comment at all along those lines. There's absolutely no reason for you to think that based on anything I've said. Maybe you're trying to project your own opinions onto me. Or just making things up and then commenting on it. Who knows.
Dynamite is used by all yaVDR users. Restfulapi is now part of OpenELEC.
They sound successful. Unfortunately https://github.com/yavdr/vdr-plugin-restfulapi/blob/master/README is just an advertisement for yavdr and gives no actual information on what exectly restfulapi does. From what I could find searching elsewhere, it's just an alternative way to display epg information (returned as json or xml formatted). Is this correct?
The dynamite plugin sounds like it would help speed up the VDR start process. I would imagine something like that would be necessary if/when VDR gets a real server/client upgrade. I would hope so anyways! I'll probably wait until Lars does the rework he mentioned before I try it.
Are you man enough to confess that you are wrong? I doubt that, you will surely find some excuses.
What exactly do you think I was wrong about? That I'm "genuinely curious who you talked into learning to code, and what projects they've done", or that " I expected nothing more than the completely predictable response you gave"? Maybe you're referring to, "people love making claims like that but hate backing them up"? Nothing I've said is wrong or untrue. There's nothing to `confess`, as you put it.
Can you please discuss this further off the list? I think this is going way beyond the purpose of the list and I think I might not be the only one that is not interested in following this argument on the list.
Best regards, Reiner.
Am 16.04.2015 16:09, schrieb VDR User:
Restfulapi and dynamite were the projects I had in mind, thanks Lars. And restfulapi was a starter for even two more fellows.
I've never heard of Restfulapi. Dynamite I've at least heard of but until Lars post, had no clue what it did.
And just in case that you will tell now that nobody needs that, then you talk only for yourself.
I haven't made any comment at all along those lines. There's absolutely no reason for you to think that based on anything I've said. Maybe you're trying to project your own opinions onto me. Or just making things up and then commenting on it. Who knows.
Dynamite is used by all yaVDR users. Restfulapi is now part of OpenELEC.
They sound successful. Unfortunately https://github.com/yavdr/vdr-plugin-restfulapi/blob/master/README is just an advertisement for yavdr and gives no actual information on what exectly restfulapi does. From what I could find searching elsewhere, it's just an alternative way to display epg information (returned as json or xml formatted). Is this correct?
The dynamite plugin sounds like it would help speed up the VDR start process. I would imagine something like that would be necessary if/when VDR gets a real server/client upgrade. I would hope so anyways! I'll probably wait until Lars does the rework he mentioned before I try it.
Are you man enough to confess that you are wrong? I doubt that, you will surely find some excuses.
What exactly do you think I was wrong about? That I'm "genuinely curious who you talked into learning to code, and what projects they've done", or that " I expected nothing more than the completely predictable response you gave"? Maybe you're referring to, "people love making claims like that but hate backing them up"? Nothing I've said is wrong or untrue. There's nothing to `confess`, as you put it.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Gerald, my opinion is my opinion - you disagreeing doesn't change anything. It's not wrong and nobody is the opinion police.
Reiner, if you don't want to following something, *don't follow it*. You're not being forced to read anything. However, out of courtesy for Matthias, the OP, I won't keep participating in distraction from his query.
Am 16.04.2015 um 17:09 schrieb VDR User:
Gerald, my opinion is my opinion - you disagreeing doesn't change anything. It's not wrong and nobody is the opinion police.
So why you then argued against my argumentation to show that I am not rude and named me even a liar? And after I proofed that I didn't lie you just continued to let me me just look stupid?
All the years I had the feeling that you are just a troll, but I hoped that I was wrong.
Gerald
!DSPAM:552fdaa1645671082260260!
On 16/04/15 16:28, Gerald Dachs wrote:
Am 2015-04-16 16:09, schrieb VDR User:
What exactly do you think I was wrong about?
You forgot already? You told that I was rude and I proofed that I was not.
Gerald
Sometimes even the truth may sound rudely. So you both made your points. Kind regards Bernd
Am 16.04.2015 um 16:09 schrieb VDR User: [...]
Dynamite is used by all yaVDR users. Restfulapi is now part of OpenELEC.
They sound successful. Unfortunately https://github.com/yavdr/vdr-plugin-restfulapi/blob/master/README is just an advertisement for yavdr and gives no actual information on what exectly restfulapi does. From what I could find searching elsewhere, it's just an alternative way to display epg information (returned as json or xml formatted). Is this correct?
Please have a look at: https://github.com/yavdr/vdr-plugin-restfulapi/blob/master/API.html
It's a plugin for communicating with and controlling vdr with http-request, so it's a good counterpart for webapps on smartphones, tablets etc.. There are also the one or other webapp using it, so you can benefit from a new user interface to vdr. It's not just displaying the OSD on a remote screen, it's used for a new kind of menu to control the most common tasks of vdr like browsing EPG, manage timers, view/edit recordings...
You won't be able to use plugins like tvguide or femon etc. as long as the won't publish their data in some way, restfulapi can consume (via some servicecall or something) and put it into json/xml, so the remote can display it in some useful way.
For streaming streamdev is used. There were some nice features added to streamdev, for example now recordings can be started at some arbitrary timestamp.
Here's an announcement of an actual app (unfortunatly in german): http://www.vdr-portal.de/board1-news/board2-vdr-news/125859-/
But this all is not a real replacement for xineliboutput/vdr-sxfe (to come back to topic...). :)
Lars.
I know, it's not a proper answer for your problem, but I think at the moment the best native vdr client is a Raspberry Pi with Thomas Reufer's great plugin. It's small, cheap and (using with vdr) it's fast.
I moved from vdr-sxfe to rpihddevice with all my 3 clients in the house.
regards,
István
2015.04.14. 9:59 keltezéssel, Matthias Wächter írta:
Hi,
I am currently using xineliboutput, and I'm using it with "--local=none" everywhere so I can attach and detach from anywhere in the LAN, even from the PC VDR is running on. It's working quite nicely this way.
Upside: No local configuration on any PC, no concurrency issues with timers, channel updates etc.. just call "vdr-sxfe <host>" and you're in the game. Downside: Multiple connected clients at the same time get the same programme, OSD, etc. [skippy/hanging video for adapting to the different client speeds, OSD sizing issues for different client resolutions]
Is there an equivalent solution which I read to be a more recent/better supported alternative? AFAIK softhddevice is similar to xineliboutput but lacks remote features, behaves like xineliboutput with "--local=sxfe --noremote", but I could be wrong. This doesn't look like a viable alternative to my current network architecture.
While streamdev and VNSI/XVDR solve some of the issues, most notably the multi-client dependency, they create new ones. No native OSD with VNSI/XVDR, VDR configuration synchronization hassle with streamdev.
Is there any other thin-client streaming solution with native VDR OSD available?
Any other suggestions?
Thanks,
- Matthias
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi all,
On Fri, 17 Apr 2015 09:25:22 +0300 Füley István aironet@tigercomp.ro wrote:
I know, it's not a proper answer for your problem, but I think at the moment the best native vdr client is a Raspberry Pi with Thomas Reufer's great plugin. It's small, cheap and (using with vdr) it's fast.
I moved from vdr-sxfe to rpihddevice with all my 3 clients in the house.
And you are using streamdev-server on your vdr-host (which has all the DVB-cards) and client on the RPI?
regards, -- Patrick.
2015.04.17. 10:24 keltezéssel, Patrick Boettcher írta:
Hi all,
And you are using streamdev-server on your vdr-host (which has all the DVB-cards) and client on the RPI?
Yes, this is the basic arhitecture, but it is changing for time to time :) I have 4 DVB-S2 cards on my headless server, which runs a plain vdr with streamdev-server. The clients are 3 Raspberries, one of them is on wireless, the other 2 on Ethernet. One of the Raspberries (an RPI 2B with 1GB ram) has a local USB DVB-S2 adapter too, but it's also runs the stremdev-client.
regards,
István
PS. To your other topic: there is no problem running xineliboutput and streamdev-server on the same vdr. I used this configuration for years.
Hello István,
which USB DVB-S2 receiver do you use on your Raspberry Pi?
Best regards, Reiner.
Am 17.04.2015 11:54, schrieb Füley István:
2015.04.17. 10:24 keltezéssel, Patrick Boettcher írta:
Hi all,
And you are using streamdev-server on your vdr-host (which has all the DVB-cards) and client on the RPI?
Yes, this is the basic arhitecture, but it is changing for time to time :) I have 4 DVB-S2 cards on my headless server, which runs a plain vdr with streamdev-server. The clients are 3 Raspberries, one of them is on wireless, the other 2 on Ethernet. One of the Raspberries (an RPI 2B with 1GB ram) has a local USB DVB-S2 adapter too, but it's also runs the stremdev-client.
regards,
István
PS. To your other topic: there is no problem running xineliboutput and streamdev-server on the same vdr. I used this configuration for years.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
2015.04.17. 13:07 keltezéssel, Reiner Bühl írta:
Hello István,
which USB DVB-S2 receiver do you use on your Raspberry Pi?
It's an old Terratec Cinergy S2: http://www.linuxtv.org/wiki/index.php/TerraTec_Cinergy_S2
I used it several years ago on my main server, but I had a problem with it: i needed to replug it every couple of days. I throwed away, and didn't use it since then. I tried it again on my RPI for about 3 weeks ago, and it's working well since then. Here you can find a low quality video about it, to make an idea how it's moving: https://vimeo.com/124439878
István
On Fri, Apr 17, 2015 at 09:25:22AM +0300, Füley István wrote:
I know, it's not a proper answer for your problem, but I think at the moment the best native vdr client is a Raspberry Pi with Thomas Reufer's great plugin. It's small, cheap and (using with vdr) it's fast.
Speaking of small and cheap, does anyone have such a VDR server? Something like an Allwinner A20 with SATA hard disk for the recordings, and a USB DVB-T/T2/C adapter, and using the built-in IR receiver and HDMI output? I have been dreaming of that, but I guess my almost 15-years-old 900 MHz Celeron box just refuses to die. :) There even are ready-made cases for a SATA disk and the Cubieboard3 (Cubietruck).
For client, I am using the Samsung SmartTV plugin. Not good for heavy use due to the bad SmartTV platform, but bearable. Recordings cannot be edited via it, and subtitles do not work.
Marko
----Origineel Bericht---- Van : marko.makela@iki.fi Datum : 17/04/2015 11:51 Aan : vdr@linuxtv.org Onderwerp : Re: [vdr] from xineliboutput to ... perhaps softhdddevice?
On Fri, Apr 17, 2015 at 09:25:22AM +0300, Füley István wrote:
I know, it's not a proper answer for your problem, but I think at the moment the best native vdr client is a Raspberry Pi with Thomas Reufer's great plugin. It's small, cheap and (using with vdr) it's fast.
Speaking of small and cheap, does anyone have such a VDR server? Something like an Allwinner A20 with SATA hard disk for the recordings, and a USB DVB-T/T2/C adapter, and using the built-in IR receiver and HDMI output? I have been dreaming of that, but I guess my almost 15-years-old 900 MHz Celeron box just refuses to die. :) There even are ready-made cases for a SATA disk and the Cubieboard3 (Cubietruck).
For client, I am using the Samsung SmartTV plugin. Not good for heavy use due to the bad SmartTV platform, but bearable. Recordings cannot be edited via it, and subtitles do not work.
Marko
That would be me. I have an alwinnerA20 with 3 DVB-T USB receivers. I use vdr-xineliboutput and vdr-sxfe on the same machine. It works, but it uses the CPU for playback. I am told it should be possible to use softhddevice, but I have not yet tried it.
Also, there's something going wrong with the DVB-T receivers, I have to power-down-and-up my machine every week, some special memory in the kernel fills up. Also, when I do a warm reboot (while the receivers remain powered) the initialization goes wrong somehow, and the pre-amplifier in the receivers is not enabled, and usually vdr can't use the receivers. My receivers are the PCTV NanoStick 73e SE (solo) http://linuxtv.org/wiki/index.php/Pinnacle_PCTV_nano_Stick_%2873e%29
Performance for recording encrypted shows is OK, I have recorded 3 encrypted shows at the same time without problems. Also, copying files using samba to and from the sata harddrive is not noticable while also watching, and recording TV. My board has 100Mb network, and I see consistent 11MB/s read and write performance. Write performance on the uSD card is terrible, even with a class 10 card. Updating debian on the card takes patience.
Kind regards, Cedric
Hi Cedric,
On Fri, Apr 17, 2015 at 12:08:05PM +0200, cedric.dewijs@telfort.nl wrote:
Write performance on the uSD card is terrible, even with a class 10 card. Updating debian on the card takes patience.
AFAIU if you are not afraid of bricking the Cubietruck, you could install Debian on the built-in flash too. This is what I understood from some forum post; I have no personal experience of installing Linux on anything else than x86 hardware.
How does your setup physically look like? Do you have a rat's nest of cables? Does it work without a USB hub?
Marko
For those of you using Raspberry Pi or Allwinner boards, how is osd performance? If the osd is fast & smooth, I'm interested in building a couple vdr setups like those (maybe Raspberry Pi 2. Rpi is just too slow). Any degrade in performance is a deal-breaker for me.
Thanks
On 4/17/2015 2:13 PM, VDR User wrote:
For those of you using Raspberry Pi or Allwinner boards, how is osd performance? If the osd is fast & smooth, I'm interested in building a couple vdr setups like those (maybe Raspberry Pi 2. Rpi is just too slow). Any degrade in performance is a deal-breaker for me.
Thanks
Hi,
OSD performance is not an issue on an allwinnerA20, with one exception. I have 640GB SD recordings. The first time after VDR startup, opening the list with recordings is a bit slow (about a second). This is on a olimex A20 board, running both the VDR server and xineliboutput and vdr-sxfe.
Come to think of it, I heard codi (xbmp) has support for hardware decoded video playback on the A20, and vdr has support for xbmc via vdr-plugin-vnsiserver. Is there anybody who has taken this route? How did it go? http://linux-sunxi.org/XBMC http://kodi.wiki/view/VDR
the other route I heard of is VDR+softhddevice via vdpau and cedarX. Has anybody got this running on an A20? Does it actually yields accelerated video playback?
I have managed to use mplayer to playback my recordings using cedarX, but that's some time ago: https://www.olimex.com/forum/index.php?topic=3560.msg14973#msg14973
Kind regards, Cedric
Actually cedarX hw decoding was another question I forgot in my previous post. I've read that it's working in linux but I didn't know if any output devices supported it (yet)?. Was hoping softhddevice does, or would if I sent Johns an A20. :)
On Fri, Apr 17, 2015 at 11:17 AM, Cedric de Wijs cedric.dewijs@telfort.nl wrote:
On 4/17/2015 2:13 PM, VDR User wrote:
For those of you using Raspberry Pi or Allwinner boards, how is osd performance? If the osd is fast & smooth, I'm interested in building a couple vdr setups like those (maybe Raspberry Pi 2. Rpi is just too slow). Any degrade in performance is a deal-breaker for me.
Thanks
Hi,
OSD performance is not an issue on an allwinnerA20, with one exception. I have 640GB SD recordings. The first time after VDR startup, opening the list with recordings is a bit slow (about a second). This is on a olimex A20 board, running both the VDR server and xineliboutput and vdr-sxfe.
Come to think of it, I heard codi (xbmp) has support for hardware decoded video playback on the A20, and vdr has support for xbmc via vdr-plugin-vnsiserver. Is there anybody who has taken this route? How did it go? http://linux-sunxi.org/XBMC http://kodi.wiki/view/VDR
the other route I heard of is VDR+softhddevice via vdpau and cedarX. Has anybody got this running on an A20? Does it actually yields accelerated video playback?
I have managed to use mplayer to playback my recordings using cedarX, but that's some time ago: https://www.olimex.com/forum/index.php?topic=3560.msg14973#msg14973
Kind regards, Cedric
On 4/17/2015 6:46 PM, VDR User wrote:
Actually cedarX hw decoding was another question I forgot in my previous post. I've read that it's working in linux but I didn't know if any output devices supported it (yet)?. Was hoping softhddevice does, or would if I sent Johns an A20. :)
I think it's always helpful to send a developer the hardware you want their code to run on. This helps on the hardware side of things, being able to debug on actual hardware goes much faster than let somebody else test stuff for you. Also, when you donate hardware, you let the developer know much you want it to work, and i think this motivates.
Kind regards, Cedric
Hi,
Am 17.04.2015 um 20:46 schrieb VDR User:
Actually cedarX hw decoding was another question I forgot in my previous post. I've read that it's working in linux but I didn't know if any output devices supported it (yet)?. Was hoping softhddevice does, or would if I sent Johns an A20. :)
I suppose you missed that vdr + softhddevice libvdpau-sunxi is working on A10/A20 hardware already and makes these devices nice fanless energy saving vdr clients. Including deinterlacing.
So first, forget the cedarx binaries and take a look at http://linux-sunxi.org/Cedrus There is a libvdpau backend driver for A10/A20 devices, that supports hardwares accelerated video decoding and presentation. With johns' help we tried to improve that piece of code in the last few weeks and have now something, that is working very well imho. But it's not finished yet and not all vdpau functions are implemented. Because of the way libvdpau-sunxi uses the hardware, there are still some limitations, especially when working in windowed mode. But it's quite good useable. You may give it a try: https://github.com/rellla/libvdpau-sunxi
There are already a few threads and howtos in the german vdr-portal.de and in vdr-wiki.de iirc. It also should be no problem to make a vdr server out of one of these boxes. It's nothing else than linux on an arm box. I recommend to take a device, that has sata and put your rootfs there instead of sd card or nand. And maybe you will have some limitations due to the bandwidth (usb etc.) as with the other arm boxes as well.
Regards Andreas
On Fri, Apr 17, 2015 at 11:17 AM, Cedric de Wijs cedric.dewijs@telfort.nl wrote:
On 4/17/2015 2:13 PM, VDR User wrote:
For those of you using Raspberry Pi or Allwinner boards, how is osd performance? If the osd is fast & smooth, I'm interested in building a couple vdr setups like those (maybe Raspberry Pi 2. Rpi is just too slow). Any degrade in performance is a deal-breaker for me.
Thanks
Hi,
OSD performance is not an issue on an allwinnerA20, with one exception. I have 640GB SD recordings. The first time after VDR startup, opening the list with recordings is a bit slow (about a second). This is on a olimex A20 board, running both the VDR server and xineliboutput and vdr-sxfe.
Come to think of it, I heard codi (xbmp) has support for hardware decoded video playback on the A20, and vdr has support for xbmc via vdr-plugin-vnsiserver. Is there anybody who has taken this route? How did it go? http://linux-sunxi.org/XBMC http://kodi.wiki/view/VDR
the other route I heard of is VDR+softhddevice via vdpau and cedarX. Has anybody got this running on an A20? Does it actually yields accelerated video playback?
I have managed to use mplayer to playback my recordings using cedarX, but that's some time ago: https://www.olimex.com/forum/index.php?topic=3560.msg14973#msg14973
Kind regards, Cedric
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Am 17.04.2015 um 20:46 schrieb VDR User:
Actually cedarX hw decoding was another question I forgot in my previous post. I've read that it's working in linux but I didn't know if any output devices supported it (yet)?. Was hoping softhddevice does, or would if I sent Johns an A20. :)
I suppose you missed that vdr + softhddevice libvdpau-sunxi is working on A10/A20 hardware already and makes these devices nice fanless energy saving vdr clients. Including deinterlacing.
So first, forget the cedarx binaries and take a look at http://linux-sunxi.org/Cedrus There is a libvdpau backend driver for A10/A20 devices, that supports hardwares accelerated video decoding and presentation. With johns' help we tried to improve that piece of code in the last few weeks and have now something, that is working very well imho. But it's not finished yet and not all vdpau functions are implemented. Because of the way libvdpau-sunxi uses the hardware, there are still some limitations, especially when working in windowed mode. But it's quite good useable. You may give it a try: https://github.com/rellla/libvdpau-sunxi
There are already a few threads and howtos in the german vdr-portal.de and in vdr-wiki.de iirc. It also should be no problem to make a vdr server out of one of these boxes. It's nothing else than linux on an arm box. I recommend to take a device, that has sata and put your rootfs there instead of sd card or nand. And maybe you will have some limitations due to the bandwidth (usb etc.) as with the other arm boxes as well.
Regards Andreas
Thank you. I indeed missed that vdr + softhddevice + libvdpau-sunxi exist. I will take a look at it. When I succeed in creating a functional VDR box with it, I'll add it to these howtos: https://wiki.debian.org/VDR https://wiki.archlinux.org/index.php/Digitenne
I have used the olimex A20-OLinuXino-MICRO-4GB with 3 DVB-T receivers all connected to one USB port of the A20 via a hub. my receivers can't filter the data, therefore the entire datastream is sent to the A20. When recording 3 TV shows concurrently, this is 24MB/s (192Mb/s) of data. I have almost never seen glitches in the recorded shows.
When used with samba (and large files), the A20 delivered 11MB/s from the SATA HD to the 100Mb NIC.
I can say both the USB and the SATA buses are quite capable.
Kind regards, Cedric
-
Andreas Baierl -
BB -
Cedric de Wijs -
cedric.dewijs＠telfort.nl
-
Füley István -
Gerald Dachs -
Lars Hanisch -
Marko Mäkelä -
Matthias Wächter -
Niedermeier Günter -
Patrick Boettcher -
Reiner Bühl -
VDR User