Call for tester for 1.4.0 features and fixes (2 Viewers)

[Scythe42]

@ripk: can you test the attached build if it solves your problems?

Edit: Removed temp. test build.

 

[ripk]

I see, then this is correct behavior. I know you tried to "trick" MP by moving it a bit out of screen in hoping you can resize it. Nope, no bug here you can exploit.

As soon as you resize MP it will "snap" to the screen it was bound to before the re-sizing attempt.This is because we have some limitations in the code that would make other problems visible. With that behavior we have always a defined state.

There is also a second thing under Win8 for example when you bump a Window to a screen side. Windows will resize the Window. When you drag to to the right edge of the screen it will distort MP as well as Windows forces it into some special "portrait" mode by telling an application that the screen bounds are different. *sigh*

Just to make clear: these are not bugs of this build. These are just things are not handled at the moment.

Sure, not perfect but I don't want these Area 51 builds to continue forever. What ever small glitches are visible will get a new Mantis entry and are dealt with at an appropriate time. It's not like users are constantly re-sizing and moving the MP window. Also the majority uses full screen anyway.

Didn't think these were bugs, don't get me wrong I was just trying to be as elaborate as possible to point out the differences in behaviour between the official release and your build in order to paint a clear picture for you on how the thing is behaving. My only concern at the moment is the 1024 restriction and I'm glad you were able to understand why this is happening...

I think you are doing a great job, and I am really grateful that the half-screen problem is getting some attention (along with a major overhaul on the D3D!)

 

[Scythe42]

No problem. I am not offended here. The more people elaborate what feels strange to them, the better. Some stuff will be fixed at a later date depending on how critical I think it is at the moment.

As said, I know what's happening on your system and now we need to test some builds for you until the issue is resolved as I cannot reproduce it on my system. But I think I identified the root cause.

So let's see how Build 15b is doing on your system that I attached two post up.

Edit: Regardless if it works or not, please provide logs as I added some debug info as well.

 

[ripk]

@ripk: can you test the attached build if it solves your problems?

Works like a charm!

Tortured it both in full screen and windowed and it recognizes the correct resolution no problem! Windowed mode restores to 1024 but as soon as I drag the corner a bit, the ratio corrects and window is able to grow to a larger size!

Did a couple of cycles in fullscreen and everytime the TV is filled with a fully spread-out MePo I'm keeping this build as it is

Wunderschön, vielen Dank @Scythe42

 

[Scythe42]

Cool that it worked on the first attempt. That the window with 1024x768 is in the wrong aspect ratio is one of the things I have not handled yet and will do sometime in the future.

Let's take a look at the relevant parts from the log:

[2013-04-06 22:25:13,250] [40200  ] [MPMain  ] [INFO ] - D3D: Restoring from tray
[2013-04-06 22:25:13,260] [40210  ] [MPMain  ] [DEBUG] - Main: WM_GETMINMAXINFO
[2013-04-06 22:25:13,260] [40210  ] [MPMain  ] [INFO ] - Main: Screen MP is displayed on changed to:
[2013-04-06 22:25:13,260] [40210  ] [MPMain  ] [INFO ] - Main: Bounds of display changed from 1920x1080 to 800x600

Interesting... That should not be the case. But not a biggie as MP is not visible yet anyway. That must be the iMon software causing this as the 800x600 are not the native resolution of your secondary LCD. Or the task bar is only on this monitor.

[2013-04-06 22:25:13,280] [40230  ] [MPMain  ] [DEBUG] - Main: WM_GETMINMAXINFO
[2013-04-06 22:25:13,280] [40230  ] [MPMain  ] [INFO ] - Main: Screen MP is displayed on changed to:
[2013-04-06 22:25:13,280] [40230  ] [MPMain  ] [INFO ] - Main: Bounds of display changed from 800x600 to 1920x1080

But we are back where we belong 20ms later on the next frame. Will not investigate this. One frame wrong during making MP visible again? Nah, not wasting time on that one. Especially not if this 800x600 iMon stuff comes into play.

[2013-04-06 22:25:30,822] [57772  ] [MPMain  ] [DEBUG] - Main: WM_DISPLAYCHANGE
[2013-04-06 22:25:30,832] [57782  ] [MPMain  ] [INFO ] - Main: Resolution changed to 1024x768x32 or displays added/removed
[2013-04-06 22:25:30,842] [57792  ] [MPMain  ] [DEBUG] - Main: WM_GETMINMAXINFO
[2013-04-06 22:25:30,842] [57792  ] [MPMain  ] [INFO ] - Main: Screen MP is displayed on changed to:
[2013-04-06 22:25:30,852] [57802  ] [MPMain  ] [INFO ] - Main: Bounds of display changed from 1920x1080 to 1024x768

Display turned off, we resize ourselves to 1024x768. No aspect ratio correction takes place. In theory it should do in windowed mode. But that is not implemented yet as it is of low importance. Did not check if you ran fullscreen or windowed.

[2013-04-06 22:25:31,836] [58786  ] [MPMain  ] [DEBUG] - Main: WM_DEVICECHANGE (Event: 32772)
[2013-04-06 22:25:31,836] [58786  ] [MPMain  ] [DEBUG] - Main: Audio Renderer NVIDIA High Definition Audio removed

