[fixed] Client Freeze (1 Viewer)

[wjw]

Just an update to report that since replacing the .dll and turning off Powerscheduler shutdown in the client everyhting has worked just fine. Long may it continue!

Thanks to those who looked at this and helped.

 

[mm1352000]

Just an update to report that since replacing the .dll and turning off Powerscheduler shutdown in the client everyhting has worked just fine. Long may it continue!

Excellent!
*Thank you* for reporting back - it is always good to hear that problems are resolved and to have a record of the solution for other people.

 

[Seidelin]

So what do we do to prevent errors like this from happening?

We don't know if it was configuration changes that fixed it, or if it was the exception handling (see attached patch).

 

[elliottmc]

Could the user please test without the replaced dll but with the configuration changes? This should tell us.

Mark

 

[wjw]

OK, I'll do some testing next week - there are several programs scheduled for recording this weekend at times when I won't be here so I don't want to risk altering what is now a very stable setup if I'm not able to fix it.

 

[wjw]

As requested by elliotmc, I reverted yesterday morning to the old plugin.dll but made no other changes (i.e. Powersheduler is activated only in TVServer).

A failure has occurred again today - the first time for just over a week. Once again, MP Client was in a "hang" state.

I still cannot use MP in Debug mode to get the logs - it simply crashed every time without fail. I have therefore tried to collect some of the system event data manually, but am not really sure which ones will help you. The attached zip file contain the entire contents of the Client and Server log directories, plus 2 other files copied from the system event viewer. I hope these are the ones needed - as far as I can tell they are the records relating to the failures today, one each for TVServer and MP Client.

I have now gone back to the replacement .dll file provided by Seidelin

 

[Seidelin]

Since this issue requires code changes (OK'd by arion_p), I will add it to mantis and apply the patch soon (will be included in next release). Thanks for reporting and help with testing.

 

[wjw]

Thanks. I'd just like to add my thanks for all your work on this product. I worked in IT for many years before I retired (all the way up from programming to senior management) and I know just what is involved in producing - and supporting - complex software like this. Amongst other things I know just how important it is that the designers/developers get accurate reports of problems - and just how hard it is to get users to accurately describe what is happening when you're not sitting beside them watching!

Anyway, thanks again.

Out of interest, I would like to know what has been causing my problem when it doesn't seem to happening to others. I would also like to know just why I cannot use the debug mode on my system. I believe that I am running a completely standard system - Win7 32 bit (kept up to date) and no funny software! This is just an HTPC and does nothing else - so why do i get crashes and others don't? In fact, I have another Win7 64 bit system where I have installed a copy purely for testing out the remote TV Server function (on a very minor basis because this machine has other more important uses) and on this one debug mode works perfectly.

 

[Seidelin]

I am pretty sure your issue is caused by your remote (Hauppauge, unless I am much mistaken). The (Hauppauge remote) executable failed to start on resume causing an exception. Since the exception wasn't handled by MP it caused the rest of the wake-up procedure to not be executed. I solved the issue by adding exception handling, which makes sure that the rest of the wake-up is done correctly.

I believe the executable will autostart by itself so I think you won't have problems with your remote after standby.

The problem might be caused by a slight incompatibility between Hauppauge recent (remote handling) software and MP. This we are already trying to solve as well by getting an updated SDK from Hauppauge.

Should you get remote issues now, please report back (again).

I am a bit worried about the crashing debug mode, but that is hard to fix blindly. And frankly, it is not the most pressing issue for us to fix, since logs can be collected manually as well - and you are the only one I know of who experience this issue.

 

[arion_p]

The crash in debug mode described in the first post is cause by a Unicode character that cannot be mapped to ANSI code page when WatchDog tries to export the event log to csv (either application or system log). It could be a directory name, a computer name or anything else. One solution would be to change WatchDog to export to Unicode CSV instead of ANSI CSV, so that no conversion is necessary.