[Fixed in v3.2] Black band issue at the top of CMC

[Manni]

I often have a black bar at the top of CMC, even when my HTPC starts.

I have to exit, and start it again, and then it's gone.

I've just had the issue after displaying the log from the full scan. You can see one of the report line in the top bar that's usually black, to make it clear that it's not a black bar or a non-addressable part of the display.

IMG_6042.jpg (1.99 MiB) Viewed 8180 times

I don't have that with any other software, so it looks like a CMC bug. The above is what was displayed after I pressed "back" from the text log results.

Of course it makes the bottom of the CMC window not visible.

My screen is 16/9 by the way and the resolution is UHD.

[Pauven]

Do you happen to have a dpi.txt file in your logs directory?

What is your screen resolution (physical and configured)?

Do you have more than 1 screen/monitor?

This looks like a side effect of the scaling logic, and perhaps CMC is getting some bad data about your screen resolution somehow.

[Manni]

Yes, I do have a DPI.txt in my logs dir, it's not been updated since November. I attach it.

My physical and configured resolution is UHD, as I said, so 3840x2160. Scaling is 200%.

My main display is my JVC 4K projector, through my Denon AVR.

I do have a 4K monitor, but that's through my HD Fury splitter, so it doesn't make any difference to Windows. Plus it's the same physical and configured resolution @ 200% scaling.

The only thing that might interfere is that I use remote desktop to log into the HTPC without having to switch on the JVC. You can't change the resolution, so it's also UHD @ 200%, but it might cause some interference.

The screenshot above was taken without using remote desktop or using the splitter, and just the JVC connected as the only display.

[Pauven]

The fact that everything is UHD resolution is good, but with multiple displays (I'm counting remote desktop as a display) being connected/disconnected on occasion, including when/if you change inputs on your Denon AVR, it might be that resolution changes are being presented back to Windows, and these are confusing CMC.

I recently disabled the dpi.txt generation with v3.1, thought I didn't need it anymore. That's why it hasn't been updated since Nov.

It would be helpful to me if you could do some testing to try to determine what steps causes the problem. For example, does changing the AVR source or turning off the receiver cause the issue? What about connecting or disconnecting via remote desktop, or using/turning off the 4K monitor?

[Manni]

I very rarely change the AVR source, so we can rule this out, and as I said using the 4K monitor is 100% invisible to the HTPC. It has no way to know what it connected to the HD Fury Maestro, as the Maestro always sends the same EDID.

The most likely culprit is the remote desktop. I'll try to see if I get the issue when I boot directly on the HTPC without using the remote desktop, or If I get the issue if I try to use CMC after using the remote desktop.

I've noticed the the DPI in the DPI.txt is wrong though, it should be 200 and it's 168.

[Pauven]

I'm not sure that the DPI # itself matters here. That's a number I use internally in CMC, and it is influenced by other factors, and doesn't necessarily match the Windows value.

To me the bigger issue is not a DPI issue (scaling looks correct) but rather a cropping issue. I have some users on oddly sized screens (i.e. Microsoft Surface Tablet) and to make CMC display correctly I had to do black bars style cropping. It looks like this cropping feature is getting triggered on your setup, even though it shouldn't. So not exactly a scaling issue, but related as the code for both is in the same function.

[Manni]

I did some testing, and the issue seems to occur if I do the following:

- Connect to the HTPC using Remote Desktop
- Exit Remote Desktop
- Start CMC from the HTPC

Would there be a way to disable cropping?

[Pauven]

Thanks for testing, that's very helpful.

I checked my code, hoping I had simply moved the DPI.txt info into Debug logging, but it looks like I've completely disabled that code. I will re-enable it for debug logging in the next version, as I think I'll need some info from it.

Alternatively, you could try the same steps above to reproduce the issue with CMC v3.0 which still outputs the DPI.txt info (Debug logging not required). That would help me develop a solution faster.

I'm thinking that somehow the remote desktop connection is changing the screen size values provided to CMC, which is what the DPI txt file would reveal. I'd like to see the DPI.txt info when you are having a problem.

I'll have to think about ways to disable or possibly hard-set the scaling and screen position. A simple disable of the entire function would break a lot of things, we would just need to disable the position shift that is moving the main CMC window down.

One last thought - I sometimes see a similar problem on my development workstation with 3 4k monitors. CMC displays on the middle monitor, and if the screens go to sleep and then re-awaken, CMC is always shifted down and right (diagonally). I hadn't worried about this because this usage scenario seemed extremely rare for HTPC use, plus I have a lot of issues with windows shifting position after sleeping the displays, it's not just a CMC issue. Maybe this is related, or maybe not, hard to say.

[Pauven]

One last question: Are you 100% sure that your remote desktop resolution is the exact same 3840x2160? The way it is shifting down looks like what I would expect if you had a 16x10 monitor (i.e. 1920x1200 or 3840x2400, something like that). Because the CMC GUI is hardcoded at 16:9, I shift it down to center it when displayed on taller screens.

[Manni]

One last question: Are you 100% sure that your remote desktop resolution is the exact same 3840x2160? The way it is shifting down looks like what I would expect if you had a 16x10 monitor (i.e. 1920x1200 or 3840x2400, something like that). Because the CMC GUI is hardcoded at 16:9, I shift it down to center it when displayed on taller screens.

Yes, I'm 100% sure. When you mentioned scaling, I checked and tried both "large" and 3840x2160 exactly. It produces the same effect.

It couldn't be this anyway because I never have the issue when I use Remote Desktop to access the HTPC. It's only when I use the HTPC *after* after I've used remote desktop. The easiest way to reproduce it is to start CMC using remote desktop on my laptop (it looks fine on my 4K monitor), then log into the HTPC: here is the black bar at the top and the missing bottom part. You might want to try this, it would be easier to solve if you can reproduce it yourself.

Anyway, don't waste too much time about this if there is no easy solution. I thought it would be easy to disable whatever you're doing for the surface, or force a 16x9 ratio.

The workaround is easy enough: exit CMC, start again.

What's weird is that CMC is the only app that does this, so I don't think it's connected to your tri-monitor issue. Also there is no sleep involved.