or Connect
AVS › AVS Forum › Video Components › Home Theater Computers › Cliff Watson EPG add-on for MyHD, FusionHDTV, and HD Homerun
New Posts  All Forums:Forum Nav:

Cliff Watson EPG add-on for MyHD, FusionHDTV, and HD Homerun - Page 122

post #3631 of 3896
Thread Starter 
Yes, MyHD requires the 32-bit version of Windows (all flavors). If you're a MyHD user there very few reasons to change to a newer OS than XP. I was running the above experiments using W7-64 on a Zotac Zbox Nano AD10 Plus with 4-GB of RAM and a 2-TB WD Green HDD in an eSATA enclosure together with Fusion7 HDTV USB and HDHR tuners.

Edit: BTW, the HDD and tuner ac adapters are plugged into a smart strip controlled by the Zotac box so that there's no zombie load from them when the HTPC is asleep. This setup works very well as a DTV recorder!
Edited by TPeterson - 6/15/12 at 1:08pm
post #3632 of 3896
Quote:
Originally Posted by TPeterson View Post

Yes, MyHD requires the 32-bit version of Windows (all flavors). If you're a MyHD user there very few reasons to change to a newer OS than XP. I was running the above experiments using W7-64 on a Zotac Zbox Nano AD10 Plus with 4-GB of RAM and a 2-TB WD Green HDD in an eSATA enclosure together with Fusion7 HDTV USB and HDHR tuners.

Wow...Did I read that right? .... MyHD on 32bit win 7... eek.gif
I didn't even think to try it. Are there any issues? I just bought a 3-pack of 32bit win 7 Home Premium. Put one copy on an old VAIO Desktop, and was hashing with the idea of departing with the MyHD. Oh sooo glad to read this. biggrin.gif

Thanks,
Chris
post #3633 of 3896
Thread Starter 
"Issues"? Don't get Nani started!

Yes, there are some (IMO, minor) issues, such as the fact that the overlay window doesn't want to stay the same size but keeps getting smaller and smaller.... But the plain fact is that if you have some other reason for updating your OS you don't have to abandon your MyHD it will continue to work, as long as you don't switch to a 64-bit version.
post #3634 of 3896
Hi, Terry.

My memory is quite bad for W7, I just know that I was driven back to XP.

If I changed "MyHD on Vista Main Thread" to

"MyHD on Vista & W7 / W8 Main Thread"

or "Wx" to be future proof,

would you and others be interested to document the Wx HTPC problems?

I was going to build the list but I just did not.

Positive comment to:

http://www.avsforum.com/t/797208/myhd-on-vista-main-thread

please.

Wow, they did away with the "Old Post" nag box.

(Off topic for CW_EPG)

SHF
post #3635 of 3896
Quote:
Originally Posted by SFischer1 View Post

Hi, Terry.
My memory is quite bad for W7, I just know that I was driven back to XP.
If I changed "MyHD on Vista Main Thread" to
"MyHD on Vista & W7 / W8 Main Thread"
or "Wx" to be future proof,
would you and others be interested to document the Wx HTPC problems?
I was going to build the list but I just did not.
Positive comment to:
http://www.avsforum.com/t/797208/myhd-on-vista-main-thread
please.
Wow, they did away with the "Old Post" nag box.
(Off topic for CW_EPG)
SHF
wink.gif
Thanks for the feedback....and to SFischer1 for the pointer to the vista tread..... I'll start reading there.
Been putting off departing from XP for a long time. Since MS is 'kicking us to the curb' in a year, I thought I'd better at least update my most frequently used systems.

Again Thanks,
post #3636 of 3896
I've been running CW_EPG successfully for quite a while on an old, slow XP system using 2 HDHR dual tuners and a MyHD card. I'm trying to move it to my latest build, a Core-i5 system dual-booting Win 7/64-bit and Linux (Windows is the default; Linux asks too many pesky questions at bootup). I know I can't move the MyHD card but the 4 HDHR tuners should be enough.

