[mythtv-users] How to handle schedule pre-emptions?
Dean at collins.net.pr
Fri Apr 29 22:26:58 UTC 2005
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
> -----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
> > and broadcast database updates for the networks, I could produce
> > 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
> > a perl script.) That changes from system to system so it's not
> > possible to have it slotted in out of the box.
> > Far less efficient would be polling a web address. That could work
> > of the box but it's a _lot_ less efficient and depends on you
> > 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
> 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
> daemon in Myth. This daemon would listen to a port (could be any
> for a very simple command set. One would need to open a firewall/NAT
> to the port, and because of the security risks of doing so, the
> set for the port would be very small, and the commands probably signed
> with a crytographic digital signature. The commands would probably
> 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
> (Alerts could also still come via email for those who could handle
> 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
> 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
More information about the mythtv-users