Scythe42's fixes for 1.4.0 (1 Viewer)

Status
Not open for further replies.

Atomic7431

Portal Pro
June 17, 2011
497
71
United Kingdom United Kingdom
i been waiting :)[DOUBLEPOST=1367343107][/DOUBLEPOST]tested first one and its still the same logs attached.
 

radical

Portal Pro
December 16, 2010
1,466
191
Germany Germany
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

Retired Team Member
  • Premium Supporter
  • June 20, 2009
    2,065
    2,703
    47
    Berlin
    Germany Germany
    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.
     
    Last edited:

    Scythe42

    Retired Team Member
  • Premium Supporter
  • June 20, 2009
    2,065
    2,703
    47
    Berlin
    Germany Germany
    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.
     

    Attachments

    Last edited:

    Atomic7431

    Portal Pro
    June 17, 2011
    497
    71
    United Kingdom United Kingdom
    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 :whistle:
     

    edterbak

    Test Group
  • Team MediaPortal
  • March 4, 2008
    2,114
    1,176
    Netherlands Netherlands
    Country flag
    OK,

    Ran the latest build. Did some testing and I couldnt see major issues :) Fast as hell and very responsive btw.
     
    Last edited:
    Status
    Not open for further replies.

    Users Who Are Viewing This Thread (Users: 0, Guests: 1)

    Top Bottom