I currently have the BIOS RTC set to UTC rather than local time. Ubuntu prefers that so I tweaked the Windows registry to accept it as well. CW_EPG does what it should as long as the new PC is already running but it won't wake it at the right time. Before I updated the BIOS yesterday it wouldn't wake the computer at all; today it woke it 4 hours early (I'm on EDT, 4 hours behind UTC). So I could probably fix things by setting BIOS time to local, undoing the Windows tweak and hunting up a similar fix for Linux. But first I'd like to know if this is normal operation or if Windows is supposed to compensate for the difference when it sets a wake timer. Is anyone else using CW_EPG with the BIOS set to UTC?

BTW, powercfg -waketimers shows two identical timers set for the daily download:
Code:
Timer set by [PROCESS] \Device\HarddiskVolume2\Apps(x86)\CW_EPG\CwHelper.exe expires at 16:53:30 on 06/18/2012.

Timer set by [PROCESS] \Device\HarddiskVolume2\Apps(x86)\CW_EPG\CwHelper.exe expires at 16:53:30 on 06/18/2012.
Is this normal?
post #3637 of 3896
Thread Starter 
ebo, I believe that Windows is designed to compensate for timezone offsets (and, e.g., actually uses UTC for file timestamps) but it also assumes that the RTC is set to local time, which would be why your machine's wake timer based on the RTC is incorrect. I'm afraid that proper CW_EPG operation will require the RTC to conform to Windows' expectation.

Yes, CwHelper does sometimes duplicate wakeup timers. This normally doesn't cause any fatal problems and at worst can cause a stray wakeup after you've deleted a scheduled capture. The PC then just goes back to sleep after your Power Options timeout setting.
post #3638 of 3896
I changed BIOS time to local and undid the registry tweak (if anyone cares, under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation set DWORD "RealTimeIsUniversal" to 1 for UTC or 0 for local). I set a test recording and the computer awoke from S3 sleep and started it on time. Haven't tried S4 (hibernation) or hybrid (S3 for a while, then S4) but they'll probably work.

Now I'll have to hunt up a tweak for Ubuntu. I'm sure a quick search will turn it up. I predict it'll be an inscrutable terminal mode line beginning with "sudo" and I'll probably have to reenter it every time I upgrade Ubuntu.

How does CW_EPG set a wake timer? I presume it uses a Windows service like Task Scheduler. I'd think the service should be smart enough to check that registry setting and, if the BIOS is using UTC then check the local offset and adjust the wake timer. Or maybe CW_EPG could do that itself. There are certain advantages to using UTC in the BIOS, which is why most major OSs default to that.
post #3639 of 3896
Quote:
Originally Posted by ebo View Post

How does CW_EPG set a wake timer? I presume it uses a Windows service like Task Scheduler. I'd think the service should be smart enough to check that registry setting and, if the BIOS is using UTC then check the local offset and adjust the wake timer. Or maybe CW_EPG could do that itself. There are certain advantages to using UTC in the BIOS, which is why most major OSs default to that.
Code:
     * BOOL WINAPI SetWaitableTimer(
     *       __in      HANDLE hTimer,
     *       __in      const LARGE_INTEGER* pDueTime,
     *       __in      LONG lPeriod,
     *       __in_opt  PTIMERAPCROUTINE pfnCompletionRoutine,
     *       __in_opt  LPVOID lpArgToCompletionRoutine,
     *       __in      BOOL fResume
     *     );

...where pDueTime is ms from now.

When a request comes in from the main part of the program for a recording event, an instance of a Calendar object for the starting event is created. The Calendar returned is based on the current time in the default time zone with the default locale. The Calendar object is cleared, and the setTime method is used, parsing the date string passed in. All the timer work is done in milliseconds from "now". That count of ms comes from doing start.getTimeInMillis() - new Date().getTime(), where start is that Calendar object. Both are in ms from the epoch.

--Dale--
post #3640 of 3896
Thread Starter 
So, ebo, evidently the Windows API routine is not smart enough to check that Registry flag to find out that the RTC is set to UTC. frown.gif
post #3641 of 3896
Quote:
Originally Posted by TPeterson View Post

So, ebo, evidently the Windows API routine is not smart enough to check that Registry flag to find out that the RTC is set to UTC. frown.gif
Well, the Windows API is just taking milliseconds from now, so it's oblivious. The Java Calendar and/or Java Date is out of whack with the start date time string that's passed in.

--Dale--
post #3642 of 3896
Hi,

Any knowledge of the resulting registry string, there are so many places that do the same thing.

Wake up is one thing I want to know as it took so long to finally discover that it was Windows Media Center that was turning my Vista laptop on during the night draining the battery.

TIA

SHF
post #3643 of 3896
Thanks, Sengsational and TPeterson, for that explanation. I don't claim to understand it perfectly but I get the idea. Kind of like reading a foreign language with some similarities to English. But I like the conclusion: it's Java's fault. That supports what Steve Gibson says on Security Now: if you don't need Java, get rid of it. Unfortunately, I need it. Some of my reading said that Windows 7 uses UTC for some of its internal operations regardless of the setting of RealTimeIsUniversal, so I'd have been surprised if they had forgotten about it when setting a wake timer. I didn't notice if there was any difference in Win7's own wakeups between when I had the RTC set to UTC and now.

Like SFischer1, I was annoyed that my computer would wake up for no apparent reason. I'm getting better at tracking down the causes. I've found that "powercfg -lastwake" never tells me anything useful but "powercfg -waketimers" tells me when CW_EPG is planning to do something. The best resource is usually the Event Viewer, under Windows Logs|System to see what happened just after it awoke. Mostly WMC updates even though I don't use WMC, or Windows phoning home about my "Experience" (I hate that and thought I'd turned it off).
post #3644 of 3896
Thread Starter 
While I'm not a Java fan, I don't see how this could be Java's fault. If the milliseconds-from-now (delta-t) calculation is actually done in local (default) time it should be impervious to the RTC's settings and the Registry flag. It's the Window API that's responsible for converting milliseconds-from-now to the appropriate parameters for the RTC and that's where knowledge of the RTC's timezone is needed.

