[mythtv-users] Using database backup as starting point for new backend
James Abernathy
jfabernathy at gmail.com
Mon Oct 28 18:11:17 UTC 2019
On 10/26/19 8:16 PM, James Abernathy wrote:
>
>> On Oct 26, 2019, at 4:45 PM, James Abernathy <jfabernathy at gmail.com
>> <mailto:jfabernathy at gmail.com>> wrote:
>>
>>
>> On 10/26/19 3:58 PM, David Hampton wrote:
>>> On Sat, 2019-10-26 at 15:41 -0400, James Abernathy wrote:
>>>> So I have a production mythtv backend called “mythbuntu”. I have a
>>>> new backend built on a Raspberry Pi 4 on the same network. It’s name
>>>> is “raspberrypi”. I’m wanting to parallel test these systems for a
>>>> few months with the same recording rules to see how the RP4 performs.
>>>> “mythbuntu” has Hauppauge WinTV Quad tuners and “raspberrypi” has
>>>> HDHR Quatro tuners. So in theory they both should record the same
>>>> programs since all tuners are on the same antenna.
>>>>
>>>> I started by taking a database backup of mythbuntu and restoring it
>>>> on raspberrypi. I also copied all the recordings over to raspberrypi.
>>>> I had some problems cleaning up the changes needed on raspberrypi to
>>>> General, Tuners, and input connections.
>>>>
>>>> There was some problem with the master backend settings because it
>>>> wanted to setup raspberrypi as a slave off of mythbuntu. I got that
>>>> fixed and both backends showed the same recordings and schedules for
>>>> future recordings.
>>>>
>>>> SO my current issue is, I tried to look for problems on raspberrypi
>>>> with find_orphans.py. It seemed to show duplicate entries and files
>>>> on both mythbuntu and raspberrypi. I don’t know if this was an issue
>>>> on just the database on raspberrypi or was find_orphans looking on
>>>> the network at both backends?
>>>>
>>>> I ended up deleting a lot of recordings on the raspberrypi I didn’t
>>>> want deleted so I’m going to have to repeat the process. Any advice
>>>> on what I should have done???
>>> One of the columns in the recorded table is the hostname where the
>>> recording lives. Did you update this field?
>>>
>>> The best way to change hostnames is with the mythconverg_restore.pl
>>> script. Restore the database on the new system, and then run the
>>> script again with different arguments:
>>>
>>> mythconverg_restore.pl \
>>> --change_hostname \
>>> --old_hostname="XXXX" \
>>> --new_hostname="YYYY"
>>>
>>> I did this a while back. I can't remember whether or not I had your
>>> problem of the new backend trying to find the old backend.
>>>
>>> David
>>
>> That sounds like what I need to do differently. I'll test tomorrow
>> morning before my recordings start.
>>
>> Thanks
>>
>> Jim A
>
> I redid the copy of the recordings and the database. The database
> restore worked fine, but the —change_hostname failed due to some uses
> on raspberrypi in the database somewhere. I didn’t understand it so I
> chose to rename the system host and hostname entries to rpi-mythtv.
> Then the —change_hostname worked.
>
> I exposed some other Raspbian buster issues related to boot up waiting
> for networking affecting lxpanel and mythtv-backend. I’m going to work
> that issue in another topic.
>
> Jim A
>
So I finally figured this out. Starting with a unique hostname for the
Raspberry Pi was key. Also after the restore and recording copies the
--change_hostname in mythconverg_restore.pl was key.
in mythtv-setup -> General, I checked the master backend box and
selected the new RPI master name and then the usual settings for tuners,
input-connections, and volumes. After testing it for a while, I shutdown
my original master backend and then ran the find_orphans.py script and
cleaned up a few things. So they both are operating as 2 complete
master backends on the same subnet. the PC based one has remote FEs, but
the RPi4 is a self contained FE/BE combo
Jim A
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20191028/7ec3b381/attachment.htm>
More information about the mythtv-users
mailing list