[mythtv-users] Advice on v31 installation?

[f-myth-users at media.mit.edu]

    > Date: Tue, 29 Jun 2021 22:40:34 +0100
    > From: Paul Harrison <mythtv at mythqml.net>

    > MythWeb is still working OK. No new development is being done on it but 
    > it does receive any required fixes to keep it going.

Excellent!

    > You do need to make sure you get the latest version available for your 
    > version of MythTV.

I'm assuming it'll be in the PPA?  I also vaguely recall people having
trouble setting up Apache correctly, but hopefully I'll figure it out.
I've configured a lot of Apaches over the years and I also have the old
backend's configuration, if they're still configured similarly.

    > The plan is to replace MythWeb with the WebFrontend or at least the son 
    > of the WebFrontend which will use the Services API.

OK.  Hey, once I'm running a modern version, I may even be able to
help.  I have grand plans for use of the API given what I've been
doing all these years in (ab)using the web interface for bespoke tools.

    > The old SD lineups you setup on the SD web site are not used in XMLTV. 
    > In XMLTV you have to create new lineups and add the channels in the 
    > XMLTV grabber you choose to use. When you configure the XMLTV grabber it 
    > will ask you for your SD username/pw etc. The old MythTV settings fro 
    > them are not used.

OK.  As long as the XMLTV stuff doesn't touch the DD lineup I have, I'm
happy.  I don't want it to break the lineup for my existing prod host
until I can cut over, which probably will be days/weeks, realistically.

    > > (And of course still wondering why we have both JSON and SQLite XMLTV
    > > grabbers and if there's any way to decide between them.  Is either one
    > > faster/smaller/better maintained/the way of the future/easier to set up?)

    > Gary B. the author of the SQLite grabber is a friend of the project so 
    > most developers use that one :)

Well, that's an excellent reason, then! :)  Definitely implies it'll be
well-maintained.

    > The way the SD XMLTV grabbers work is basically rather than download 
    > every program each time it runs, which is what the old SD grabber does,
    > it just grabs the changes (any new programs or program updates) that 
    > makes them a lot more efficient and reduces the strain and bandwidth 
    > required on the SD servers. In the early days the SQLite grabber was 
    > more efficient because it was written from the start to comply with the 
    > SD recommendations.  There was a suspicion the other grabber in the 
    > early days at least just grabbed all the data each time it run but I 
    > think that is no longer the case but I don't use it so can't confirm this?

I recall people talking about having to go day-at-a-time to avoid
gigantic working sets, and also that maybe someone made it more
efficient a while back, but I don't recall the details or when.

But if the SQLite version doesn't eat gobs of RAM doing mfdb, great.
(The new machine has "only" 8 GB in it.)

    > For those interested SD asked all projects if possible to switch to the 
    > new method that only downloads changes because it's much more efficient. 
    > We didn't do it to piss of uses honest :)

:)

    > > P.S.  One thing I recall from very old installations is that they were
    > > somewhat promiscuous about finding other backends on the network and
    > > upgrading any DB they find, and I definitely don't want v31 to even try;
    > > my old one is too old for it to upgrade and I'll have to upgrade it with
    > > some intermediate ancient version in schroot or something, I'm guessing.
    > > I'm thinking the safe way to proceed there is to use iptables on my old
    > > backend to just reject any packets from my new backend; that should (I'd
    > > think!) absolutely prevent any misfire from attempting to upgrade the
    > > old DB in-place, as opposed to from some backup file I explicitly hand
    > > to the new installation.

    > If it really bothers you just use a different name for the new database. 
    > It defaults to 'mythconverg' but you can call it whatever you want. I 
    > run two backend on my network and that is what I do.

...oh!  Right, that makes sense.  Just in case, I may -still- firewall
off the old backend from the new one, but if I'd realized that trick,
I might have been way more amenable to trying newer versions over the
years.  I just -really- didn't want to accidentally bash the stable
version while experimenting, and that behavior really gave me pause.
(And for some reason I had a blind spot and just didn't think about
using iptables to firewall the old host, and such blind spots can
persist for -years- until insight unexpectedly arrives. :)

Thanks again!