[mythtv-users] Moved to .22 on new box, but recordings not playing
Michael T. Dean
mtdean at thirdcontact.com
Thu Nov 5 00:10:03 UTC 2009
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
>>> 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?
>> Does the new backend have a different host name?
>> If so, did you follow the advice here?
> 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).
> 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
. 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:
in mysql.txt or
Here, also, you lose any configuration/recordings done with the new
Another partial fix is to run:
cat << "EOF" | mysql -umythtv -p mythconverg
SET hostname = 'newhostname'
WHERE hostname = 'oldhostname'
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).
More information about the mythtv-users