Hi Steve, long time no talk. Yes of course running good up to now and of course ran into same problem as this topic addresses. What I found interesting of my two recorders. #1 did not run into this problem (does not work as hard but did have a show correctly set to record on Nov 5). System #2 of course did, so after many painful attempts, reloaded #2 from the last clone I of it made on 7/7/20, and of course that did not help (if system #1 working I figured maybe how a software glitch - both systems running windows 7 with all updates turned off!). So to this path after more crazy attempts.
From your last statement on this thread, tired setting local time to Eastern standard time on my old version. No Change same error.
Then downloaded and installed above update and re-ran with time change. All worked.
Great job, and good timing on my part running into the problem.
Hope life is better in NZ than in US, Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Jim beat me to the good news that the new verions seems to fix the problem. I first ran it on a 7 day update, and then I did it on my normal 14 day update. Both seem to load without probems.
Carl
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'll do a proper release in the next few days. It will be the same as the version above.
Hi Jim,
Keep in mind the phrase 'things can only get better'. Mind you, never actually believed it myself.
Life in NZ is pretty good as usual. But then it's easier when you live on a small island 1,000 miles from the rest of civilisation at the back end of the world with a small population and a (mostly) popular leader who knows what they are doing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One point about the fix. When you change back to summertime in around 6 months time you might notice the odd gap in the guide around the DST change time.
This is because, if say the clocks change at 2am, a programme lasting an hour might start at 1.30am and, with the fix the duration will be correct so the programme will finish at 2.30 am but I assume the zap2it data won't have the next programme starting until 3.30am.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Steve, Just DL'd your most recent EPGC install above and ran it with my original settings ('run standard tasks' and local time zone) - no issues to report :) Guide behaving itself and no mcupdate crashes...
Thanks for jumping on this and getting it resolved so quickly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had two Questions, but I believe I may have the answer for the first one (if you concur):
I was wondering why System #1 did not have the above problem that System #2 did? I believe the answer was because System #2 had a recording set to happen on Nov 1 at 2 am, System #1 did not. Reasonable?
When I restored the 7/7/20 clone of System #2, I expected all channel physical settings to carry forward that had been set before that date. Instead channel 8 & 44 were both wrong (I had changed them both before 7/7/20) and had to be reset. Where is this information stored? Obviously not in software (my clones are of the entire operating system and applications full disk clone – the only thing not included on these clones is the recorded shows – which is on a separate disk). And that information must not be on the Hauppauge cards otherwise that data would still be intact? So where else is there?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Steve,
No. I checked the dll version number I used with the version listed in the log you posted. They are the same.
Try the attached.
My previous attempt only worked if you selected a timezone on the Import tab.
Hi Steve, long time no talk. Yes of course running good up to now and of course ran into same problem as this topic addresses. What I found interesting of my two recorders. #1 did not run into this problem (does not work as hard but did have a show correctly set to record on Nov 5). System #2 of course did, so after many painful attempts, reloaded #2 from the last clone I of it made on 7/7/20, and of course that did not help (if system #1 working I figured maybe how a software glitch - both systems running windows 7 with all updates turned off!). So to this path after more crazy attempts.
From your last statement on this thread, tired setting local time to Eastern standard time on my old version. No Change same error.
Then downloaded and installed above update and re-ran with time change. All worked.
Great job, and good timing on my part running into the problem.
Hope life is better in NZ than in US, Thanks
Steve,
Jim beat me to the good news that the new verions seems to fix the problem. I first ran it on a 7 day update, and then I did it on my normal 14 day update. Both seem to load without probems.
Carl
I'll do a proper release in the next few days. It will be the same as the version above.
Hi Jim,
Keep in mind the phrase 'things can only get better'. Mind you, never actually believed it myself.
Life in NZ is pretty good as usual. But then it's easier when you live on a small island 1,000 miles from the rest of civilisation at the back end of the world with a small population and a (mostly) popular leader who knows what they are doing.
One point about the fix. When you change back to summertime in around 6 months time you might notice the odd gap in the guide around the DST change time.
This is because, if say the clocks change at 2am, a programme lasting an hour might start at 1.30am and, with the fix the duration will be correct so the programme will finish at 2.30 am but I assume the zap2it data won't have the next programme starting until 3.30am.
Steve, Just DL'd your most recent EPGC install above and ran it with my original settings ('run standard tasks' and local time zone) - no issues to report :) Guide behaving itself and no mcupdate crashes...
Thanks for jumping on this and getting it resolved so quickly.
I had two Questions, but I believe I may have the answer for the first one (if you concur):
I was wondering why System #1 did not have the above problem that System #2 did? I believe the answer was because System #2 had a recording set to happen on Nov 1 at 2 am, System #1 did not. Reasonable?
When I restored the 7/7/20 clone of System #2, I expected all channel physical settings to carry forward that had been set before that date. Instead channel 8 & 44 were both wrong (I had changed them both before 7/7/20) and had to be reset. Where is this information stored? Obviously not in software (my clones are of the entire operating system and applications full disk clone – the only thing not included on these clones is the recorded shows – which is on a separate disk). And that information must not be on the Hauppauge cards otherwise that data would still be intact? So where else is there?