I'm moving a 0.29 backend between hosts. Other threads here on my travails.
Now that I've got it running on the new Ubuntu 18.04 host, my frontends and mythweb connect to it just fine. I see the current recorded programs and can play them. I can play live TV.
However my Recording Rules and Upcoming Recordings disappeared. Are the recording rules pointing at the old host? Is there some update I can make to the database to point the existing rules at the new backend?
Moving 0.29 Backend to new host
Re: Moving 0.29 Backend to new host
Code: Select all
curl --header accept:application/json OLDhost:6544/Myth/GetHostName
curl --header accept:application/json NEWhost:6544/Myth/GetHostName
Then ALL config.xml files in the new host could be changed to that old hostname
in LocalHostName
.
I wouldn't have both hosts connected to your network at the same time while trying
this test (to see if the rules become visible). The new host should be stopped 1st
and started after the change.
Re: Moving 0.29 Backend to new host
So amber is the old backend. On the new backend I added
to /home/mythtv/.mythtv/config.xml and restarted the backend.
I restarted a front end to connect but still no recording rules and no upcoming recordings. Is there something manual I can do in the database? I don't see any host names in the record table.
Code: Select all
<LocalHostName>amber</LocalHostName>I restarted a front end to connect but still no recording rules and no upcoming recordings. Is there something manual I can do in the database? I don't see any host names in the record table.
Re: Moving 0.29 Backend to new host
Right no hostnames there. See if the recording rules are even there:
Can't (shouldn't) hurt to check for DB problems for this and
other topics here: sudo mysqlcheck mythconverg
There's a backup job in /etc/cron.weekly that does it too
if you don't know your root DB password and the above
doesn't work.
Code: Select all
SELECT title,recordid FROM record ORDER BY title;
other topics here: sudo mysqlcheck mythconverg
There's a backup job in /etc/cron.weekly that does it too
if you don't know your root DB password and the above
doesn't work.
Re: Moving 0.29 Backend to new host
Yes the rules are in the table record. First thing I checked. Something else is borked. I can see and play the already recorded shows. But I cannot create new recording rules. Selecting "Record This Show" in the listings does nothing. And selecting Live TV says "Cannot Connect to Master Backend." But I'm already connected.
Re: Moving 0.29 Backend to new host
So going into status on the frontend. I see the old tuners as OK but the new tuners as "error." So Live TV will work when I start the *old* backend. I guess I need to delete the tuners associated with the old backend when I make the transition. But I still need to figure out the schedules issue.
Re: Moving 0.29 Backend to new host
You can always start the backend and frontend with -v schedule to look for additional clues.
The scheduler, naturally, needs to know about the tuners. Items in the logs may point the
way. Not knowing what's been changed in the DB, backing up the current DB and reloading
an old one may be the quickest solution.
The scheduler, naturally, needs to know about the tuners. Items in the logs may point the
way. Not knowing what's been changed in the DB, backing up the current DB and reloading
an old one may be the quickest solution.
Re: Moving 0.29 Backend to new host
I think I'm setting up the tuners wrong. I was trying to leave the old backend setup and add new instances of all the tuners on the new backend. I think that's wrong. So I've deleted all the tuners in mythtv-setup and re-added them on the new backend. But I'm getting tuner errors in the frontend status screen. Looking a the log on the new backend:
10.0.2.2 is the new backend. Do you know what's going on?
Code: Select all
Jul 23 10:10:11 myth mythbackend: mythbackend[28720]: E CoreContext recorders/hdhrstreamhandler.cpp:481 (TunerSet) HDHRSH(1310D391-1): DeviceSet(channel none): ERROR: resource locked by 10.0.2.2
Re: Moving 0.29 Backend to new host
Tuner pooling in MythTV wasn't available 'til v30. mythbackend expects to have exclusive
use all tuners. You can Get around this by setting the Schedule Order and Live TV order
to 0 on one host and on another host, set the opposite tuners to non-zero values. Or,
just don't run both hosts at the same time (or disconnect one from the LAN.)
You can take the message literally. Possibly, the 10.0.2.2 mythbackend either has an active
lock on the tuner or either the backend or the host itself wasn't shudown gracefully.
The result is that the HDHR considers the tuner locked. Stop the other backend/host
or any other program (e.g. on Windows) that uses the tuners. Failing that, I'd restart
the HDHR.
use all tuners. You can Get around this by setting the Schedule Order and Live TV order
to 0 on one host and on another host, set the opposite tuners to non-zero values. Or,
just don't run both hosts at the same time (or disconnect one from the LAN.)
You can take the message literally. Possibly, the 10.0.2.2 mythbackend either has an active
lock on the tuner or either the backend or the host itself wasn't shudown gracefully.
The result is that the HDHR considers the tuner locked. Stop the other backend/host
or any other program (e.g. on Windows) that uses the tuners. Failing that, I'd restart
the HDHR.
Re: Moving 0.29 Backend to new host
I wasn't paying attention to the logs. Those tuner messages were from yesterday.
I shutdown the old master. The tuners are installed on the new backend. The new backend is setup as the master. I power-cycled the HDHRs. Rebooting the frontend, I still see tuner errors in Information. I do not see any new tuner messages in the log.
I shutdown the old master. The tuners are installed on the new backend. The new backend is setup as the master. I power-cycled the HDHRs. Rebooting the frontend, I still see tuner errors in Information. I do not see any new tuner messages in the log.
Re: Moving 0.29 Backend to new host
I see several messages in the backend log:
Code: Select all
Jul 24 10:13:33 myth mythbackend: mythbackend[26664]: E ProcessRequest mainserver.cpp:4763 (HandleRemoteEncoder) MainServer: HandleRemoteEncoder(cmd GET_STATE) Unknown
encoder: 1
Jul 24 10:13:33 myth mythbackend: mythbackend[26664]: E ProcessRequest mainserver.cpp:4763 (HandleRemoteEncoder) MainServer: HandleRemoteEncoder(cmd GET_SLEEPSTATUS) U
nknown encoder: 1
Jul 24 10:13:33 myth mythbackend: mythbackend[26664]: E ProcessRequest mainserver.cpp:4763 (HandleRemoteEncoder) MainServer: HandleRemoteEncoder(cmd GET_STATE) Unknown
encoder: 2
Jul 24 10:13:33 myth mythbackend: mythbackend[26664]: E ProcessRequest mainserver.cpp:4763 (HandleRemoteEncoder) MainServer: HandleRemoteEncoder(cmd GET_SLEEPSTATUS) U
nknown encoder: 2
Jul 24 10:13:33 myth mythbackend: mythbackend[26664]: E ProcessRequest mainserver.cpp:4763 (HandleRemoteEncoder) MainServer: HandleRemoteEncoder(cmd GET_STATE) Unknown
encoder: 3
Jul 24 10:13:33 myth mythbackend: mythbackend[26664]: E ProcessRequest mainserver.cpp:4763 (HandleRemoteEncoder) MainServer: HandleRemoteEncoder(cmd GET_SLEEPSTATUS) U
nknown encoder: 3
Jul 24 10:13:33 myth mythbackend: mythbackend[26664]: E ProcessRequest mainserver.cpp:4763 (HandleRemoteEncoder) MainServer: HandleRemoteEncoder(cmd GET_STATE) Unknown encoder: 4
Jul 24 10:13:33 myth mythbackend: mythbackend[26664]: E ProcessRequest mainserver.cpp:4763 (HandleRemoteEncoder) MainServer: HandleRemoteEncoder(cmd GET_SLEEPSTATUS) Unknown encoder: 4
Jul 24 10:13:33 myth mythbackend: mythbackend[26664]: E ProcessRequest mainserver.cpp:4763 (HandleRemoteEncoder) MainServer: HandleRemoteEncoder(cmd GET_STATE) Unknown encoder: 5
Jul 24 10:13:33 myth mythbackend: mythbackend[26664]: E ProcessRequest mainserver.cpp:4763 (HandleRemoteEncoder) MainServer: HandleRemoteEncoder(cmd GET_SLEEPSTATUS) Unknown encoder: 5
Jul 24 10:13:33 myth mythbackend: mythbackend[26664]: E ProcessRequest mainserver.cpp:4763 (HandleRemoteEncoder) MainServer: HandleRemoteEncoder(cmd GET_STATE) Unknown encoder: 6
Jul 24 10:13:33 myth mythbackend: mythbackend[26664]: E ProcessRequest mainserver.cpp:4763 (HandleRemoteEncoder) MainServer: HandleRemoteEncoder(cmd GET_SLEEPSTATUS) Unknown encoder: 6
Jul 24 10:13:42 myth mythbackend: mythbackend[26664]: E ProcessRequest mainserver.cpp:4763 (HandleRemoteEncoder) MainServer: HandleRemoteEncoder(cmd GET_STATE) Unknown encoder: 1
Jul 24 10:13:42 myth mythbackend: mythbackend[26664]: E ProcessRequest mainserver.cpp:4763 (HandleRemoteEncoder) MainServer: HandleRemoteEncoder(cmd GET_SLEEPSTATUS) URe: Moving 0.29 Backend to new host
Did you install the homerun config tools on the new system?
BE/FE-Asrock AB350 Pro Ryzen 3 3200G, 6 atsc tuners. FE's-GF8200's Athlon II, Ryzen 3 2200G. Mythtv user since 2005.
Re: Moving 0.29 Backend to new host
Yes I just did. Discovery works fine. Plus mythtv-setup discovered and auto-installed the tuners without issue
.
Code: Select all
$ hdhomerun_config discover
hdhomerun device 131992E4 found at 10.0.2.94
hdhomerun device 1310D391 found at 10.0.2.67
Re: Moving 0.29 Backend to new host
A QUERY_REMOTEENCODER message has been sent to the backend via Myth Protocol and the encoder (cardid)
isn't known. Suggests it's still in the memory or the DB (somewhere) or the BE hasn't been restarted since it
was changed. Although the PID in the above is different from the earlier message, it was restarted at least
once. The query used here is:
isn't known. Suggests it's still in the memory or the DB (somewhere) or the BE hasn't been restarted since it
was changed. Although the PID in the above is different from the earlier message, it was restarted at least
once. The query used here is:
Code: Select all
SELECT cardid, cardtype, videodevice FROM capturecard ORDER BY cardid;
Re: Moving 0.29 Backend to new host
Okay, I ran that SQL. It gives me the list of the 6 encoders
Code: Select all
cardid cardtype videodevice
1 HDHOMERUN 1310D391-0
2 HDHOMERUN 1310D391-1
3 HDHOMERUN 1310D391-2
4 HDHOMERUN 131992E4-0
5 HDHOMERUN 131992E4-1
6 HDHOMERUN 131992E4-2