I have read through the MCEBuddy 2.x Remote Client Guide.docx, but am still confused. Can someone explain what the use case is?
Is it to push CPU crunching to a second machine so that your current machine is not so taxed?
Is it to divide and conquer conversions, e.g. Computer A, which is monitoring for new conversion jobs, sends the first job to Computer B, then starts converting the second job on the queue. When either A or B finishes a job, it is assigned the next job in the queue, until the job queue is empty?
Using the naming convention in (2), which machine (A or B) is considered the “remote client”?
I will reply to my own question, as it was mostly answered in a different thread:
Both use cases 1 and 2 in my original question were wrong.
(I my defense, I have yet to read somewhere that clearly explains why you would want to have a remote engine. I’m sure it is somewhere, but I’ve been looking for the last few days, searching this forum, the local documentation, and the Googles.)
Remote engines appear to be a simple monitoring utility. You would independently set up a conversion task on Computer A. You can then, from Computer B, run a remote client app (available as a separate zip file for the latest beta 2.4.9) that simply monitors the conversion task on Computer A. Thus while sitting at Computer B, you need not keep looking at Computer A to monitor Computer A’s conversion process.
Yes, it makes sense. Always weird how much naming can shape your assumptions.
I assumed a remote engine would be a service on another system where you could temp load a local file and let that remote computer convert your file for you.
Sounds like this is really meant as a remote monitor. It seems weird that you would have essentially the entire gui there if all you are doing on the remote client is monitor progress. If I were more involved, I might push for a change in the naming convention. But it is your party, and I’m overall enjoying it.