gbr at majentis
Nov 4, 2009, 5:39 PM
Post #6 of 6
(162 views)
Permalink
|
|
Re: Moved to .22 on new box, but recordings not playing
[In reply to]
|
|
Hi,
Thanks for your help. I recommend you change the docs to specify the host and the ip, since in my world host names resolve to IP's, and are not neccesarily used as unique id's
I changed the IP of my new server to that of my old, and everything works again.
Gerald
----- "Michael T. Dean" <mtdean[at]thirdcontact.com> wrote:
> On 11/04/2009 06:10 PM, Gerald Brandt wrote:
> > ----- "Nick Rout" wrote:
> >
> >> On Thu, Nov 5, 2009 at 11:53 AM, Gerald Brandt wrote:
> >>
> >>> I built a new backend and moved my databse over using the .22 supplied
> >>> backup and restore scripts. Everything works, except playing back of old
> >>> recordings.
> >>>
> >>> I'm streaming recording from the backend, and they still want to come from
> >>> the old backend, not the new one.
> >>>
> >>> How can I tell myth to get it's recordings from the new backend?
> >>>
> >>> Thanks,
> >>> gerald
> >>>
> >> Does the new backend have a different host name?
> >>
> >> If so, did you follow the advice here?
> >> http://www.gossamer-threads.com/lists/mythtv/users/405443
> > The hostname did change, but I never referenced it in any of the configs, I only reference the IP's. In fact, the hostnames didn't resolve to an IP, if I recall. I didn't bother to throw them into DNS.
> >
>
> That doesn't matter. In myth, hostnames are not used for IP address
> resolution, but as unique identifiers of systems. So, your recordings
> are all associated with the old system, so Myth tries to find that
> system to ask it for the recordings, but it doesn't exist (or, at the
> least, doesn't have those recordings).
>
> > Gerald
> >
> > ps: I did follow that guid, thnaks.
>
> You missed the part e) and "If you change hostnames on a MythTV system,
> it is critical that you update all the data in the database to change
> the old hostname to the new hostname so recordings, settings,
> keybindings, jumppoints, and /much/ more are properly found for the
> host" part, then.
>
> At this point, your options are limited. The best fix would be to use
> the restore script to do a hostname change of the new (desired) hostname
> to some garbage hostname and then run the script again to change the old
> hostname to the new (desired) hostname. See
> http://www.mythtv.org/wiki/Database_Backup_and_Restore#Change_the_hostname_of_a_MythTV_frontend_or_backend
> . The problem with this fix is you lose any configuration and/or
> recordings done with the new hostname.
>
> Another fix would be to "lie" to MythTV about the hostname by editing
> /all/ of your mysql.txt and config.xml files on the new sytem to include:
>
> LocalHostName=newhostname
>
> in mysql.txt or
>
> <LocalHostName>newhostname</LocalHostName>
>
> in config.xml
>
> Here, also, you lose any configuration/recordings done with the new
> hostname.
>
> Another partial fix is to run:
>
> cat << "EOF" | mysql -umythtv -p mythconverg
> UPDATE recorded
> SET hostname = 'newhostname'
> WHERE hostname = 'oldhostname'
> EOF
>
> which will only fix some of the broken data--and leave the rest broken.
>
> I /really/ wasn't lying in that post when I said, "it is criticial," and
> "If you forget to do so, changing the hostname becomes /much/ more
> difficult--to the point that restoring your pre-upgrade backup and doing
> the upgrade properly, and using the script to change the hostname, is
> the easiest solution. "
>
> Which brings me to my final approach--restore the pre-upgrade backup and
> do the name change properly (which also loses configuration/recordings
> done on the new hostname).
>
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users[at]mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
|
