All,<br>
<br>
I think it's a bug in myth. Here are some screen shots for the following experiment...<br>
<a href="http://www.spartanframeworks.com/Spikey/ScreenShot-Working_845AM_after_running_--refresh-all.gif">http://www.spartanframeworks.com/Spikey/ScreenShot-Working_845AM_after_running_--refresh-all.gif</a><br>
<a href="http://www.spartanframeworks.com/Spikey/ScreenShot-Working_915AM_after_waiting_30_minutes.gif">http://www.spartanframeworks.com/Spikey/ScreenShot-Working_915AM_after_waiting_30_minutes.gif</a><br><br>
1) At 8:45ish I noticed that tonights programming information was an hour early. So I ran "mythfilldatabase --refresh-all"<br>
2) It corrected the programming information (as seen in 845AM screenshot)<br>
3) At 9:15ish I check the program guid again and the info was shifted by an hour again. (see 915AM screenshot)<br>
<br>
I have a theory about what's going on here. I think that when I
run "mythfilldatabase --refresh-all" it's correcting the information in
the DB. However, when the time change happened I had several
recordings scheduled to be recorded into the next week... I'll bet
these "recording times" are stored by the backend and are somehow
getting written over the "good" database information. I don't
know enough about it to point to a piece of code, but I'm hoping that
someone else who does know sees this email. :)<br>
<br>
I have noticed that if I browse very far out, like into next week, all
the timestamps look correct. I know this is not a zap2it issue because
when I run "mythfilldatabase --refresh-all" it's getting the correct
information.<br>
<br>
-Greg<br>