[mythtv-users] Remote Secondary Backend

[Chris Adams]

On Thu, Jun 17, 2010 at 2:14 PM, Toby Mills <Toby.Mills at vmsl.co.nz> wrote:
>>Back to my original reply.  We don't condone discussions about violations of TOS or sharing of recordingslike this, take this discussion elsewhere. (no >'please' this time)
>
> My question is totally independent of what I am actually using mythtv for but anyway...
> I retract my initial scenario, this is my new totally legal scenario (at least in my country anyway)...
> I have a guesthouse on my property with its own backend. The guesthouse has its own network and is linked to my house via a stable long range wifi link of 24Mbps. The guesthouse has its own backend installed with its own DVB tuner picking up free to air channels. The master backend is in the house with another DVB tuner also picking up free to air channels.
> Clients in the guesthouse should be able to watch recordings from the main house and vice versa.
>
> It would make sense for clients in the guesthouse to stream all their content from the secondary server that was actually in the guesthouse.
> With the current functionality, if a client in the guesthouse watches a program that is stored on the guesthouse server, then the media is pulled from the guesthouse, over the link to the master backend, then streamed directly to the client back over the link. This works but is a waste of bandwidth and is very slow. NFS, Samba & SSHFS network shares work but do not provide the buffering required and are susceptible to occasional choppiness.
>
> Thanks to those who have replied,  I was not aware that the default behaviour was to stream from the recording backend, this actually makes it a little tricker in the above scenario.
> I can actually see a need for 3 scenarios that are only partly covered by current mythtv capabilities.
>
> 1) Stream from the recording backend - This is possible now and is most useful when you have media stored on backends AND the backends are all on the same network segment so it has no impact on network traffic over any particular segments with limited bandwidth.
>
> 2) Stream from Master backend - This is useful if your secondary backends have no storage.
>
> 3) Stream from preferred backend (client setting) - This is useful if your backends are on different network segments where bandwidth will be used inefficiently by any other method.
>
> I can think of a lot of legal examples where it would be preferable to stream traffic from a specific backend other than just the master backend, especially on larger networks where certain segments have limited bandwidth.
>
> Regards
> Toby

Toby,

Raymond gave you the answer: by default it streams from the backend
where the recording was done. Seems to me this will be sufficient to
avoid multiple hops, provided your backends all host their own
storage.

There's a setting to force streaming via the master, which you should
ensure is disabled. I have no idea if that has to be done on the MBE,
all the backends individually, or the frontend.

Cheers
Chris