Audio renderer removed as expected.

[2013-04-06 22:25:42,078] [69028  ] [MPMain  ] [INFO ] - Main: Resolution changed to 1920x1080x32 or displays added/removed
[2013-04-06 22:25:42,088] [69038  ] [MPMain  ] [DEBUG] - Main: WM_GETMINMAXINFO
[2013-04-06 22:25:42,088] [69038  ] [MPMain  ] [INFO ] - Main: Screen MP is displayed on changed to:
[2013-04-06 22:25:42,088] [69038  ] [MPMain  ] [INFO ] - Main: Bounds of display changed from 1024x768 to 1920x1080

Display turned on again and we resize ourselves to back to 1920x1080 if we were in fullscreen before. In windowed mode, we do nothing. Here I will insert a check for a correct aspect ratio at at future date. Not for this series of builds.

[2013-04-06 22:25:43,242] [70192  ] [MPMain  ] [DEBUG] - Main: WM_DEVICECHANGE (Event: 32768)
[2013-04-06 22:25:43,243] [70193  ] [MPMain  ] [DEBUG] - Main: Audio Renderer NVIDIA High Definition Audio connected

Roughly a second later Windows got the HDMI audio renderer back. At this time I should check if the volume handler is still operational and not re-init it.

[2013-04-06 22:26:16,396] [103346 ] [MPMain  ] [DEBUG] - Main: WM_GETMINMAXINFO
[2013-04-06 22:26:16,396] [103346 ] [MPMain  ] [INFO ] - D3D: Client Size: 1280x720
[2013-04-06 22:26:16,396] [103346 ] [MPMain  ] [INFO ] - D3D: Screen size: 1920x1080

Looks like you are using 720p skin here. Should have no visible impact beside that scaling of the graphics need to take place. MP renders internally with 1920x1080 anyway, meaning the size of the display it was started on.

[2013-04-06 22:26:23,714] [110664 ] [MPMain  ] [DEBUG] - Main: WM_GETMINMAXINFO
[2013-04-06 22:26:24,644] [111594 ] [MPMain  ] [DEBUG] - Main WM_SIZING
[2013-04-06 22:26:24,644] [111594 ] [MPMain  ] [INFO ] - Main: Aspect ratio safe resizing from 1296x778 to 1341x803 (Skin resized to 1325x745)

You did some resizing. Aspect Ratio correction (taken from the skin dimensions) are taken into account.

Then you turned off/on again. Same stuff in the logs, so it is consistent.

Will include the change in the next build.

 

[Scythe42]

...but if you than start the playback again you can't control the volume anymore.

@FreakyJ: Can you test the attached build how it behaves in regards to Volume Control? I added some debug code to logging that could tell me more.

@Lightning303: could you also do a test? I know from your logs that the Volume Handler threw some errors. Also want to make sure that I didn't break the fix I added for your scenario (freezing after multiple hibernate/resume cycles).

 

[FreakyJ]

nice job! looks like it works

What I've done:

- start MP
- go to EPG => start a channel
- plugged off the hdmi cable
- waited 10sec
- plugged it in again
- started the same channel again
Result:
- MP showed the EPG
- I have GUI sound
- I had also volumecontrol

 

[FreakyJ]

A second test:
Here I disabled the option: Stop playback by Audiorenderer lost
I know why this option exist and that there is currently no support from the directshow side to resume the audio, but I wanted to provide logs, just in case you can gather any useful information for whatever

What I've done:
- start MP
- EPG => start watching a channel
- unplugged hdmi cable
- waited some time ~10-20sec
- plugged it in again
- it still showed the video, but there was no audio anymore
- tried to change the volume: I saw the volumeindicator but than the dialog came: "MediaPortal ahs stopped working", but playback was still running, I clicked "close Apllication", nothing happend, wanted to close MP with alt + F4 => MP freezes, killed it with the task manager

Overall I have to say THANK YOU!
Your build is working great, also I have the feeling that the GUI is more smooth, but maybe it is just a subjective feeling
I also tried MyTvSeries yesterday and had no issues Everything went fine^^

 

[Scythe42]

Thanks for testsing. Looks like the re-initialization of the volume handler works.

Nothing special in the logs. The errors are from some "incompatible plugins". Probably because of the versions of these builds. I did not mark anything as incompatible.

Regarding the crash: yes, that is because playback is not stopped and the audio renderer used in the Direct Show Graph is gone. As a workaround there's the option you mentioned, which is checked per default. That will hold until this is handled on the Direct Show side.

But you know that already. Just mentioning it for others again.

So that leaves a few minor glitches I am aware of and the zapOSD issue and I guess we are done unless new errors get reported.

Guess we will not reach Build 20 then unless I miss the 1.4.0 deadline...

 

[elliottmc]

@Scythe42 - I still see a white screen briefly during loading. This is just on a system with a VGA monitor. Haven't tested with the absolute latest, but I did test a couple of days ago. If necessary I can video the startup on my phone so you can see it.