Hi again,
Can someone give me some guidance on how to confgure the following;
I have a central machine running vdr 1.4.6 (has all the recording storage and dvb cards)
I have several networked vdr machines that i want to use to connect back to the 'server' vdr machine. The networked vdr machines will have no dvb cards (they will all be located at the vdr server). How do i configure my vdr client machines to connect back to the server vdr machine and use its dvb cards/recording storage etc?
Can anyone give some guidance on this type of setup or point me at a url where I can find out about such a config?
Thanks in advance.
Andrew
On Sat, 2007-06-09 at 18:15 +0100, Andrew Herron wrote:
I have several networked vdr machines that i want to use to connect back to the 'server' vdr machine. The networked vdr machines will have no dvb cards (they will all be located at the vdr server). How do i configure my vdr client machines to connect back to the server vdr machine and use its dvb cards/recording storage etc?
Can anyone give some guidance on this type of setup or point me at a url where I can find out about such a config?
If you don't watch different recordings / channels at the same time you can just run vdr-sxfe at each client and connect to the single VDR server. You'll get same video + OSD mirrored to all locations.
But, if you need to have independently controlled clients with own video and OSD, you need to run several instances of VDR - it doesn't matter if you run all VDR instances on server or at each client. I run several VDR instances on the server: - less maintenance, only one installation of VDR and plugins required - allows using diskless clients (and with less memory) - Faster cutting / DVD burning / ... as there is no network between VDR and disks - no need to export/mount /video to every client - ...
Here's how I do it:
master VDR: DVB cards, recordings, server for client 1: vdr -c /etc/vdr \ -P"xineliboutput --local=none --remote=37890" \ -Pstreamdev-server server for client 2: vdr -c /etc/vdr2 \ -D 10 \ -P"xineliboutput --local=none --remote=37892" \ -Pstreamdev-client server for client 3: vdr -c /etc/vdr3 \ -D 10 \ -P"xineliboutput --local=none --remote=37894" \ -Pstreamdev-client
+ other options / plugins you normally use.
Using -D 10 option for client VDR instances "forces" all DVB cards for master VDR. Streamdev plugin is used to provide live view for client VDR's, it is not required to just watch recordings. You must use separate configuration directory for each VDR (-c option). Without it you'll most likely break all recordings (all VDRs record all timers in paraller to same recording directory).
And at clients: Client 1: vdr-sxfe Client 2: vdr-sxfe xvdr://<server ip>:37892 Client 3: vdr-sxfe xvdr://<server ip>:37894
If you use RTP between vdr and vdr-sxfe, using separate RTP address or port for each xineliboutput server instance might be good idea.
Also it might be good idea to disable recording at all but the "master" vdr. Recording the same timer on two VDR instances will most likely corrupt whole recording. Besides that, doing all recordings directly from DVB card (no streamdev in middle) makes things simpler and less error prone. It is probably even impossible to do several recordings from different transponders using single streamdev instance. I use timersync plugin to disables recording on client VDRs. All timers are still visible at each client and you can create/modify timers at any client just as before. Plugin synchronizes all modifications to timers between VDR instances and takes care that all recordings are made only by "master" vdr. Still, if you have some kind of autotimer plugins etc. that generate timers automatically it might be better to run those only at server vdr...
- Petri
On 6/9/07, Petri Hintukainen phintuka@users.sourceforge.net wrote:If you don't watch different recordings / channels at the same time you
can just run vdr-sxfe at each client and connect to the single VDR server. You'll get same video + OSD mirrored to all locations.
But, if you need to have independently controlled clients with own video and OSD, you need to run several instances of VDR - it doesn't matter if you run all VDR instances on server or at each client. I run several VDR instances on the server:
- less maintenance, only one installation of VDR and plugins required
- allows using diskless clients (and with less memory)
- Faster cutting / DVD burning / ... as there is no network between VDR and disks
- no need to export/mount /video to every client
- ...
Here's how I do it:
master VDR: DVB cards, recordings, server for client 1: vdr -c /etc/vdr \ -P"xineliboutput --local=none --remote=37890" \ -Pstreamdev-server server for client 2: vdr -c /etc/vdr2 \ -D 10 \ -P"xineliboutput --local=none --remote=37892" \ -Pstreamdev-client server for client 3: vdr -c /etc/vdr3 \ -D 10 \ -P"xineliboutput --local=none --remote=37894" \ -Pstreamdev-client
- other options / plugins you normally use.
Using -D 10 option for client VDR instances "forces" all DVB cards for master VDR. Streamdev plugin is used to provide live view for client VDR's, it is not required to just watch recordings. You must use separate configuration directory for each VDR (-c option). Without it you'll most likely break all recordings (all VDRs record all timers in paraller to same recording directory).
And at clients: Client 1: vdr-sxfe Client 2: vdr-sxfe xvdr://<server ip>:37892 Client 3: vdr-sxfe xvdr://<server ip>:37894
If you use RTP between vdr and vdr-sxfe, using separate RTP address or port for each xineliboutput server instance might be good idea.
Also it might be good idea to disable recording at all but the "master" vdr. Recording the same timer on two VDR instances will most likely corrupt whole recording. Besides that, doing all recordings directly from DVB card (no streamdev in middle) makes things simpler and less error prone. It is probably even impossible to do several recordings from different transponders using single streamdev instance. I use timersync plugin to disables recording on client VDRs. All timers are still visible at each client and you can create/modify timers at any client just as before. Plugin synchronizes all modifications to timers between VDR instances and takes care that all recordings are made only by "master" vdr. Still, if you have some kind of autotimer plugins etc. that generate timers automatically it might be better to run those only at server vdr...
- Petri
Hi Petri,
Thanks for providing exactly the info I needed. Much appreciated indeed :-)
Andrew
On 6/9/07, Petri Hintukainen phintuka@users.sourceforge.net wrote:
On Sat, 2007-06-09 at 18:15 +0100, Andrew Herron wrote:
I have several networked vdr machines that i want to use to connect back to the 'server' vdr machine. The networked vdr machines will have no dvb cards (they will all be located at the vdr server). How do i configure my vdr client machines to connect back to the server vdr machine and use its dvb cards/recording storage etc?
Can anyone give some guidance on this type of setup or point me at a url where I can find out about such a config?
If you don't watch different recordings / channels at the same time you can just run vdr-sxfe at each client and connect to the single VDR server. You'll get same video + OSD mirrored to all locations.
But, if you need to have independently controlled clients with own video and OSD, you need to run several instances of VDR - it doesn't matter if you run all VDR instances on server or at each client. I run several VDR instances on the server:
- less maintenance, only one installation of VDR and plugins required
- allows using diskless clients (and with less memory)
- Faster cutting / DVD burning / ... as there is no network between VDR and disks
- no need to export/mount /video to every client
- ...
Here's how I do it:
master VDR: DVB cards, recordings, server for client 1: vdr -c /etc/vdr \ -P"xineliboutput --local=none --remote=37890" \ -Pstreamdev-server server for client 2: vdr -c /etc/vdr2 \ -D 10 \ -P"xineliboutput --local=none --remote=37892" \ -Pstreamdev-client server for client 3: vdr -c /etc/vdr3 \ -D 10 \ -P"xineliboutput --local=none --remote=37894" \ -Pstreamdev-client
- other options / plugins you normally use.
Using -D 10 option for client VDR instances "forces" all DVB cards for master VDR. Streamdev plugin is used to provide live view for client VDR's, it is not required to just watch recordings. You must use separate configuration directory for each VDR (-c option). Without it you'll most likely break all recordings (all VDRs record all timers in paraller to same recording directory).
And at clients: Client 1: vdr-sxfe Client 2: vdr-sxfe xvdr://<server ip>:37892 Client 3: vdr-sxfe xvdr://<server ip>:37894
If you use RTP between vdr and vdr-sxfe, using separate RTP address or port for each xineliboutput server instance might be good idea.
Also it might be good idea to disable recording at all but the "master" vdr. Recording the same timer on two VDR instances will most likely corrupt whole recording. Besides that, doing all recordings directly from DVB card (no streamdev in middle) makes things simpler and less error prone. It is probably even impossible to do several recordings from different transponders using single streamdev instance. I use timersync plugin to disables recording on client VDRs. All timers are still visible at each client and you can create/modify timers at any client just as before. Plugin synchronizes all modifications to timers between VDR instances and takes care that all recordings are made only by "master" vdr. Still, if you have some kind of autotimer plugins etc. that generate timers automatically it might be better to run those only at server vdr...
- Petri
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi Petri,
I have few questions after testing your suggestions above to achieve independently controlled clients with their own video and OSD;
I would like all recordings to be managed/controlled by the master vdr as this would seem to be the best solution. However if I have say a single twin tuner DVB-T card and the master vdr is controlling all recordings is it still possible for the remote clients to schedule a recording via the master vdr if the timersync plugin is used? I think that you are saying this is possible... which is great!
I have created separate /etc/vdr2 & /etc/vdr3 directories by copying /etc/vdr Will this work ok? As both /etc/vdr3 & /etc/vdr3 are exact copies of /etc/vdr without any changes in the conf files etc. Is this what you meant or do i need to make any changes in /etc/vdr3 & /etc/vdr3 ?
Cheers
Andrew
On Sun, 2007-06-10 at 14:15 +0100, Andrew Herron wrote:
I would like all recordings to be managed/controlled by the master vdr as this would seem to be the best solution. However if I have say a single twin tuner DVB-T card and the master vdr is controlling all recordings is it still possible for the remote clients to schedule a recording via the master vdr if the timersync plugin is used? I think that you are saying this is possible... which is great!
Ÿes. All timer stuff works just as when using single VDR - if you set a timer at any client, it is immediately transferred to server (and visible to all other clients too). Plugin monitors timers state and synchronices all timer changes between VDR instances. Only master vdr does recordings, recording is completely disabled at all client VDRs (there's no way to record anything on client VDR even if one wants to).
There's one restriction: With timersync you can't (at least yet) modify timers that are currently recording - such timers can be modified only at master VDR.
I have created separate /etc/vdr2 & /etc/vdr3 directories by copying /etc/vdr Will this work ok?
Yes. Maybe you need to configure streamdev server address (127.0.0.1) for clients, but you can do that from client setup menu when you have client running.
Be sure to empty all client VDR timers.conf files, if timersync refuses to load etc. you might end up having N*3 recordings running immediately at startup :)
One more thing: using suspendoutput plugin with some proper timeout value in every VDR instance might be good idea - it releases streamdev VTP connection and server-side DVB devices for other use when the client is not in use.
- Petri
On 09/06/07, Petri Hintukainen phintuka@users.sourceforge.net wrote:
On Sat, 2007-06-09 at 18:15 +0100, Andrew Herron wrote:
I have several networked vdr machines that i want to use to connect back to the 'server' vdr machine. The networked vdr machines will have no dvb cards (they will all be located at the vdr server). How do i configure my vdr client machines to connect back to the server vdr machine and use its dvb cards/recording storage etc?
Can anyone give some guidance on this type of setup or point me at a url where I can find out about such a config?
If you don't watch different recordings / channels at the same time you can just run vdr-sxfe at each client and connect to the single VDR server. You'll get same video + OSD mirrored to all locations.
But, if you need to have independently controlled clients with own video and OSD, you need to run several instances of VDR - it doesn't matter if you run all VDR instances on server or at each client. I run several VDR instances on the server:
- less maintenance, only one installation of VDR and plugins required
- allows using diskless clients (and with less memory)
- Faster cutting / DVD burning / ... as there is no network between VDR and disks
- no need to export/mount /video to every client
- ...
Here's how I do it:
master VDR: DVB cards, recordings, server for client 1: vdr -c /etc/vdr \ -P"xineliboutput --local=none --remote=37890" \ -Pstreamdev-server server for client 2: vdr -c /etc/vdr2 \ -D 10 \ -P"xineliboutput --local=none --remote=37892" \ -Pstreamdev-client server for client 3: vdr -c /etc/vdr3 \ -D 10 \ -P"xineliboutput --local=none --remote=37894" \ -Pstreamdev-client
- other options / plugins you normally use.
Using -D 10 option for client VDR instances "forces" all DVB cards for master VDR. Streamdev plugin is used to provide live view for client VDR's, it is not required to just watch recordings. You must use separate configuration directory for each VDR (-c option). Without it you'll most likely break all recordings (all VDRs record all timers in paraller to same recording directory).
And at clients: Client 1: vdr-sxfe Client 2: vdr-sxfe xvdr://<server ip>:37892 Client 3: vdr-sxfe xvdr://<server ip>:37894
If you use RTP between vdr and vdr-sxfe, using separate RTP address or port for each xineliboutput server instance might be good idea.
Also it might be good idea to disable recording at all but the "master" vdr. Recording the same timer on two VDR instances will most likely corrupt whole recording. Besides that, doing all recordings directly from DVB card (no streamdev in middle) makes things simpler and less error prone. It is probably even impossible to do several recordings from different transponders using single streamdev instance. I use timersync plugin to disables recording on client VDRs. All timers are still visible at each client and you can create/modify timers at any client just as before. Plugin synchronizes all modifications to timers between VDR instances and takes care that all recordings are made only by "master" vdr. Still, if you have some kind of autotimer plugins etc. that generate timers automatically it might be better to run those only at server vdr...
This system is just what I'm looking to create, however I have one or two questions. (As usual..)
Is it possible to have one of the VDR 'servers/instances' to be running on one of the clients rather than the main server pc? The exact same setup except Client2 has an instance of VDR running in the background with 1 dvb card saving files to the server's /video mounted over nfs.
Ideally all Clients + Master VDR Server will see channels on Client 2's satellite feed and be able to register timers on that server.
If there was a way for PCI buses to traverse networks, then the location of the 3rd card wouldn't be an issue, but I don't believe that's possible...
There is currently no way for me to have all 3 DVB cards in the same box.
On Wed, 2007-06-13 at 19:16 +0100, Alasdair Campbell wrote:
Is it possible to have one of the VDR 'servers/instances' to be running on one of the clients rather than the main server pc?
Yes. Then you don't need the -D option.
The exact same setup except Client2 has an instance of VDR running in the background with 1 dvb card saving files to the server's /video mounted over nfs. Ideally all Clients + Master VDR Server will see channels on Client 2's satellite feed and be able to register timers on that server.
This is more complicated :)
I think you need to set every timer manually to the system where it is supposed to be recorded. Timersync won't work as it disables all recording at client(s). Using timersync and enabling recording at the client won't work if you use streamdev: both systems will see the same channels and would record the same timers in paraller.
Maybe something like this might work: VDR1: (2x DVB-?): streamdev-server, streamdev-client connected to VDR2 VDR2: (1x DVB-S): streamdev-server, streamdev-client connected to VDR1 VDR3: (no DVB): 2 instances of streamdev-client: one connected to VDR1 and another to VDR2.
Note that circular streamdev setup doesn't work without patching ( http://www.vdr-developer.org/mantisbt/view.php?id=198 )
If there was a way for PCI buses to traverse networks, then the location of the 3rd card wouldn't be an issue, but I don't believe that's possible...
No, but transferring the device interface (/dev/dvb/...) over network is possible with something like nbd (network block device). I think I saw similar redirector for DVB devices few years ago: http://linuxtv.org/mailinglists/linux-dvb/2004/08-2004/msg00326.html But it seems quite old and unmaintained.
- Petri
On 16/06/07, Petri Hintukainen phintuka@users.sourceforge.net wrote:
On Wed, 2007-06-13 at 19:16 +0100, Alasdair Campbell wrote:
Is it possible to have one of the VDR 'servers/instances' to be running on one of the clients rather than the main server pc?
Yes. Then you don't need the -D option.
The exact same setup except Client2 has an instance of VDR running in the background with 1 dvb card saving files to the server's /video mounted over nfs. Ideally all Clients + Master VDR Server will see channels on Client 2's satellite feed and be able to register timers on that server.
This is more complicated :)
I think you need to set every timer manually to the system where it is supposed to be recorded. Timersync won't work as it disables all recording at client(s). Using timersync and enabling recording at the client won't work if you use streamdev: both systems will see the same channels and would record the same timers in paraller.
Maybe something like this might work: VDR1: (2x DVB-?): streamdev-server, streamdev-client connected to VDR2 VDR2: (1x DVB-S): streamdev-server, streamdev-client connected to VDR1 VDR3: (no DVB): 2 instances of streamdev-client: one connected to VDR1 and another to VDR2.
Note that circular streamdev setup doesn't work without patching ( http://www.vdr-developer.org/mantisbt/view.php?id=198 )
If there was a way for PCI buses to traverse networks, then the location of the 3rd card wouldn't be an issue, but I don't believe that's possible...
No, but transferring the device interface (/dev/dvb/...) over network is possible with something like nbd (network block device). I think I saw similar redirector for DVB devices few years ago: http://linuxtv.org/mailinglists/linux-dvb/2004/08-2004/msg00326.html But it seems quite old and unmaintained.
I remember reading about this years ago, if it could work then it would be ideal for my situation - maybe for others too. Vadim Epmak's address is bouncing so I'll ask on the DVB mailing list and see if anyone else ever got it up and running.
I'm keen on trying it out myself, and have started reading about porting drivers to 2.6 kernels. Could be an interesting way to learn more C ;-)
On 18/06/07, Alasdair Campbell ragawu@gmail.com wrote:
On 16/06/07, Petri Hintukainen phintuka@users.sourceforge.net wrote:
On Wed, 2007-06-13 at 19:16 +0100, Alasdair Campbell wrote:
Is it possible to have one of the VDR 'servers/instances' to be running on one of the clients rather than the main server pc?
Yes. Then you don't need the -D option.
The exact same setup except Client2 has an instance of VDR running in the background with 1 dvb card saving files to the server's /video mounted over nfs. Ideally all Clients + Master VDR Server will see channels on Client 2's satellite feed and be able to register timers on that server.
This is more complicated :)
I think you need to set every timer manually to the system where it is supposed to be recorded. Timersync won't work as it disables all recording at client(s). Using timersync and enabling recording at the client won't work if you use streamdev: both systems will see the same channels and would record the same timers in paraller.
Maybe something like this might work: VDR1: (2x DVB-?): streamdev-server, streamdev-client connected to VDR2 VDR2: (1x DVB-S): streamdev-server, streamdev-client connected to VDR1 VDR3: (no DVB): 2 instances of streamdev-client: one connected to VDR1 and another to VDR2.
Note that circular streamdev setup doesn't work without patching ( http://www.vdr-developer.org/mantisbt/view.php?id=198 )
If there was a way for PCI buses to traverse networks, then the location of the 3rd card wouldn't be an issue, but I don't believe that's possible...
No, but transferring the device interface (/dev/dvb/...) over network is possible with something like nbd (network block device). I think I saw similar redirector for DVB devices few years ago: http://linuxtv.org/mailinglists/linux-dvb/2004/08-2004/msg00326.html But it seems quite old and unmaintained.
I remember reading about this years ago, if it could work then it would be ideal for my situation - maybe for others too. Vadim Epmak's address is bouncing so I'll ask on the DVB mailing list and see if anyone else ever got it up and running.
I'm keen on trying it out myself, and have started reading about porting drivers to 2.6 kernels. Could be an interesting way to learn more C ;-)
In hindsight, I believe learning C on my own by porting a driver to the 2.6 kernel was a tad optimistic..
Sill won't compile, and I haven't got to grips with the changes in the dvb api from when this was written.
No response yet on the linuxtv list. I'll keep working at the code - it could be a fun way to learn, and the principle seems quite straight-forward.
Hi,
yesterday evening i followed your setup to create 1 client. Server : VDR & VDR2 server Client : vdr-sxfe
When i run the second VDR server i can't switch channels. It's bloked on channels attached to the first transponder (hope you understand what i mean). plz help...
cheers, 'Z
2007/6/28, Alasdair Campbell ragawu@gmail.com:
On 18/06/07, Alasdair Campbell ragawu@gmail.com wrote:
On 16/06/07, Petri Hintukainen phintuka@users.sourceforge.net wrote:
On Wed, 2007-06-13 at 19:16 +0100, Alasdair Campbell wrote:
Is it possible to have one of the VDR 'servers/instances' to be running on one of the clients rather than the main server pc?
Yes. Then you don't need the -D option.
The exact same setup except Client2 has an instance of VDR running
in the
background with 1 dvb card saving files to the server's /video
mounted
over nfs. Ideally all Clients + Master VDR Server will see channels on Client 2's satellite feed and be able to register timers on that server.
This is more complicated :)
I think you need to set every timer manually to the system where it is supposed to be recorded. Timersync won't work as it disables all recording at client(s). Using timersync and enabling recording at the client won't work if you use streamdev: both systems will see the same channels and would record the same timers in paraller.
Maybe something like this might work: VDR1: (2x DVB-?): streamdev-server, streamdev-client connected to VDR2 VDR2: (1x DVB-S): streamdev-server, streamdev-client connected to VDR1 VDR3: (no DVB): 2 instances of streamdev-client: one connected to VDR1 and another
to
VDR2.
Note that circular streamdev setup doesn't work without patching ( http://www.vdr-developer.org/mantisbt/view.php?id=198 )
If there was a way for PCI buses to traverse networks, then the location of the 3rd card wouldn't be an issue, but I don't believe that's possible...
No, but transferring the device interface (/dev/dvb/...) over network
is
possible with something like nbd (network block device). I think I saw similar redirector for DVB devices few years ago: http://linuxtv.org/mailinglists/linux-dvb/2004/08-2004/msg00326.html But it seems quite old and unmaintained.
I remember reading about this years ago, if it could work then it would be ideal for my situation - maybe for others too. Vadim Epmak's address is bouncing so I'll ask on the DVB mailing list and see if anyone else ever got it up and running.
I'm keen on trying it out myself, and have started reading about porting drivers to 2.6 kernels. Could be an interesting way to learn more C ;-)
In hindsight, I believe learning C on my own by porting a driver to the 2.6 kernel was a tad optimistic..
Sill won't compile, and I haven't got to grips with the changes in the dvb api from when this was written.
No response yet on the linuxtv list. I'll keep working at the code - it could be a fun way to learn, and the principle seems quite straight-forward.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Petri Hintukainen wrote:
But, if you need to have independently controlled clients with own video and OSD, you need to run several instances of VDR - it doesn't matter if you run all VDR instances on server or at each client. I run several VDR instances on the server:
- less maintenance, only one installation of VDR and plugins required
- allows using diskless clients (and with less memory)
- Faster cutting / DVD burning / ... as there is no network between VDR and disks
- no need to export/mount /video to every client
- ...
Nice setup! What kind of remote control do you use on the clients running xine and how does it work to send the command to the vdr session?
Simon
On Sun, 2007-06-17 at 12:48 +0200, Simon Natterer wrote:
Petri Hintukainen wrote:
But, if you need to have independently controlled clients with own video and OSD, you need to run several instances of VDR - it doesn't matter if you run all VDR instances on server or at each client. I run several VDR instances on the server:
- less maintenance, only one installation of VDR and plugins required
- allows using diskless clients (and with less memory)
- Faster cutting / DVD burning / ... as there is no network between VDR and disks
- no need to export/mount /video to every client
- ...
Nice setup! What kind of remote control do you use on the clients running xine and how does it work to send the command to the vdr session?
LIRC, vdr-sxfe forwards LIRC commands from remote system to VDR (--lirc option). Keyboard works too, and I belive any device accessible thru /dev/event interface should work with evdev <-> lirc forwarding daemon.
- Petri
Petri Hintukainen wrote:
I use timersync plugin to disables recording on client VDRs. All timers are still visible at each client and you can create/modify timers at any client just as before. Plugin synchronizes all modifications to timers between VDR instances and takes care that all recordings are made only by "master" vdr.
Are there solutions to similarly synchronize preferably in real time channels.conf (the satellite crap is managed by autosort plugin in my setup) and recordings listing? I'm using a slightly different setup compared to your idea where I need to regularly kill the clients and copy the channels.conf from main vdr box. Recordings list gets updated when a client restarts. These limitations are currently causing confusion in my family.
Best regards, Seppo
-
Alasdair Campbell -
Andrew Herron -
Petri Hintukainen -
Seppo Ingalsuo -
Simon Natterer -
Sébastien Serra