[mythtv-users] Strange scheduling behavior: duplicate events in "Upcoming Recordings" in MythWeb

[Michael T. Dean]

  On 11/09/2010 02:17 PM, E. Westbrook wrote:
> On Tue, Nov 9, 2010 at 11:57, Douglas Peale wrote:
>> How are you determining that they were recorded on the same channel?
>> An older version of MythWeb would get confused when this situation occurred
>> (the reason this thread got started in the first
>> place) and report two recordings on the same channel at the same time when
>> in fact they were on different channels.
> The "chanid" field is 1041 in both rows of the dump I posted earlier in this
> thread.
>
> The FE also lists both as channel 4_1 which corresponds to chanid 1041 in my
> database.  I am not using mythweb at this time.

So, either you had a recording fail while in progress (i.e. due to 
backend reboot) or have bad listings.

 From your data, it looks like the latter (as the program start time and 
end times--in addition to the recording start/end times) differ.  This 
is something I'd expect to occur only with EIT data (especially the 
program start times like:

2010-11-08 03:10:15
and
2010-11-08 03:10:02

(note the seconds on the end).  Note that you shouldn't be using EIT on 
the same channel for which you're using XMLTV or using Schedules 
Direct.  If you're using only EIT on these channels, then all I can say 
is that MythTV is only as good as the listings you feed it...  :(

If EIT changed the start time after the first show began recording, the 
show would be seen as a new show--since  there's no show with the 
channel ID and (program) start time currently recording.

Could MythTV be made to realize that it just updated the existing 
program data for the show that's currently recording?  Sure, someone who 
was sufficiently interested could do so.

However, based on the show you're talking about, I'm guessing you're 
eligible for using Schedules Direct data.  If so, IMHO, $20/year is a 
/lot/ cheaper than coding the above correctly.

Oh, and if you are using Schedules Direct and not using EIT on that 
channel, the only way the listings could have changed while you were 
recording is if a) you used mythfilldatabase --dd-grab-all and b) you 
got /really/ unlucky on picking up a schedule change (just /after the 
last second, even :).  If that's the case, it should be a very uncommon 
occurrence, so probably not worth worrying about.

And, when it all comes down to it, what happened is actually the best 
possible result.  MythTV recorded too much instead of too little.  A 
quick delete fixes all the problems.  And, it's really a lot easier to 
do that delete than to go back in time to record something that MythTV 
decided not to record because it tried to be too smart.

Mike