Right. There's some benefit to that, I'm just not sure if it's worth the
extra time those queries would then take, especially if the frontend were
made to use 'em.
Although, one _could_ also argue that other projects should just use
libmyth/libmythtv instead of reimplementing things from scra
On Sunday 01 May 2005 10:05 pm, Kevin Kuphal wrote:
> Isaac Richards wrote:
> >My questions as well, every time this is brought up. libmysqlclient's
> > just a cross-compile away for almost any platform. It's tiny, too - if a
> > platform's that starved for RAM, it's not going to be capable of
>
Isaac Richards wrote:
On Sunday 01 May 2005 03:32 pm, Brad Templeton wrote:
On Sun, May 01, 2005 at 01:45:01PM -0400, Noone wrote:
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,
Isaac Richards wrote:
My questions as well, every time this is brought up. libmysqlclient's just a
cross-compile away for almost any platform. It's tiny, too - if a platform's
that starved for RAM, it's not going to be capable of displaying much of a
UI, either.
Just out of curiosity, do yo
On Sunday 01 May 2005 03:32 pm, Brad Templeton wrote:
> On Sun, May 01, 2005 at 01:45:01PM -0400, Noone wrote:
> > 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.), t
On Sun, May 01, 2005 at 01:45:01PM -0400, Noone wrote:
> 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.
I don't know about the inside
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 o
Noone wrote:
>The guide definetly needs help. I count about 11 queries just by changing
>focus (alt-tab away and back to myth):
>
>- SELECT NULL (these btw POUND the sql server in mini storms for some reason
>.. I haven't dug much into what the hell causes it or why they are needed)
>- Time for
On Sunday 01 May 2005 02:58 am, Noone wrote:
> On Sun, May 01, 2005 at 12:53:35AM -0400, David Shay wrote:
> > OK, I've decided to go ahead and complete the protocol extensions that I
> > would
>
> If it matters much, I think what you're doing is exactly what myth needs.
> Something I noticed awhi
On Sun, May 01, 2005 at 12:53:35AM -0400, David Shay wrote:
> OK, I've decided to go ahead and complete the protocol extensions that I would
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.
On 5/1/05, David Shay <[EMAIL PROTECTED]> wrote:
Comments,thoughts before I proceed? Next steps would be to add functions toget guide data, in order to emulate the front-end guide, then add a function
to schedule a recording. Scheduling the recording is a pretty vital one. Ifwe can make that a p
OK, I've decided to go ahead and complete the protocol extensions that I would
need for most playback functions from alternate frontends. Here are the
additional commands and how they work:
QUERY_SQL [query statement]
Returns all rows and columns of the resultset in []:[] delimited form
QUE
12 matches
Mail list logo
