[mythtv] [PATCH] revised/added protocol extension patch -- ignore last one

[Noone]

On Sun, May 01, 2005 at 03:32:31AM -0400, Isaac Richards wrote:
> On Sunday 01 May 2005 02:58 am, Noone wrote:
> >
> > If it matters much, I think what you're doing is exactly what myth needs. 
> > Something I noticed awhile ago is myth's reliance (and blocking) on sql
> > queries.  It looks fine on paper until you consider latency.
> 
> Let's compare:
> 
> frontend -> sql server -> frontend
> vs.
> frontend -> backend -> sql server -> backend -> frontend.
> 
> By gosh, you're right!  Latency is _much_ lower in the second case!
> 


It is a step in the right direction imho.  Since the end result would also be the backend caches much of the commonly requested data (recorded list, guide data, ICONS, etc.), the hit shouldn't be that bad.

The more frontends you have, the more you gain as well.  I don't think it is that uncommon (though .. I could be wrong), for people to be running two or more frontends serving different TV's.  By having the server do the query work (and cache), you've now taken the number of queries down from a possible 22/s (using example I gave), to 2.  


Something else I thought of but haven't really tried out yet was turning the frontend into a kind of Xterm or "thinclient" (without the bloat).  The backend would do much of the work while feeding a pretty light weight frontend whose sole job is to display it.

I kind of did that with a laptop running mplayer off the backend server.  It worked ok for me because although the sound came out the soundcard of the backend, I'm a few feet from it so it didn't matter :-)  (a real Xterm does it's own sound).

I've also run a real frontend off the backend from remote.  Although it seems that broke somewhere now ... ug:

X Error: BadShmSeg (invalid shared segment parameter) 169
  Major opcode:  146
  Minor opcode:  2
  Resource id:  0x2800021

Oddly enough the mini preview of recordings work .. hrmm..