[mythtv-users] How to force frontends to play only from master backend?

[Harry Coin]

John Finlay wrote:
> Harry Coin wrote:
>> Michael T. Dean wrote:
>>> On 03/15/2009 05:08 PM, Nick Rout wrote:
>>>> On Mon, Mar 16, 2009 at 9:42 AM, William 
>>>> <william_munson at comcast.net> wrote:
>>>>  
>>>>> Harry Coin wrote:
>>>>>  
>>>>>> Using 0.21 I need help to cause frontends to play from the 
>>>>>> 'masterbackend'
>>>>>> only, even though diskless other slave backends that received and 
>>>>>> stored the
>>>>>> shows are running on the same little net.
>>>>>>
>>>>>> I have some older, slower diskless PC's acting as slave 
>>>>>> backends.  These
>>>>>> were just supposed to catch the video and put it on the common 
>>>>>> nfs share,
>>>>>> never host playbacks.   There is a master backend that has an NFS 
>>>>>> share that
>>>>>> all the frontends and backends can access.  The masterbackend is 
>>>>>> fast, has
>>>>>> quick disks and has a fast network connection.
>>>>>>
>>>>>> But, I've proven that the frontends actually don't actually pull 
>>>>>> from the
>>>>>> master backend either stream or nfs, but contact the slave 
>>>>>> backend that
>>>>>> recorded the video, cause that little underpowered thing to pull 
>>>>>> the video
>>>>>> from the nfs share, then stream it out to the frontend.    So, bad
>>>>>> performance, choppy playback, dropped frames on recording and so on.
>>>>>>
>>>>>> So, I really need to turn off any kind of playback activity / 
>>>>>> streaming
>>>>>> from all the diskless slave backends - but to have them still be 
>>>>>> running to
>>>>>> host the tuner cards and record shows.   Help please!
>>>>>>
>>>>>> Last, I'd appreciate some guidance about whether the frontends 
>>>>>> would do
>>>>>> better to use NFS to playback from the server, or cause the 
>>>>>> server to stream
>>>>>> -- and tell me how to direct the frontends to implement that 
>>>>>> decision.
>>>>>>       
>>>>> There is an option to always stream from the backend with a check 
>>>>> box on one
>>>>> of the setup screens, Sorry but I am not able to get to the system 
>>>>> right now
>>>>> to give the specifics
>>>>>
>>>>> I think its in mythtv-setup rather than the frontend setup.
>>>>>     
>>>> I think its in frontend setup as I just noticed it when setting up a
>>>> new frontend yesterday.
>>>>
>>>> However I am not sure that it achieves the aim of "always stream from
>>>> the MASTER backend rather than the backend that recorded it"
>>>
>>> Right, Nick.  The mythfrontend setting is:
>>>
>>> Always stream recordings from the backend
>>> Enable this setting if you want MythTV to always stream files from a 
>>> remote backend instead of directly reading a recording file if it is 
>>> accessible locally.
>>>
>>> and it makes the recording host stream the show.
>>>
>>> There's also the mythtv-setup setting:
>>>
>>> Master Backend Override
>>> If enabled, the master backend will stream and delete files if it 
>>> finds them in the video directory. Useful if you are using a central 
>>> storage location, like a NFS share, and your slave backend isn't 
>>> running.
>>>
>>> but that would only make the master backend stream the files if you 
>>> shutdown the recording host.
>>>
>>> However, if you have a "local" copy of the file available to the 
>>> frontend--i.e. a copy of the file on a filesystem that's directly 
>>> accessible by the frontend (which means NFS mounts are "local")--the 
>>> frontend will read the file directly from the disk (which would mean 
>>> from NFS).
>>>
>>> In your test, it didn't do so because you either had enabled the 
>>> setting, "Always stream recordings from the backend", or your 
>>> filesystem is using a different structure on the frontend from the 
>>> backend(s).  So, uncheck that option and/or make the directory 
>>> structure of the recording directories /exactly/ identical on /all/ 
>>> hosts (backends and frontends), and all will work.
>>>
>>> Mike
>>>
>>> _______________________________________________
>>> mythtv-users mailing list
>>> mythtv-users at mythtv.org
>>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>>>
>> Thanks to all for these insights.    To sum it all up, when is more 
>> than one backend but only the master has fast disks holding all the 
>> files and fast networking there are two choices.
>>
>> A:  Preserve the benefits of mythtv backend streaming, avoid exposing 
>> the filesystem to the frontends via nfs, presumably gain the benefit 
>> of whatever other frontends may speak the streaming protocols all by 
>> ferreting out a mysql update command to cause all shows to point to 
>> the master backend as the source for all shows and running it on a 
>> ten minute schedule as a cronjob.
>>
>> B:  Turn off the 'always stream' setting in the frontend, turn off 
>> the 'master backend can stream if the others are taking a nappy' 
>> setting in the backend, export the source of all files to the 
>> frontends via nfs in exactly the same access path fashion as the 
>> backends use to write them.  Then the frontends will default through 
>> and use nfs to play the shows defacto fetching them from the nfs 
>> servers running on the master backend.
>>
>> I think on balance 'A' is the better choice to keep overall 
>> complexity down as far as hacking settings on frontends re: nfs and 
>> overall maintainability.    I think changing the backend setting from 
>> a toggle to 'stream from master if slave backends are sleeping or 
>> not' to a three state:  'always stream from master backend when 
>> possible, only if slave is snoozing, never' would be better! Thanks 
>> all again
>>
>> Harry
> If you have videos you have to set up NFS access on the frontends to 
> play them which tips the balance to scenario 'B'.
>
> John
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
Thanks for the further thoughts on this question.   I wasn't aiming to 
generate irritation or feature bloat as I think the previous responder 
feared.   As it happens there aren't many videos involved here, they 
don't change very often, aren't used much and they aren't in the same 
directory / disk structure as the captured video shows.   It just seems 
that as there already is a feature that allows the master backend to 
stream files if the slave is missing, turning that 'off / on' feature 
into an 'always/ only if missing slave / never : stream from the master 
backend' feature wasn't going to create stress.

Really I was just trying to avoid having to maintain network mounts on 
frontends (they come, they go, who knows who is using them), and also 
avoid the really bad idea of having a backend pull video over its nfs 
mount from the server in order to turn around and stream it back over 
the same cable to the frontend.  

I started with such a simple plan when I cooked up this little system -- 
it just happens here that it was much better for reception and reception 
cabling / converter box issues to put some little diskless backends near 
to the point of entry of the antenna / dish gear, then have all the 
video from whatever source just make it to the server via one easy no 
fuss network cable.     All the front ends could do or be whatever they 
were, and would just get their content from the server.   Thought it 
would have been easy. 

At one point I was even going to put the backends on their own little 
subnet physically separated from the frontends and use an added lan card 
on the server just dedicated to slave backend management, but I couldn't 
get the frontends to play the shows at all in that instance.

Anyhow, hope this discussion sparks improvement down the road.

Harry