[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