[mythtv-users] How to handle schedule pre-emptions?

[Dean Collins]

Brad, like I said earlier, - it's a lot of work for little effective
gain and opens up a number of holes or potential areas for concern.

I think we just need to accept that very infrequently shit happens and
move along.

Cheers,
Dean


> -----Original Message-----
> From: mythtv-users-bounces at mythtv.org [mailto:mythtv-users-
> bounces at mythtv.org] On Behalf Of Brad Templeton
> Sent: Friday, April 29, 2005 6:21 PM
> To: Discussion about mythtv
> Subject: Re: [mythtv-users] How to handle schedule pre-emptions?
> 
> On Fri, Apr 29, 2005 at 02:39:07PM -0700, Brad Templeton wrote:
> > Well, if some brave volunteer wanted to offer a service to notice
pre-
> emptions
> > and broadcast database updates for the networks, I could produce
code
> > to read these off the web or an e-mail to update the database.
> >
> > A mailing list seems the most efficient, but it means that each user
> > has to know how to redirect a mail or an alias into a process (such
as
> > a perl script.)  That changes from system to system so it's not
really
> > possible to have it slotted in out of the box.
> >
> > Far less efficient would be polling a web address.  That could work
out
> > of the box but it's a _lot_ less efficient and depends on you
polling in
> > time.
> >
> > But the main thing is somebody willing to be the trusted party who
> > sends out updates.    You would write up the updates in something
> > similar to the SQL that would be executed.
> 
> With a bit more thought, I came upon some additional realizations.
> 
> One more secure approach would be to send the zap2it style XML with
> updates, and feed that into mythfilldatabase.
> 
> (One could also consider just a signal to tell the system to run
> mythfilldatabase with an argument telling what site to fetch data
from.
> However, that would still need to be secured, as otherwise it could
> cause a DOS attack)
> 
> However, it also occurs to me that unlike me, many people may not have
> a mail server running anywhere that can connect to their SQL database.
> While one could tunnel or play other tricks, the e-mail route might
> leave a number of users unable to easily use the system.
> 
> The alternatives aren't great though.  One would be to develop an
"alerts"
> daemon in Myth.  This daemon would listen to a port (could be any
port)
> for a very simple command set.   One would need to open a firewall/NAT
> hole
> to the port, and because of the security risks of doing so, the
command
> set for the port would be very small, and the commands probably signed
> with a crytographic digital signature.   The commands would probably
not
> contain any data, they would be more along the lines of "You should
> resync your database now" or "go get database updates from this IP
> address."
> 
> (Alerts could also still come via email for those who could handle
that.
> The alert could just trigger the same thing or even talk to the hidden
> alerts port.)
> 
> While one obvious app is real time database update notifications, this
> port could also exist for future collaborative or P2P applications in
> the system.
> 
> This is all a lot more work.  E-mailed mythfilldatabase XML or SQL
would
> be vastly easier to implement, but I presume there are many who can't
> get E-mail anywhere in range of their myth box.  (You could install
> an MTA on your myth box but that's pretty drastic.)  E-mail, unlike an
> alerts port, has lots of extra reliability measures to assure
delivery.