[mythtv-users] Problem upgrading from 0.25fixes to 0.26

Michael T. Dean mtdean at thirdcontact.com
Tue Jan 22 16:01:21 UTC 2013


On 01/22/2013 10:45 AM, Michael T. Dean wrote:
> On 01/22/2013 05:32 AM, Peter Foulkes wrote:
>> From: "Michael T. Dean"
>>
>>> So, as I read it, you spent 3 to 4 days trying to figure out something
>>> that could have "fixed itself" with a reboot?
>>
>>> GNU/Linux doesn't /have/ to be rebooted for most changes--as long as
>>> you're willing to spend the time figuring out what's wrong, then
>>> learning how to fix it--but sometimes 30s to reboot is the easiest way
>>> to fix things.
>>
>> Accepted. It is my first call for all problems. Sadly, in this case 
>> it didn't cure the problem. Although the fact that it didn't probably 
>> indicates that there is something amiss in my setup somewhere.
>
> That would imply that your system was starting mythfrontend before 
> starting either mythbackend (on the master backend) or mythtv-setup 
> (on any host).  (Only the master backend can upgrade the database, but 
> mythtv-setup can upgrade it on any host.)  And, the reason why 
> mythtv-setup couldn't get the lock to upgrade was because mythfrontend 
> was being continually restarted by some script (that wasn't looking at 
> mythfrontend's exit status) each time mythfrontend shut itself down 
> with a DB schema version error.  The most worrisome part is that your 
> system start scripts allowed this to happen, too...

Actually, I stand corrected--mythfrontend won't ever even request a lock 
when checking DB schema version, so I can't see any way that 
mythfrontend would be related to the issue.

The binding error you mentioned, on port 6948, is for the frontend-only 
UDP Notify Port, so that's completely unrelated to the DB schema 
problem, but it does imply you were running multiple mythfrontend instances.

Mike


More information about the mythtv-users mailing list