I’m really hoping that someone can help me out here…
We’re running three side-by-side displays at 1920x1080 each, with Xibo configured to run at 5760x1080 via the display profile. The usual effect is that Xibo plays content stretching across the three displays. Today is a different story… I had some display issues this morning that caused one of the displays to go black for a little while. Once Windows could see all three displays in the correct order again, Xibo started scaling the regions to be larger than the canvas.
It appears that Xibo is stretching two-thirds of the region to fill the three displays…
Okay, so I did a full system restore back to a working image from April and the problem persists. The only thing that would be different now is the player downloaded new copies of all of the assets when I cleared out library folder.
@alex and @dan… What’s the chance that a change was introduced into the CMS module scripts that would cause this problem? I suspect that I may have had outdated dependencies in my library. If I were going to test this theory, which dependencies would I want to focus on?
The Player caches pre-scaled content for the screen size it’s run at. It seems likely that something caused it to resize, and it now has cached content at a different scale.
You need to firstly ensure the display settings profile is set correctly for the screen.
Once that’s definitely right, clear the CMS-side cache by editing the display, and then saving it making no changes.
Finally, stop the Player running and clear the Player local library directory.
Then start the player again. That will cause fresh content to be downloaded.
For whatever reason the slider for the DPI setting kept disappearing, but I eventually was able to get it to show up so I could change it. Indeed, Windows “recommended” default setting was 150%.
Do you guys think it would be worth running a system integrity check at startup that checks the HKEY_CURRENT_USER\Control Panel\Desktop\Win8DpiScaling registry key for a value of 1? Even if this was only reported in the logs it could be a useful diagnostic based on Windows propensity for setting the value to 150%.
