[mythtv-users] Best Way to Run Commercial Detection Jobs Not On Master Backend

Michael T. Dean mtdean at thirdcontact.com
Wed Jan 29 02:54:05 UTC 2014


On 01/28/2014 12:45 PM, Stephen P. Villano wrote:
> On 1/28/14, 8:57 AM, Michael T. Dean wrote:
>> On 01/28/2014 08:20 AM, Raymond Wagner wrote:
>>> On 01/27/14 23:15, Stephen P. Villano wrote:
>>>> On 1/28/14, 12:49 AM, Raymond Wagner wrote:
>>>>> On 01/27/14 20:09, Hika van den Hoven wrote:
>>>>>> On the master, but for the slave it doesn't matter.
>>>>> If you're recording on your slave backend (and you should be, because
>>>>> otherwise there's no reason to have a slave backend), then frontends
>>>>> must be able to connect to it to stream recordings made on it.
>>>>>
>>>> My slave BE is more for additional storage. The machine is far slower
>>>> than my primary BE and it has far less RAM.
>>>> Most of my heavy data handling is done from the primary BE.
>>> Ideally, rather than run another full backend, you would just run
>>> mythmediaserver. However it seems it may be suffering code rot, and
>>> crashes at the end of a file transfer.
>> Or, if it's just for storage, NFS or CIFS (which actually allow
>> writing as well as reading)...
> True. Initially, I had it set up for NFS, read-write.
> But, this way leaves me with additional processing ability, as that is
> an older dual Xeon processor workstation.
> So, I get the best of both worlds.
> I can transcode on both, lowering total transcode time for multiple
> programs.
>
> Architecture:
> Dell 2850 primary BE
> Dell Precision 530-MT secondary BE
> Varied FE's.

I'd still recommend NFS for read/write storage and mythjobqueue for 
running jobs.  It's literally 1/10 the resources of running a remote 
backend (not to mention the whole mythbackend expects to have tuners part).

That said, you'll need to get backend configuration finished, 
regardless, as configuring mythjobqueue takes exactly the same 
configuration as configuring mythbackend (the only difference is which 
application you run when you finish configuring).

Mike


More information about the mythtv-users mailing list