Mailing List Archive

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Well, maybe not status per-se, but something like what the Tivo
> does when it reports the last time it got EPG data, and how far out
> the data goes. So even though I've got a cron job running
> mythfilldatabase, it'd still be nice to know if I'm running out of
> data. (xmltv broken, zap2it broken, etc)
>
> [.Isaac, are you keeping feature requests somewhere, (/dev/null?) or
> is sending them to the mailing list sufficient?]

This appears to be doable with

mysql> select max(starttime) from program;
or alternatively,
mysql> select max(endtime) from program;

While it won't directly tell you if mythfilldatabase is running
correctly or not, you _could_ do something that says "If the
max(starttime) from the database < 5 days from now, it means that we
haven't been getting data. Alert the user."

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPdJ/Svc1NpCTlP0JEQIEBgCfQysSUkryT9le6nunWyRjOcwQS8gAoIuw
mlD61VnCP7lnDYoI7TFdIw0Y
=y7zY
-----END PGP SIGNATURE-----

On Wednesday 13 November 2002 09:48 am, Robert Kulagowski wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Well, maybe not status per-se, but something like what the Tivo does
> when it reports the last time it got EPG data, and how far out the
> data goes. So even though I've got a cron job running
> mythfilldatabase, it'd still be nice to know if I'm running out of
> data. (xmltv broken, zap2it broken, etc)

Where would it show this info?

> [.Isaac, are you keeping feature requests somewhere, (/dev/null?) or
> is sending them to the mailing list sufficient?]

Anything that I think would be useful, I add to my todo list. Anything else
that comes along without a patch implementing it, I pretty much just ignore.

Isaac

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> > Well, maybe not status per-se, but something like what the Tivo
> > does when it reports the last time it got EPG data, and how far
> > out the data goes. So even though I've got a cron job running
> > mythfilldatabase, it'd still be nice to know if I'm running out
> > of data. (xmltv broken, zap2it broken, etc)
>
> Where would it show this info?

Hrmm. Good question. That's a UI question, I think. Did you plan
on having any sort of status page for when you have a distributed
setup with different front ends / back ends? I would think that a
status page would have information on it like:

1. Last mythfilldatabase run (or highest guide data information)
2. Status of servers: Encoder 1: Recording program X, Encoder 2:
Live TV Channel y
3. Status of clients: "Client x: watching channel y"

I don't know. Maybe too complicated. What _would_ a status page
display? How would it change in a distributed vs. monolithic system?
Do you have thoughts on how you're going to proceed?

> > [.Isaac, are you keeping feature requests somewhere, (/dev/null?)
> > or is sending them to the mailing list sufficient?]
>
> Anything that I think would be useful, I add to my todo list.

Is this a private to-do, or the one on the web page?

> Anything else that comes along without a patch implementing it, I
> pretty much just ignore.

Hrmm. That's why I think that discussion of potential features
should be in the open, to see how receptive you are. If a patch is
developed that you don't like, then it's a bunch of work that the
developer did that won't go anywhere, at least without splitting the
tree, or maintaining private patches.


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPdMig/c1NpCTlP0JEQJYwwCfaVniPc45mR7vqdt3WFveXfvlIUUAnRFk
iBVdu+QNrZ0YnmrJ0Fa3JyAq
=IEZE
-----END PGP SIGNATURE-----

On Wednesday 13 November 2002 11:11 pm, Robert Kulagowski wrote:
> Hrmm. Good question. That's a UI question, I think. Did you plan
> on having any sort of status page for when you have a distributed
> setup with different front ends / back ends? I would think that a
> status page would have information on it like:
>
> 1. Last mythfilldatabase run (or highest guide data information)
> 2. Status of servers: Encoder 1: Recording program X, Encoder 2:
> Live TV Channel y
> 3. Status of clients: "Client x: watching channel y"
>
> I don't know. Maybe too complicated. What _would_ a status page
> display? How would it change in a distributed vs. monolithic system?
> Do you have thoughts on how you're going to proceed?

Hmm, a status webpage or something generated by the master record box would
probably be the way to go. Wouldn't be constrained by any particular UI
limitations, that way, and would most likely be the easiest thing to do.

> Is this a private to-do, or the one on the web page?

pen and paper =) It used to be the same as the one on the webpage, but that
got too cumbersome to keep updated regularly.

> Hrmm. That's why I think that discussion of potential features
> should be in the open, to see how receptive you are. If a patch is
> developed that you don't like, then it's a bunch of work that the
> developer did that won't go anywhere, at least without splitting the
> tree, or maintaining private patches.

Of course -- here's an easy rule of thumb for what I'd accept: If it changes
the default behavior, make it optional. Unless, of course, its a completely
new feature, in which case I'd assume it'd be discussed a little here..
Stuff can always be run by me in IRC, as well.

Isaac