Hi there,
I just published new releases of the plugins remoteosd and svdrposd (formerly svdrpext) on http://vdr.schmirler.de. The most important changes are the overdue gettext support for remoteosd and a major speedup of the remote menu in combination with the new svdrposd plugin.
The remoteosd plugin provides access to the menu of an other VDR. Remoteosd relies on the svdrpservice plugin, which is also available from my website.
I renamed the svdrpext plugin to svdrposd. The plugin publishes the textual contents of the OSD menu on SVDRP. In order to access the menu of a remote VDR using the remoteosd plugin, svdrposd or its successor svdrpext must be installed on the remote VDR.
Changelog remoteosd: - if available, use svdrposd-plugin instead of svdrpext-plugin - added gettext support (thanks to Diego Pierotto) Credits to Udo Richter for his po218n.pl backward compatibility script - added Italian translation (thanks to Diego Pierotto) - log error if svdrpservice or svdrpext/svdrposd are not installed - replaced all occurences of asprintf - fixed not parsing replace mainmenu settings
Changelog svdrposd: - renamed plugin from svdrpext to svdrposd - new command LSTO - number of items parameter to OSDI is now optional - improved selection of current item if multiple items have the same text - fixed memleak; no longer relying on OsdClear() being called before assigning new values - code cleanup
Have fun!
Frank
I just published new releases of the plugins remoteosd and svdrposd (formerly svdrpext) on http://vdr.schmirler.de. The most important changes are the overdue gettext support for remoteosd and a major speedup of the remote menu in combination with the new svdrposd plugin.
The remoteosd plugin provides access to the menu of an other VDR. Remoteosd relies on the svdrpservice plugin, which is also available from my website.
I renamed the svdrpext plugin to svdrposd. The plugin publishes the textual contents of the OSD menu on SVDRP. In order to access the menu of a remote VDR using the remoteosd plugin, svdrposd or its successor svdrpext must be installed on the remote VDR.
Hi, I got interested in from your plugins and tried to read throught your web page to get more info. So if I understood correctly the svdrpservice plugin provides the highway howto communicate from client to vdr server.
But after that I get a little lost what are the cases where I should use your plugins... I mean currently I have 1 vdr server with dvb-t and dvb-c cards, xineliboutput server and streamdev server plugins running on it. Then from other client computers I can use either mplayer or xineliboutput client (vdr-sxfe) for connecting to this server for watching the tv. Currently my setup has however a that kind of limitation that all vdr-sxfe clients are forced to watch the same channel and whenever any of the clients change channel, the channel will be changed also to every other vdr-sxfe clients. I have read this could be somehow be avoided by running multiple vdr servers on the server machine and then forcing each client to connect to own vdr server port...
Are your plugins meant for solving a that kind of multiple clients want to watch different channel problems or for which purpose your are using these plugins?
Mika
Mika Laitio schrieb:
I just published new releases of the plugins remoteosd and svdrposd (formerly svdrpext) on http://vdr.schmirler.de. The most important changes are the overdue gettext support for remoteosd and a major speedup of the remote menu in combination with the new svdrposd plugin.
The remoteosd plugin provides access to the menu of an other VDR. Remoteosd relies on the svdrpservice plugin, which is also available from my website.
I renamed the svdrpext plugin to svdrposd. The plugin publishes the textual contents of the OSD menu on SVDRP. In order to access the menu of a remote VDR using the remoteosd plugin, svdrposd or its successor svdrpext must be installed on the remote VDR.
Hi, I got interested in from your plugins and tried to read throught your web page to get more info. So if I understood correctly the svdrpservice plugin provides the highway howto communicate from client to vdr server.
But after that I get a little lost what are the cases where I should use your plugins... I mean currently I have 1 vdr server with dvb-t and dvb-c cards, xineliboutput server and streamdev server plugins running on it. Then from other client computers I can use either mplayer or xineliboutput client (vdr-sxfe) for connecting to this server for watching the tv. Currently my setup has however a that kind of limitation that all vdr-sxfe clients are forced to watch the same channel and whenever any of the clients change channel, the channel will be changed also to every other vdr-sxfe clients. I have read this could be somehow be avoided by running multiple vdr servers on the server machine and then forcing each client to connect to own vdr server port...
Are your plugins meant for solving a that kind of multiple clients want to watch different channel problems or for which purpose your are using these plugins?
My understanding of how you could do the setup, and how exactly this plugins can help you:
You have streamdev-server and svdrpservice/osd plugins running on the server. You have running streamdev-client and remote-osd, remote-timer and whatever else plugin running on the client(s)
The client would carry the xineliboutput plugin and you connect on the client machine to the client machine vdr. The streamdev provides the "tv cards" to the clients. The remote timer plugin enables you to create timers and more on the server, the epgsync lets you sync the epg, so clients don't need to do epg-scan (which could hit your server hard if 1 server , multipke clients). The Remote OSD Plugin enables you to have the server OSD on one of the clients to do configurations etc pp. So in the end you get a client server vdr which behaves very near like a few standalone vdr
On Thu, 08 Oct 2009 07:28:08 +0200, Steffen Barszus wrote Well explained, Steffen. Thanks. Just a few additional notes:
You have streamdev-server and svdrpservice/osd plugins running on the server. You have running streamdev-client and remote-osd, remote- timer and whatever else plugin running on the client(s)
svdrpservice is not a serverside but a client side plugin. It allows multiple plugins on the same client to share a single SVDRP connection to the server (remember, SVDRP accepts only one connection at a time). So e.g. while epgsync downloads the server's EPG you can still edit the server's timers.
The client would carry the xineliboutput plugin and you connect on the client machine to the client machine vdr.
Just to avoid confusion: xineliboutput on the client is just one possibility. Any output plugin will do (softdevice, dxr3, reelbox3, ...).
In general my plugins become useful as soon as multiple VDR instances come into play. On the server you'd typically put streamdev-server, svdrposd, femon and dummydevice. The client runs some sort of output plugin, streamdev-client, remoteosd, epgsync, femon and either remotetimers or timersync.
Note that the client VDR may run on the same machine as the server VDR. That's the setup described in the xineliboutput README for real multi client. I'd rather label it the "thin client" approach:
**Server Machine************************************* * DVB card > SERVER-VDR > streamdev-server * streamdev-client > CLIENT-VDR > xineliboutput *****************************************************
NETWORK
**Client Machine************************************* * xineliboutput frontend *****************************************************
as opposed to "fat client":
**Server Machine************************************* * DVB card > SERVER-VDR > streamdev-server *****************************************************
NETWORK
**Client Machine************************************* * streamdev-client > CLIENT-VDR > output plugin of your choice *****************************************************
Fill in xineliboutput as the output plugin and add the frontend - you end up with the same components for both approaches, just the network is at a different place.
Best regards, Frank
On 07/10/2009, Mika Laitio lamikr@pilppa.org wrote:
Hi, I got interested in from your plugins and tried to read throught your web page to get more info. So if I understood correctly the svdrpservice plugin provides the highway howto communicate from client to vdr server.
But after that I get a little lost what are the cases where I should use your plugins... I mean currently I have 1 vdr server with dvb-t and dvb-c cards, xineliboutput server and streamdev server plugins running on it. Then from other client computers I can use either mplayer or xineliboutput client (vdr-sxfe) for connecting to this server for watching the tv. Currently my setup has however a that kind of limitation that all vdr-sxfe clients are forced to watch the same channel and whenever any of the clients change channel, the channel will be changed also to every other vdr-sxfe clients. I have read this could be somehow be avoided by running multiple vdr servers on the server machine and then forcing each client to connect to own vdr server port...
In the xineliboutput documents directory there is a README file that explains how to setup xineliboutput where each client can watch different channels. You are currently remote viewing the "master vdr" already so no need to use the plugins. If you run vdr on each client then these plugins are of greate use, which you are not, you are only running vdr-sxfe on it's own.
Are your plugins meant for solving a that kind of multiple clients want to
watch different channel problems or for which purpose your are using these plugins?
Mika
-
Frank Schmirler -
Mika Laitio -
Steffen Barszus -
Theunis Potgieter