On 6/9/07, Petri Hintukainen <[EMAIL PROTECTED]> 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" \
server for client 2:
    vdr -c /etc/vdr2 \
        -D 10 \
        -P"xineliboutput --local=none --remote=37892" \
server for client 3:
    vdr -c /etc/vdr3 \
        -D 10 \
        -P"xineliboutput --local=none --remote=37894" \

+ 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:
  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

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 ?


vdr mailing list

Reply via email to