The only way that CwHelper (i.e., Java) can be at fault is if it's not really using the same TZ for both ends of delta-t. Dale, is that what you're saying is the case?
post #3645 of 3896
Quote:
Originally Posted by ebo View Post

That supports what Steve Gibson says on Security Now: if you don't need Java, get rid of it.
Yeah, Java, Shockwave, Flash, etc, etc. But it bugs me he never says the same thing about the dot net framework. It's basically the same thing as Java...a runtime engine that's not required to run Windows. The only difference is that Windows Update will try to push a new copy on you if you delete it. But dot net is always getting exploited, and I've removed it, and I just keep my Java up to date. But I digress.
Quote:
Originally Posted by ebo View Post

But I like the conclusion: it's Java's fault.
I wouldn't say it's Java's fault. It's probably just that I coded it for 99.999% of the people. There's always somebody on the fringes, hehe.

--Dale--
post #3646 of 3896
Quote:
Originally Posted by sengsational View Post

I wouldn't say it's Java's fault. It's probably just that I coded it for 99.999% of the people. There's always somebody on the fringes, hehe.

--Dale--
Yeah, that's always been Windows' biggest problem too. It's coded for the 99.999% of us who don't try to overflow its buffers or do other unexpected things to it just to see what happens.
post #3647 of 3896
Hi,

Edit: XP is the OS.

MSE=? (MSFT Security Essentials? ) YES! That is the BSOD and it is MSE that is the cause. Using SAFE mode and turning Real Time Monitoring off allows booting, other wise it is a continuous loop. DEP (Data Execution Prevention) is suspected but I cannot find the event log entry to prove it. Motherboard had memory socket problems in the past. Freezing the computer on BSOD is planned when I am up to it.

CW_EPG never has had a BSOD AFAIK ever. biggrin.gif

Quote:
The padding is omitted for various reasons, so you may be running into some constraint that you're not expecting and that's why it disappears on some occasions.

Note: It is the listing window that offers the padding. As the program has already started the start padding must be and is ignored. The end time padding can be applied. (Just an annoyance.)
Quote:
You seem to be suggesting that HDHR recordings are not occurring as scheduled...this is highly unusual. That plus the BSOD causes me to suspect hardware/OS installation issues.

Yes, HDHR recording failures I have not seen before ~ four months ago. BTW, Fusion mad.gif may be playing back a previous capture but VLC media player is in use more of the time. (I must be watching a capture to note the HDHR light not on when expected.)

OS has not been reinstalled for a long time.

Yes, hardware is suspected. HDHRs, NAS and computer cables just have been disconnected and reconnected, all have been deadstarted.



I have three items, perhaps related. Last night it was Leno.

1) Right clicking a program (Leno or Letterman, PBS Newshour ...) in the listings window and selecting "Schedule Capture (default padding) always produces (no padding) even when an matching entry is in the match list. It's the end padding not being added that is the problem.

2) Why do I wish to do #1? When the entry IS in the match list and has been scheduled and SHOULD have started already on one of my HDHomeRun tuners and I just caught the error and wish to start another capture to get the rest of the program.

I am looking for an debugging technique. I have dead started both of the two HDHRs and my Wireless router and sometimes the problem does not occur again for a time (Days, Weeks). This messes up CW_EPG which must be started twice to get back in sync.

3) MSE gives a BSOD on booting and I must use Safe mode to turn off RT monitoring. Two UN-installs and reinstalls plus searching the MSE web page have not helped. MSE icon is red with "X". (I feel safe with NO RT monitoring. I can wipe HD and reinstall very quickly.) I cannot find the BSOD data in the event viewer on XP where it appeared before.

frown.gif

