[mythtv] Slave Back End Looping
Michael T. Dean
mtdean at thirdcontact.com
Tue Oct 14 19:42:09 UTC 2008
On 10/14/2008 02:30 PM, Anduin Withers wrote:
> > I applied the diff from here
> > http://svn.mythtv.org/trac/ticket/5268#comment:9 to solve a similar
> > issue with the SCHEDULE_CHANGE message. This caused a similar
> > SCHEDULE_CHANGE issue to be "fixed".
>
> SCHEDULE_CHANGE was just one quick loop elimination, it wasn't the
> actual cause. If you or someone else don't want to wait for me to fix it
> (had less MythTV time last weekend than I thought):
>
> Cause: new timezone checker _or_ a confusing mess of things with strange
> rules, take your pick.
>
> call stack:
>
> MythContext::ConnectToMasterServer
> MythContext::SendReceiveStringList()
> checkTimeZone()
>
> That ConnectToMasterServer() call creates a new connection to the master
> backend, along with a new event connection (this connection didn't exist
> before).
>
> The SlaveBackend connection forwards events from the SBE to the MBE (not
> new).
>
> The new event channel means the SBE gets messages it was never supposed
> to, causing it to forward messages it shouldn't which are then returned
> back down that event channel, repeat.
Shouldn't it just require moving the time zone check to later in
mythbackend's main(), like was done for mythfrontend? And, doing so has
the additional benefit of allowing for translated messages (and,
possibly, a pop up for interactive sessions with a DISPLAY as I think
the backend will show for protocol/DB schema version differences) in the
event of a time zone mismatch.
Haven't done any testing or even determined where best to place the
check, but the time zone check doesn't have to be done immediately--I
only put it there (not realizing the complexity of the server connection
stuff) thinking it would save a lot of initialization if we're going to
refuse to start up.
Mike
More information about the mythtv-dev
mailing list