[mythtv-users] Advice on v31 installation?

Paul Harrison mythtv at mythqml.net
Tue Jun 29 21:40:34 UTC 2021


On 29/06/2021 20:03, f-myth-users at media.mit.edu wrote:

> Speaking of which, does Mythweb still work?  That's been my 100% way of
> scheduling for many years now, and I keep seeing rumors of it going away
> because it's not maintained.  But being able to manipulate schedules on
> -any- machine, without worrying about compatible frontend versions, is
> very convenient.


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.

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

> And I'm still wondering whether it's safe not to create a brand-new SD
> acct to avoid accidentally blowing away my existing lineup; does the
> grabber ask to create a new one once I give it my username/pw?  (The SD
> website says not to create new lineups via the web interface if using
> the XMLTV grabber, so I don't have any experience with that yet.)

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.


> (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 :)

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?


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.


> Thanks again!


Paul H.



More information about the mythtv-users mailing list