[mythtv] [PATCH] External channel changer's exit code missed

[Richard Gering]

Greetings,

Sorry for the delayed follow-up, but I was unavailable last week.

Thanks for explanation on how the & made it into the code.  I can
understand why it was put there, but I don't totally agree with it.
Giving up accuracy in favor of speed is, IMHO, a bad idea. It's an
example of the rule:

  "Good, Fast, Cheap: Pick two."

yielding a solution that is both fast & cheap (to make), but
unfortunately isn't good.  And that's just not what I've learned to
expect from Myth :-)

I'm also not quite sure where the big performance increase is coming
from.  I've played with using the changer with and without &, and the
only difference I find is directly related to the implementation of the
channel changer script itself: if it doesn't linger, the channel zapping
won't either.

In the 30 second rotating-dish-to-a-different-satellite example, I still
wouldn't see the picture any sooner.  The only difference would by that
Myth would tell me it had switched channels, when in fact it was still
in the process of switching.

Perhaps the advantage is that you can continue to zap?  True, I guess,
but doing so could spawn a multitude of channel changers, all
simultaneously trying to manipulate the same device.  The result is
pretty much guaranteed to be ambiguous, especially for receivers
controlled by a serial cable, but Myth will report that we ARE watching
the last chosen channel since all feedback is ignored.

Personally I don't mind having to remove the & by hand before compiling
the code, although I'm not a big fan of having to always customize code.
The problem, from my view, is that someone picking up a pre-built
version of Myth won't be able to get it right.

A version of Myth that would not use the & can easily be made to act as
if it had, simply by having users who want this write a two line wrapper
script ONCE for their channel changer of choice:

	#!/bin/sh
	ActualChannelChanger $* &

All in all this seems a better idea, with the only downside being that
the out-of-the-box experience can be slower for the channel zapping
speed junkies who like to drive without safety belts :-)

I've pondered the threaded channel changer Daniel suggested, but I'm not
quite sure how that would pan out. Myth switches channels, but when the
external channel changer finally reports that it failed, do we:

- Cancel & delete a recording that was started while the channel changer
ran?
- Revert back Live TV to the previous, known good channel?

All possible, but it sounds like a huge amount of overhead that
shouldn't really be necessary.

If I have missed the intention of the threaded external channel changer,
please do enlighten me!

In closing, I would be HAPPY to add an option to the setup program that
would allow a user to configure whether or not the channel changer
should be launched asynchronously or not.  Please let me know if you're
interested!

Cheers,

- Richard.


-----Original Message-----
From: Daniel Thor Kristjansson [mailto:danielk at mrl.nyu.edu] 
Sent: Saturday, January 22, 2005 8:39 AM
To: Development of mythtv
Subject: Re: [mythtv] [PATCH] External channel changer's exit code
missed


On Sat, 22 Jan 2005, Jeremiah Morris wrote:
]On 22 Jan 2005, at 3:51 AM, Isaac Richards wrote:
]> On Saturday 22 January 2005 03:36 am, Richard Gering wrote:
]> > The current implementation of the external channel changer misses
the ]> > exit code set by that changer, because it (accidentally) runs
that ]> > program as an additional background process.
]> Can't drop the &, people will start bitching about the slower channel
change ]> speed.
]The current verbose messages are misleading, as they imply that the
channel ]change exit is monitored; we should at least change the
messages to reflect the ]situation.

The verbose messsages are in anticipation of a threaded channel changer.

I generated this code in the last month or so and explained the "&" and
what was needed to fix it when I submitted the patch.

-- Daniel



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.