[mythtv] Backwards compatibility

Lawrence Rust lvr at softsystem.co.uk
Wed Jan 6 21:03:03 UTC 2016

On Tue, 2016-01-05 at 22:28 +0000, John McEntee wrote:
> On Tue, Jan 5, 2016 at 8:33 PM, Lawrence Rust <lvr at softsystem.co.uk> wrote:
> > On Tue, 2016-01-05 at 14:25 -0500, Dan Wilga wrote:
> > > On 1/5/16 1:36 PM, Lawrence Rust wrote:
> > > > This set me thinking - how difficult would it be to achieve backwards
> > > > protocol and schema compatibility for the frontend?  So over the
> > weekend
> > > > I tried some ideas:
> > > >
> > > > 1. Enable read-only access to old old database schema.
> > > > 2. Fallback to an old version of the Myth comms protocol.
> > > > 3. Provide a translation layer for updated protocol requests
> > > > 4. Provide a translation layer for serialised data structs.
> > > This is a great idea, Lawrence. I know I am much more likely to try this
> > > than I would be to replace my working BE with 0.28.
> > >
> > > Is there any chance the 0.28 code could run a *slave* BE talking to a
> > > 0.27 *master* BE?
> >
> > This is distinctly possible - not with what I have now but with a little
> > bit more effort.
> >
> > >  That's another scenario under which I could test. It
> > > would even allow me to temporarily reassign my tuners to the 0.28 slave
> > > and try recording.
> >
> > That's what I was hoping - a more diverse test environment exercising
> > all the corners.
> >
> > This is something I have been considering recently as well. I am probably
> one of the worst offenders. I used to update to the latest version of
> mythtv soon after it came out, ( often wanting the new features). I would
> in effect run two backends for a short time in tamdem to minimise risk.
> Then by mistake I let a 0.19 frontend connect to my 0.18 backend (auto
> scheme update) and bit the bullet and didn't roll back. Changes to mythtv
> have become more of a nice to have than a necessity now. I spent years on
> 0.19 until I updated to 0.24 when 0.25 was already out, I wanted to still
> run my VIA M10000 front end. The upgrades always brought changes which
> lower the WAF, as she could see nothing wrong in the old versions. I am not
> going to try to update to at least 0.27 so I can try out the Raspberry pi 2
> I got for Christmas, I have tried Openelec, but I really want a Mythtv
> frontend not a kodi one.
> But back on topic. In my opinion Mythtv should learn from the DevOps
> bandwagon, and do smaller releases and more often, so the upgrades are less
> of a burden and less of a risk. One step to help this would be to enable
> different versions to talk to each other, .

That's just what I would like to achieve.

>  Perhaps the backend could be
> split down to take on the idea of microservices (probably all running on
> the same server though) so you have the masterbackend just controlling the
> scheduling, and a separate service for the recording, another service for
> the communication to the frontend etc..

A nice idea but a major change in architecture.

> A big step missing in my mind would then be a way to roll back the database
> to the old scheme but keeping the current recordings, which would be easier
> with smaller schema updates.

The common way of doing this is to have 2 parallel databases.

> I wonder if providing a docker image for people to test with would help. I
> don't know much about docker yet, but it uses aufs, so you should be able
> to overlay on top of a working master backend to get a sudo live system
> (without the tuner though).
> Just my thoughts, I may ask the users-list what stops others testing out
> the master branch.

Good idea.

Thanks for sharing your ideas.

-- Lawrence Rust

PGP encrypted emails preferred. Public key: AFBDA0B0

More information about the mythtv-dev mailing list