[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.


More information about the mythtv-dev mailing list