[mythtv] [mythtv-commits] mythtv commit: r23012 - in trunk/mythtv by cpinkham

Chris Pinkham cpinkham at bc2va.org
Tue Dec 29 22:43:56 UTC 2009


* On Mon Dec 28, 2009 at 04:06:05AM -0500, f-myth-users at media.mit.edu wrote:
> Random feature suggestions---anyone else think these would be useful?

I'm open to new events.  The list included in the original commit were the
things that I could think of off the top of my head in one or two
brainstorming sessions.  I know there are lots more and the way I
implemented the functionality, adding a new event is normally as simple as
adding a line or two of code in the desired place and then adding a
single line to the editor screen to allow editting the command string
for the new event.

> [If so, and if Chris doesn't beat me to 'em, I may implement them when
> I've got a trunk devo system.]

If anyone wants to code these up, they can create a patch and ticket,
but I have added them to a TODO and may get to them soonish.

> (a) "Mythfilldatabase started".  You've got "ran", but I also arrange

> (b) "Scheduling started".  I monitor scheduler starts/stops (via

These are trivial to do.  I might consider changing the current 'ran'
versions to 'finished' to be more consistent in naming.

> (c) "Backend predicted to be idle for at least N minutes", where N is
>     chosen by the user.  Right now, I extract this info by waiting

I wanted the settings screen for this to be very very simplistic.  I
do have another patch for making the settings screen a little more
user-friendly, but that is waiting on another MythUI patch I'm working
on.

I didn't want events that the user had much control over because that
complicates settings.  I could see adding an event for each backend
after each scheduler run that said "Backend ABC's next recording is
in X minutes".  This would get sent for each connected backend.
I also made a note to modify the 'Recording Pending' event to include
the hostname of the backend that the recording will be starting on.

Events should be simple, always sent when situation X occurs.  I don't
want to get into the settings nightmare that could be if the user
can start specifying when events fire.  The event should always fire
when the situation happens, it is up to the user script whether to
act on the event.  In this (c) case, the user script could act if the
backend was going to be idle for 2 hours, but not if the backend would
only be idle for 30 minutes.

--
Chris


More information about the mythtv-dev mailing list