[mythtv-users] Advice on v31 installation?
f-myth-users at media.mit.edu
f-myth-users at media.mit.edu
Tue Jun 29 22:00:10 UTC 2021
> 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.
> 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
> 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. :)
More information about the mythtv-users