SHF
Edited by SFischer1 - 6/30/12 at 10:25am
post #3648 of 3896
Thread Starter 
Nani, would you care to try that post again, starting from the top? I can't follow it. What OS are you using this week? MSE=? (MSFT Security Essentials? I can think of no reason that it would have any problems with CW_EPG and I've not see it BSOD ever)

The padding is omitted for various reasons, so you may be running into some constraint that you're not expecting and that's why it disappears on some occasions.

You seem to be suggesting that HDHR recordings are not occurring as scheduled...this is highly unusual. That plus the BSOD causes me to suspect hardware/OS installation issues.
post #3649 of 3896
Quote:
Originally Posted by TPeterson View Post

Nani, would you care to try that post again, starting from the top? I can't follow it. ...

Hi,

OK, I started over at the top.

Perhaps confusing for some readers. confused.gif

SHF
post #3650 of 3896
Thread Starter 
I meant that you might actually replace the stream-of-consciousness with a more readable statement of the issue(s). Not add to the confusion by making an out-of-sequence response!
post #3651 of 3896
Hi,

Brain not working very well, sorry. redface.gif

A. Nani Mouse
post #3652 of 3896
Quote:
Originally Posted by SFischer1 View Post

I have three items, perhaps related. Last night it was Leno.
1) Right clicking a program (Leno or Letterman, PBS Newshour ...) in the listings window and selecting "Schedule Capture (default padding) always produces (no padding) even when an matching entry is in the match list. It's the end padding not being added that is the problem.


Right-clicking on listings and scheduling with default padding works fine for me.

Remember that scheduling this way uses DEFAULT PADDING as defined on the Options page. If you have Leno in your Match list and have padding defined there, that is NOT used when schedulilng from the Listings.
post #3653 of 3896
Quote:
Originally Posted by hdtvincr View Post

... If you have Leno in your Match list and have padding defined there, that is NOT used when schedulilng from the Listings.

Hi,

frown.gif That's what I saw.

It would be more clear if the (Default Padding) options were grayed out in the right click menu in the listing.


Question, when the HDHR code starts to get ready to make a capture, is there an entry made in a log or a file?

This would help me determine if the code was started or not. The other case is that it is started but fails to find any data for the capture or cannot connect to the HDHR tuner.

I have detected in live time only three failures and it is unknown if others failed also.

Hard to determine what is wrong with so very few failures,and if they will continue. So far after removing and replacing all my cables and restarting all hardware I have spotted none. KOW

SHF
post #3654 of 3896
I have been running WinXP with CW-EPG and a single HDHR successfully for over a year. CW-EPG cannot find my HDHR tuners anymore. I re-installed CW-EPG and the tuners are found and the schedules schedule but after a reboot the tuners are not found. I did check and the CWHDHR helper is running in task manager . Any suggestions?

Thanks
post #3655 of 3896
Thread Starter 
JStegin---

What did you change just prior to this problem's appearance?
post #3656 of 3896
Quote:
Originally Posted by TPeterson View Post

JStegin---
What did you change just prior to this problem's appearance?

Something that may have changed his system is Automatic Updates for Windows XP (Microsoft "Patch Tuesday" for the month of July happened this week). I haven't seen any issues on my XP machine (also using CW_EPG + HDHR here), but I have Automatic Updates turned off. I apply the patches manually -- and never before making a full backup of my system partition first!

Maybe a security patch for .NET Framework was issued this month that is causing an issue with CW_EPG. If so, then most likely other users will come forward and report it.

@JStegin:
Maybe check and see if Automatic Updates installed any fixes or updates to .NET 2.0, 3.5, etc., and if so, see if you can uninstall them. CW_EPG requires .NET, so it might be worth checking there first.
Edited by Vlad Theimpaler - 7/12/12 at 2:23pm
post #3657 of 3896
I did update the HDHR software from another network box about 2 weeks ago. I also do have auto updates set to off.

I could install an image from 4/11 and transfer the mdb database if needed.
post #3658 of 3896
Thread Starter 
Before backing up to an older image, it'd be worthwhile to try using a few of your recent System Restore points and see if that can fix the problem.
post #3659 of 3896
I have tried some restore points from June, I will try a few more. Also, I did see .DOT 4 on the machine and just uninstalled it but no change.

Thanks

edit: Looks like HDHomerun sw needs the .DOT 4 so I will try my image
post #3660 of 3896
Thread Starter 
I rather doubt that it's a MSFT-induced problem, as there'd be more than one report of it. Try to think of something more out of the ordinary that you did and then reverse that change.
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Home Theater Computers
AVS › AVS Forum › Video Components › Home Theater Computers › Cliff Watson EPG add-on for MyHD, FusionHDTV, and HD Homerun