Scythe42's fixes for 1.4.0 (1 Viewer)

[Atomic7431]

i been waiting [DOUBLEPOST=1367343107][/DOUBLEPOST]tested first one and its still the same logs attached.

 

[radical]

I will try out your advice to disabling the taskbar flickering and report if it got any effect.

I can confirm for MP 1.3 that, disabling the flickering help a lot against MP losing focus.

Here my is my short testing with Client only Installation connected to 1.3 Final TV-Server.

My 2 display Setup

Screen 1:LCD-TV
Resolution: 1920x1080
Connection: HDMI
Position: Left
Primary: No
MP-Start: Yes
Taskbar: No

Screen 2: LCD-Monitor
Resolution: 1920x1200
Connection: DVI-D
Position: Right
Primary: Yes
MP-Start: No
Takbar: Yes

With latest build from first post I don't have any Problem with MP on secondary Screen. Resolution is Fitting.

Live and recorded tv is working good. It has automatically switched to 50hz. No dropped Frames at all.

 

[Scythe42]

Can reproduce now.

Centarea takes HID input (regardless from which device, e.g. the keyboard) and execute the action. It could already have been executed before. Don't really get it. This makes absolutely no sense.

If HID message are triggered by a remote, there is no need for any special remote support at all. You are basically trying to remap all HID input. And this happens as soon as it is activated. Even with a keyboard as it reacts to all Windows messages.

MP processes the HID message, Centarea Plugin processes it again. That makes no sense code wise. If a remote sends HID codes, the plugin should do nothing with it and let MP process it like any other HID code.

This is just so screwed up code and makes no sense to me.

I actually need to find a way to have MP not process certain messages when Centarea Plugin is activated. What a mess. Try and error for me.

That it worked on 1.3.0 is pure coincidence. Probably Centarea plugin was called before MP had a change to process the message. And now stuff is faster it does not anymore. It should have never worked properly before... The whole implementation requires buggy message handling on the MP side.

 

[Scythe42]

Yeah, WndProc() of InputDevices is broken and relies on something you should never do.

There is an msg.Result for a reason that you can set if your message was already processed, so that no other WndProc gets it. This is not properly set. Instead there are some arbitrary booleans, resets of msg.Result values, returns etc.

I broke WndProc() again for the sake of catching the train. Will change and refactor to proper WndProc() handling for 1.5.0. Can re-introduce issues I thought I fixed though, but all these can be triggered on 1.3.0 as well.

This change by me is there since the first Area 51 build *sigh*. But good that we caught it. Probably other stuff even relies on it as well.

Please test if this fixes it.

 

[azzuro]

Build 29/04/2013 Tested on an old Laptop with Win7 ( only if MP start) , Mp start without problem
with Radeon 9700 mobility & P4 3.2

​

 

[Atomic7431]

yep seems fixed here

 

[Scythe42]

Cool... Will format the code changes I do a commit to GIT within the hour.

 

[Sebastiii]

Cool... Will format the code changes I do a commit to GIT within the hour.

I can confirm fixed on my side too

 

[Atomic7431]

fingers crossed this makes the cut off, so much work gone into this and many many fixes. Let me be the first to congratulate all involved

 

[edterbak]

OK,

Ran the latest build. Did some testing and I couldnt see major issues Fast as hell and very responsive btw.