[mythtv-users] MythTV setup distributed over WAN link

[Chris Isip]

You might also want to change the group name for the remote recording (to
maybe , 'Remote')so that they are not mixed with the rest of the local
recordings(Default)  and you wont select with mythfrontend accidentally on a
nonlocal file.  On the master backend, create a batch script and run with
cron  that compares local and remote filesizes  for each individual mpeg
files under the 'Remote' group and then have it change the group name entry
on the recorded table to Default once local and remote file sizes are
equal.  This way if the recording shows up in Default, then you know you
have the complete file locally.

Of course, I could be wrong at so many levels. But this is indeed
interesting.  I might try it myself.



On 10/4/07, Chris Isip <cmisipster at gmail.com> wrote:
>
> It might be possible.   Lets say we have a  slave remote backend and a
> master local backend with each  recording to their own local directories.
> The only difference I think between the entries in recorded will be the
> hostname setting (provided the local directories are similarly named).  If
> you change the hostname setting on ALL the recorded programs to the hostname
> of the master backend, selecting a recording that does not exist locally on
> the master will result in an error message. (Right?)   Now all you need is
> to do an periodic rsync between the two boxes and as soon as the video file
> is transferred to the master backend, you should be able to access it from
> mythfrontend in the same network as the master backend.  You probably just
> want the remote slave backend to sit in a corner and not have anybody mess
> with it.  Rsync has a setting for transfer speed limit with the option
> --bwlimit so you wont hog the bandwidth.  It might be possible...
>
>
>
> On 10/4/07, Blammo <blammo.doh at gmail.com> wrote:
> >
> > On 10/4/07, Taco Mel <taco_mel at yahoo.com> wrote:
> > > I wish to record a small number of shows that are not
> > > available in my area (mainly a couple PBS shows our
> > > local affiliate does not pick up).  I have a spare
> > > machine and tuner card to place at a family member's
> > > home.  My plan is to transfer the files using DVDs or,
> > > when I visit, a portable HDD.  (Or occasionally a
> > > network copy in the middle of the night.)
> > >
> > > My first thought was to set the remote machine up as a
> > > completely isolated MythTV system, with its own
> > > database, and occasionally log in to it remotely by
> > > SSH to check things out or burn files to a DVD.  I'll
> > > then have *.mpg files that I can somehow import into
> > > MythTV.  Somehow I will then have to construct
> > > metadata.
> > >
> > > My second thought was to integrate the remote system
> > > into my existing MythTV setup so that I can manage and
> > > monitor the entire system from one place.  I'll set up
> > > OpenVPN between the sites, which I have done before
> > > for various projects so that's no problem.  I believe
> > > that I will then have all the metadata and when I move
> > > the corresponding *.mpg file into one of my storage
> > > groups, it will stream from my local backend.
> > >
> > > However, I *do not* want my local frontends to try to
> > > stream a program from the remote backend, because it
> > > either will be too slow to work, or it will use enough
> > > bandwidth that said family member might no longer be
> > > willing to host said remote backend.
> >
> > I'm thinking a combination of:
> > -- "master backend override" to force streaming from the "master"
> > -- "commflag/transcode only on recording backend"
> > -- rsync over a reasonable WAN
> >
> > and you could probably run a completely remote backend. Nice idea,
> > makes me tempted to try..
> > _______________________________________________
> > mythtv-users mailing list
> > mythtv-users at mythtv.org
> > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20071004/fe599f18/attachment.htm