[mythtv-users] Per-channel time offsets

[Joe Votour]

Chris,

Well I was hoping that this functionality was already
present, but I could do it.  I've been playing around
with MySQL queries in both the C API and PHP at work
lately.  :)

I suppose if I was to do this, I would probably
implement it within mythfilldatabase, with an extra
column (time offset) in whatever table actually holds
the program listings.  Then, when the listings are
downloaded (but just before being put in the
database), I could apply the time change.  Then,
mythtv-setup would have to be modified to allow for
the entry of this offset.

So...  Basically what you suggested.  :)

I don't think that manual recordings would be an
issue, since you're specifying a time and channel.

I'll putter around in the source code and see what
happens with that.  It's better than messing around
with XMLTV content IDs.  :)

-- Joe

--- chris at cpr.homelinux.net wrote:

> On Tue, Nov 08, 2005 at 03:09:40PM -0800, Joe Votour
> wrote:
> > My situaton is that the cable provider for the
> > apartment complex that I live in uses DirecTV for
> > their cable system, and most of the channels
> (except
> > the local ones) are on Eastern feeds.  Most of the
> > listings in Zap2It are correct, but there are
> about 10
> > channels or so that are incorrect - the listings
> are
> > three hours ahead of the programming (so, for
> example,
> > something that the listings show will be on at 9PM
> is
> > actually on at 6PM).
> 
> I don't think you can do per-channel recording
> offsets within MythTV 
> itself, and even if you could it's not really the
> solution you want 
> because the listings would still be lying to you and
> *who knows* what 
> would happen if you tried to manually schedule a
> recording.
> 
> You could always hack something up.... :-)
> 
> The easiest solution would be to change the
> cron.daily/mythbackend 
> script so that once the listings were downloaded you
> would run an SQL 
> update query to update all of the times for the
> affected channels.  You 
> would then have to signal MythTV to re-optimize the
> scheduling.  
> There's probably a signal handler to do that already
> so you'd just need 
> to "killall -s SIGUSR1 mythbackend" or something
> similar.
> 
> A similar solution would be to subscribe to a second
> listing in the 
> eastern timezone and deselect all of the eastern
> channels from your 
> pacific listings.  That way the times would be
> correct, but the eastern 
> listings would not be attached to any tuner.  Again,
> a post-download 
> SQL script to copy the listings from source 2 to
> source 1 and trigger 
> an schedule evaluation would do the trick.
> 
> The best solution, of course, would be to write a
> patch for MythTV that 
> allows it to apply a time delta and reassign the
> channel number on a 
> per-station basis as the data is initially
> downloaded.  Changes would 
> be required in the SQL tables, mythfilldatabase and
> mythtv-setup, at 
> the very least.  Aside from cases where zap2it is
> just plain wrong, 
> this would also help in situations where channels
> have been shuffled to 
> insert local feeds (such as a condo inserting a
> lobby camera feed and 
> putting the original channel elsewhere).
> 
> > _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
>
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
> 



	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com