[mythtv-users] different versions on frontend and backend

[Michael T. Dean]

Robert Johnston wrote:

>On 30/10/05, Michael T. Dean <mtdean at thirdcontact.com> wrote:
>  
>
>>Robert Johnston wrote:
>>    
>>
>>>Incorrect. You can pass --disable-frontend and/or --disable-backend if
>>>you want to make a FE-Only or BE-Only machine.
>>>
>>Yeah, if you don't want it to build.  Those are porting only
>>options--they are /not/ valid options on Linux.  See
>>http://svn.mythtv.org/trac/browser/trunk/mythtv/configure?rev=7650 lines
>>2740 and 2747--and especially lines 2741 and 2748.
>>    
>>
>These USED to be valid options to build a front-end only system (As it
>seems very wasteful to have to build the whole of the backend, just to
>never use it, especially on something like an XBOX-frontend, which
>will NEVER be able to offer backend functionality, and building the
>binaries (As well as keeping them) will only waste CPU time and HDD
>space).
>
>These were changed in Rev. 7577 to add the warnings mentioned above,
>  
>
Right, but the warnings were added because of the sheer number of 
posts/tickets where people reported that they couldn't build their 
"lightweight" MythTV system using "--disable-backend" or 
"--disable-frontend".

Here's the commit message where the options were first added.  Note the 
"so it should be considered as something useful only for porting the 
backend," and "The basic aim here" parts.
http://www.gossamer-threads.com/lists/mythtv/commits/136628#136628

>and TBH I think changing this breaks the whole "Client-Server"
>functionality that Myth is supposed to be promoting, with independant
>multiple frontends and multiple backends. It used to be that a backend
>machine didn't require the behemoth that is X to compile, or run, but
>with these dependancies, it makes what should be a small(er) program
>with only the dependancies on what it needs become a huge thing that's
>not efficient at all.
>  
>
AIUI, Isaac has (rightly, IMHO) taken the stance that a "few" extra 
megabytes of installed applications on a system that processes 
multi-gigabyte files does not provide sufficient cause to justify the 
work entailed in separating the two such that each is completely 
independent of the other.  If you really want that lightweight frontend 
or backend, though, feel free to submit patches.  ;)

>>>>As a matter of fact, the same applies to
>>>>mythplugins--you need the same version of mythplugins as the version of
>>>>mythtv.
>>>>
>>>That's also incorrect. MythPlugins have to be built against the same
>>>version of libMyth, but you can take an old version of the plugins
>>>source, as long as it's built against the same version of libMyth as
>>>the MythFrontend you are wanting to load them from.
>>>
>>Unless there are changes that break compatibility.  This includes
>>incompatible changes to the myth protocol version, the DB schema
>>version, the libraries used by the plugins (i.e.
>>http://svn.mythtv.org/trac/ticket/531 ), and ...
>>    
>>
>In thoery, each "Plugin" should handle it's own "DB Schema", as they
>should be interchangeable. IOW, MythWeather should not be touching
>MythVideo's DB entries, and MythTV should not be changing MythNews'
>schema.
>
>This would mean that you could mix-and-match between Plugins/MythTV
>versions, with no compatibility issues.
>  
>
Yes, but MythWeb is actually more of a completely independent frontend 
than a "plugin," so it /requires/ knowlege of the DB schema.  This is 
actually why the current MythWeb can corrupt custom recording rules and 
other features new to the DB schema--it hasn't yet been completely 
updated for some of the changes.

>>And, in /all/ cases, doing so is *not* a "supported"
>>configuration--which was the point I was trying to make.  Unless, of
>>course, you're volunteering to provide support for all possible version
>>combinations users may wish to try.
>>    
>>
>Now, I'm not going that far. But you *should* be able to compile a
>backend-only system without anything breaking, as it's meant to work
>independantly of any frontends that may be attached to it. Likewise
>with the Frontend-Only compilation. If there is functionality that is
>used in both the frontend and backend, it should be modularised so it
>can be used in both independantly (Moved into libmyth, perhaps?).
>
>Otherwise, there's not much point in having seperate front-end and
>back-end programs, and the whole thing might just as well be one
>massively-threaded monolithic program.
>
>My £0.02 ($0.0355157USD)
>
IMHO, having the mythbackend on disk on my frontend or the mythfrontend 
on disk on my backend is not a big deal, but being able to run 
mythbackend without starting mythfrontend or vice-versa is critical.

As for breaking the client/server functionality, it's hard enough 
getting people to understand what they do and don't need with just a 
"mythtv" program that gets installed on all their Myth boxes--regardless 
of whether they're dedicated backends or dedicated frontends or combined 
frontend/backend boxes.  I can only imagine how complex this would get 
with mythfrontend, mythbackend, and libmyth--and people trying to use 
varying versions of mythlib with 
mythfrontend/mythbackend/mythplugins/whatever.

I'll admit it could be made a more elegant solution, but I'd rather have 
new features like mythui or mfd than an opportunity to save 100MB 
storage space (which is enough space for about 6 minutes of relatively 
low-quality video ;).  Even if it turned out to save 500MB, I don't see 
the value in the savings.

Mike