[mythtv] New Protocol Development

Marc Randolph mrand at pobox.com
Wed Oct 1 14:15:37 UTC 2008

On Tue, Sep 30, 2008 at 12:18 PM,  <f-myth-users at media.mit.edu> wrote:
>    > Date: Mon, 29 Sep 2008 07:56:09 -0700
>    > From: "Rob Smith" <kormoc at gmail.com>
>    > On Sun, Sep 28, 2008 at 4:52 AM, Marc Randolph <mrand at pobox.com> wrote:
>    > > The current Mythweb appears to refetch/reload the entire page on each
>    > > mouse click, which isn't the best thing to do from an interactivity
>    > > standpoint.  Example: go to upcoming page when you have a number of
>    > > pages of number of upcoming recordings.  Click "Don't record" on one.
>    > > Sometimes it takes a considerable period of time to (haven't yet tried
>    > > to figure out why it takes so long - but this is on a 2.2 GHz C2D, so
>    > > I don't think its cpu utilization).
>    > LIkely you're hitting the delay added intentionally to reduce the
>    > number of bug reports. The scheduler takes between 15 and 30 seconds
>    > on my core2duo box. When you click don't record, we actually sleep a
>    > bit as if we return before the scheduler finishes running, your button
>    > press doesn't look like it did anything. That's not a good thing.
> Maybe a trinary system where something changes to "pending"?
> (This might be a strategy in general for things that might take a
> "long" time as perceived by the user.  Presumably it would involve,
> not a timeout, but some flag set around scheduler invocations, and
> queryable via the network protocol, that says, "the scheduler is
> currently running and things that look at listings of upcoming
> recordings are not guaranteed 100% consistent".  I know that would
> help -my- sorts of scripts a whole lot.)

That'd be cool, although I'd still like a gmail-like interface so that
I could do a given action to many (all?) items that are displayed in a
list on Mythweb (and maybe mythfrontend).  It's way more efficient,
both for the user and the system.


More information about the mythtv-dev mailing list