FrontView+ [for Windows]iMon replacement, NowPlaying 2nd Screen

[jjstecchino 8]

now, I increased the scaling to 200% and the UI is correctly positioned without changing X/Y. Position seem to change only if i change the position of display2 relative to display 1 in windows display settings

[jjstecchino 8]

It looks like the offset is independent to scaling, but the origin changes depending to the position of the secondary screen relative to the primary

[jjstecchino 8]

Glenn, with manual X/Y it is workable. what VS ver are u using? I may play with the code as I can test it right away. If I can fix it I'll post it for you to review or if you like we can play with this some more tomorrow. Now got to go to sleep that I have to work early tomorrow. Too bad we some 12h of time difference.

 

Thanks and it is fun

[GlennNZ 83]

Glenn, with manual X/Y it is workable. what VS ver are u using? I may play with the code as I can test it right away. If I can fix it I'll post it for you to review or if you like we can play with this some more tomorrow. Now got to go to sleep that I have to work early tomorrow. Too bad we some 12h of time difference.

 

Thanks and it is fun

Glad we are all having fun!

 

Setting.xml X/Y is probably going to be the easiest solution in these outlying cases ; I suspect.

 

X/Y offset of 2nd screen changes depending on the DPI setting of the first monitor. Eg

If scaling 200% the x/y doubles (which is wrong) (as your examples goes from -600 right, to -1200)

It appears that essentially to correctly position the screen the 100% scaling X/Y result is wanted.

 

It seems the screen.bounds.top/screens.bounds.left reports different - on my windows 8.1 it gives me the 100% scaled X/Y values on yours the altered by dpi values.

 

However - Now that I seem to get correct dpi from the new pinvoke it would be relatively easy to then divide the x/y by scaling/dpi of first monitor correcting the result - at least in your current layout usage. But what with three monitors? Or 1st/2nd screens reversed? Wouldn't be the first monitor dpi it would be the 1st/2nd combined? Etc. Doesn't seem that robust.

 

The other issue is the behavior seems different on Windows 7, changing again for 8, again for 8.1 and then 10, and changing finally for 10 Creators update. Maintaining compatibility across all these is going to be problematic.

 

Welcome to have a look - using VS 2015 I think (but all the files are there). I suspect I have to have a much deeper look at DPIAwareness / add/ tidy-up nativeHandlers and potentially look at rescaling everything depending on dpi. The PositionScreen defn is also important as repositions based on dpi results.

 

(Although updating production computer to Windows 10; so hopefully will be able to test better)

 

Glenn

Edited June 30, 2017 by GlennNZ

[jjstecchino 8]

Hello Glenn,

 

For when you wake up.......   (Whish I was in a timezone closer to yours!)

 

Setting X and Y manually seems to be a workable solution. I would be surprised if different windows versions would use a drastically different coordimate system as it would break every piece of software. Maybe there is a more universal api that could be used. I will try to look at that over the weekend.

 

With this version of frontview I am experiencing another issue: As I start a movie the screen does not change to the movie display (fanart and related). It remains on the main screen. The log shows an error:

[14:33:55.8729] Cache TV Hight Converter : <string>Returning new Height:  Mail Ceiling : 153</string>
[14:33:55.8780] FrontView PVR: : <string>nowPlaying.Filename is :  nowPlaying.IsPlaying = False isPlaying False isNewMedia:True</string>
[14:33:55.8830] YatseApp      : Error [ Object reference not set to an instance of an object. ] ( System.NullReferenceException )
Timer_Tick : 0 / 0
   at FrontView.Yatse2Window.Timer_Tick(Object sender, EventArgs e)
   at System.Windows.Threading.DispatcherTimer.FireTick(Object unused)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
[14:33:56.3499] FrontView+Api-EMBYAPI: : EMBY Server found - FrontView Checked
[14:33:56.3529] FrontView+Api-EMBYAPI: : EMBY -- CheckTimerTick: IsConnected:True connect:True
[14:33:56.8423] FrontView+Api-EMBYAPI: : --------------- PLAYER CONNECTION: IP 192.168.100.9:8096
[14:33:56.8453] FrontView+Api-EMBYAPI: : ------------------- Username Parent :WMS
[14:33:56.8483] FrontView+Api-EMBYAPI: : ------------------- CurrentUserID Parent :cb72e71050a8480aadd5f6e4eee98078
[14:33:56.8513] FrontView+Api-EMBYAPI: : ------------------- EMBY TOKEN EQUALS :48b28ec6fcea460ba26817d8763d7574
[14:33:57.8433] FrontView+Api-EMBYAPI: : --------------- PLAYER CONNECTION: IP 192.168.100.9:8096
[14:33:57.8563] FrontView+Api-EMBYAPI: : ------------------- Username Parent :WMS
[14:33:57.8693] FrontView+Api-EMBYAPI: : ------------------- CurrentUserID Parent :cb72e71050a8480aadd5f6e4eee98078
[14:33:57.8814] FrontView+Api-EMBYAPI: : ------------------- EMBY TOKEN EQUALS :48b28ec6fcea460ba26817d8763d7574

I am not 100% sure this error is related as I see also that isPlaying is set to false.

 

I am attaching the full log as well.

 

The remote control is working some. If I click on it it goes to the gray screen saying "Nothing" (the same grey screen you fixed a couple of days ago), if I click again it goes to the remote screen where I can control emby teather with play, stop etc. The buttons are working and controlling emby.

 

Going back to few version ago, this seems to have broken after 1.233 where you make changes for Kodi.

 

Today I will be in and out of the house. I will be glad helping troubleshooting whenever I am in.

 

Thank you very muck for all you are doing

 

FrontView+.log

[GlennNZ 83]

Hello Glenn,

 

For when you wake up....... (Whish I was in a timezone closer to yours!)

 

Setting X and Y manually seems to be a workable solution. I would be surprised if different windows versions would use a drastically different coordimate system as it would break every piece of software. Maybe there is a more universal api that could be used. I will try to look at that over the weekend.

 

With this version of frontview I am experiencing another issue: As I start a movie the screen does not change to the movie display (fanart and related). It remains on the main screen. The log shows an error:

[14:33:55.8729] Cache TV Hight Converter : <string>Returning new Height:  Mail Ceiling : 153</string>[14:33:55.8780] FrontView PVR: : <string>nowPlaying.Filename is :  nowPlaying.IsPlaying = False isPlaying False isNewMedia:True</string>[14:33:55.8830] YatseApp      : Error [ Object reference not set to an instance of an object. ] ( System.NullReferenceException )Timer_Tick : 0 / 0   at FrontView.Yatse2Window.Timer_Tick(Object sender, EventArgs e)   at System.Windows.Threading.DispatcherTimer.FireTick(Object unused)   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)[14:33:56.3499] FrontView+Api-EMBYAPI: : EMBY Server found - FrontView Checked[14:33:56.3529] FrontView+Api-EMBYAPI: : EMBY -- CheckTimerTick: IsConnected:True connect:True[14:33:56.8423] FrontView+Api-EMBYAPI: : --------------- PLAYER CONNECTION: IP 192.168.100.9:8096[14:33:56.8453] FrontView+Api-EMBYAPI: : ------------------- Username Parent :WMS[14:33:56.8483] FrontView+Api-EMBYAPI: : ------------------- CurrentUserID Parent :cb72e71050a8480aadd5f6e4eee98078[14:33:56.8513] FrontView+Api-EMBYAPI: : ------------------- EMBY TOKEN EQUALS :48b28ec6fcea460ba26817d8763d7574[14:33:57.8433] FrontView+Api-EMBYAPI: : --------------- PLAYER CONNECTION: IP 192.168.100.9:8096[14:33:57.8563] FrontView+Api-EMBYAPI: : ------------------- Username Parent :WMS[14:33:57.8693] FrontView+Api-EMBYAPI: : ------------------- CurrentUserID Parent :cb72e71050a8480aadd5f6e4eee98078[14:33:57.8814] FrontView+Api-EMBYAPI: : ------------------- EMBY TOKEN EQUALS :48b28ec6fcea460ba26817d8763d7574

I am not 100% sure this error is related as I see also that isPlaying is set to false.

 

I am attaching the full log as well.

 

The remote control is working some. If I click on it it goes to the gray screen saying "Nothing" (the same grey screen you fixed a couple of days ago), if I click again it goes to the remote screen where I can control emby teather with play, stop etc. The buttons are working and controlling emby.

 

Going back to few version ago, this seems to have broken after 1.233 where you make changes for Kodi.

 

Today I will be in and out of the house. I will be glad helping troubleshooting whenever I am in.

 

Thank you very muck for all you are doing

Morning, Thanks for the logs.

 

I think the issue is maybe the change to .net 4.6.2 in Frontview.exe. I can't replicate the error here and all are using the same. Hopefully it goes away with a full/proper install. That does look like the relevant error though - if you log again with trace on as well probably give a bit more info.

(Think that is a debug log without trace)

 

The dpi stuff is a minefield as a quick google shows. Having installed windows 10 now - the behavior is quite different to windows 8.1. Which scaled the Frontview screen up/making it blurry when dpi was above 100. On Windows 10 now (pat least before creators update) it doesn't - and does report the dpi. I notice that .net .4.6.2 has to have creators update installed to run - appears Emby theater is the same.

 

When you say remote - you mean the button up the top right? Will have a look at that as well as work on the dpi stuff - once windows installs...... and then downloads update and installs some more.....

 

Glenn

Edited June 30, 2017 by GlennNZ

[jjstecchino 8]

Good morning to you. I am back home.

 

Yes, the remote I mean is the one on the top right, and the buttons are the one on the black screen with the numeric keypad and media buttons. Those works. However as you click the remote the first time you are presented with a dark gray screen with a lighter insert in the middle with the word "Nothing". If you click the remote again you get to the black screen with the media buttons. I do not know if this is part of the problem with front view not displaying the movie details as a movie is played in embryo theater.

 

If you compile a new version with the new .net framework, I can test it.

[jjstecchino 8]

PS. never had an issue with blurring

But things changed definitely after 1.233.

[GlennNZ 83]

Good morning to you. I am back home.

 

Yes, the remote I mean is the one on the top right, and the buttons are the one on the black screen with the numeric keypad and media buttons. Those works. However as you click the remote the first time you are presented with a dark gray screen with a lighter insert in the middle with the word "Nothing". If you click the remote again you get to the black screen with the media buttons. I do not know if this is part of the problem with front view not displaying the movie details as a movie is played in embryo theater.

 

If you compile a new version with the new .net framework, I can test it.

Thanks

Uploading a test version now.

 

Have gone back to 4.6.0 for the moment. Otherwise will not run on Windows 10 without creators update installed (and that does cause issues with madVR so would like to avoid that if possible)

 

Can't find anything obvious regarding your two issues - but test this version and post debug/trace log. Trace debugs the remote connection better which is where the exception is coming from.

 

Glenn

[jjstecchino 8]

Test version has the same problem, but I see you fixed the swapped x/y

 

here is the log

FrontView+.log

[GlennNZ 83]

Test version has the same problem, but I see you fixed the swapped x/y

 

here is the log

Thanks

Can you do that again with debug and trace on?

 

and the remote issue?

 

Glenn

[jjstecchino 8]

debug and trace on

FrontView+.log

[GlennNZ 83]

debug and trace on

Thanks

That was a stupid mistake.

Fixed in this one.  But check.

 

Remote still an issue?

In what screen - NowPlaying or Home screen?

 

Glenn

FrontView.zip

[jjstecchino 8]

It was not going to NowPlaying anymore, thats was the main problem

[jjstecchino 8]

Sorry if I was not clear on that

[jjstecchino 8]

Now it is working

[jjstecchino 8]

One minor thing, as you stop the movie and nowPlaying reverts to the main UI, the "Nothing" screen appears for a moment and then goes away

[GlennNZ 83]

One minor thing, as you stop the movie and nowPlaying reverts to the main UI, the "Nothing" screen appears for a moment and then goes away

Probably not easily - the 'nothing' screen is infact the nowPlaying screen (just with nothing playing).

So it appears when playback remote info updated - but hasnt quite realised that playback stopped.

Hence the fraction of a second.  

Will have a look though.

If you disable panel animations - it goes away/you won't see it. They look good but not that useful in htpc playback overall.

 

Remote issues still ongoing?

 

Glenn

Edited July 1, 2017 by GlennNZ

[jjstecchino 8]

Don't worry too much. The "nothing" is really nothing.

 

Remote is working perfectly.

 

Glad to report I have a perfectly working setup. I am very grateful.

 

If you have anything you want me to test, please let me know.

 

Strangely the forum is not emailing me on new posts, Ill keep on checking though

 

Thank you very much

[GlennNZ 83]

Don't worry too much. The "nothing" is really nothing.

 

Remote is working perfectly.

 

Glad to report I have a perfectly working setup. I am very grateful.

 

If you have anything you want me to test, please let me know.

 

Strangely the forum is not emailing me on new posts, Ill keep on checking though

 

Thank you very much

 

Great to hear.

 

I'll try to make some dpi related changes - but will leave the X/Y for overriding any of these changes.

 

Glenn

Edited July 1, 2017 by GlennNZ

[jjstecchino 8]

Yes please leave the x/y override, if anything else fails they are always useful

[jjstecchino 8]

Hello Glenn, for when you wake up...

 

Installed VS2015 on my media center PC and found out a few things:

 

1) your installer still leaves override DPI settings in the exe compatibility. That needs to be removed

 

2) I noticed in frontview-properties-AssemblyInfo.cs you have [assembly: DisableDPIAwareness]. with that removed the front view UI scales and positions just right without having to define ScreenPositionX and Y. I tried with different scaling ratios and moving the position of the second screen, placing it in all different corners and works ok. 

 

3) in Yatse2Windows.cs line 2696 screens is already assigned to System.Windows.Forms.Screens.Allscreens, so it is redundant

 

I am running the Debug version as I have not been able to run a Release exe. If I switch the target to release, the generated frontview.exe displays the splash screen then hang, no exceptions, no icon in the tray, no ui screen, just a ghost process in task manager.

 

Is there any particular steps I have to do to compile a Release version? The Debug version is significantly slower.

 

Cheers

[jjstecchino 8]

Also if I understand correctly ChangeDisplaySettings is called upon init() and as a callback to a DisplaySettingChanged event whereas PositionScreen() is called upon every timer tick.

 

These methods have almost identical functionality and perhaps the common functionality pertaining calculating the scaling factor dx/dy and Top/Left should be in a separate method just to avoid setting the same things differently i.e ChangeDisplaySetting does not apply scaling (do not divide Top/Left by dy/dx, whereas PositionScreen does. Since PositionScreen is called every tick it wins and position the screen correctly, however on changing any display setting DisplaySettingChanged is called and the screen moves just to be redrawn shortly after by PositionScreen

[GlennNZ 83]

Hello Glenn, for when you wake up...

 

Installed VS2015 on my media center PC and found out a few things:

 

1) your installer still leaves override DPI settings in the exe compatibility. That needs to be removed

 

2) I noticed in frontview-properties-AssemblyInfo.cs you have [assembly: DisableDPIAwareness]. with that removed the front view UI scales and positions just right without having to define ScreenPositionX and Y. I tried with different scaling ratios and moving the position of the second screen, placing it in all different corners and works ok.

 

3) in Yatse2Windows.cs line 2696 screens is already assigned to System.Windows.Forms.Screens.Allscreens, so it is redundant

 

I am running the Debug version as I have not been able to run a Release exe. If I switch the target to release, the generated frontview.exe displays the splash screen then hang, no exceptions, no icon in the tray, no ui screen, just a ghost process in task manager.

 

Is there any particular steps I have to do to compile a Release version? The Debug version is significantly slower.

 

Cheers

Thanks.

 

1. Yes - hadn't noticed that.

 

Where to start!

 

https://msdn.microsoft.com/en-us/library/windows/desktop/ee308410(v=vs.85).aspx

 

https://blogs.windows.com/buildingapps/2017/04/04/high-dpi-scaling-improvements-desktop-applications-windows-10-creators-update/

 

 

2.

The [disableDPIawarness] has just been added. (Wasn't there before). Because apparently to make the application PerMonitorDPIaware - you need to disable it in assemblyinfo.cs and then enable it in the code. I have done this now via a pinvoke call and the logging confirms it now works. I suspect not having it there doesn't stop the pinvoke from working. (New log line reporting dpi status - before and after trying to change - 2nd/3rd line of log)

 

Unless this it is there the application seems to be marked systemDPI at best or notDPIaware and with this setting none of the get current get Dpis code work.

 

*This is the issue*

This has clearly changed because on Windows 8.1 we still could get current accurate Dpi results and calculate position based on that. (Regardless of app state). There are three ways to do this - the graphics, the m11/m12 composition, and the getmonitorDpi call. (They are now all in there returning the same wrong results) - obviously will only need one when sorted)

 

The issue is most of the time they all report 1, or 96dpi regardless of what the actual dpi is. Accurate dpi is needed to figure out screen position - hence your issue with 10 that wasn't on 8.1.

This is the change between windows 8.1 and 10.

 

On Windows 10 creators update - the DPIs all return 1 or 96. Unless the app is marked PerMonitorDPI aware. When it is - we get the correct dpi results and positioning then works. (Changing it to that though took a while)

 

That is what it is doing currently in the latest uploaded version - marking Frontview as permonitorDPI aware. What effect this will have on Windows 8.1 I'll have to test.

 

3. Yes - it is defined twice. But remove the 2nd one and see what happens! With screen refreshing/resolution change it didn't work without it - never quite go to the bottom of why/so there it says.

 

Now that I have (late yesterday) sorted out making the application as perMonitorDPI aware - think will be pretty straightforward for Windows 10 now. Question will be older versions compatibility and working around that.

 

Glenn

[jjstecchino 8]

Without [disableDPIawarness] WPF seems to be scaling the app automatically, respecting the per monitor settings in windows10 (not sure about 8.1). Are you recalculating the UI elements based on DPI?

 

 

If not I would let WPF handle the scaling and the remaining issue is positioning.

 

With [disapleDPIawareness] off the UI seems to position correctly but it is stretched * scale factor. I do not know if it this is due to running Debug as I have not be able to compile a release target. Can you give me some instructions on that? Changing target to release in the VS GUI does not cut it.

 

Screen.Bounds seems to be returning Top and Left coordinates multiplied by the largest scale factor, regardless of which monitor the scaling has been set on. So for example if the large scale factor is 200% front view Top and Left are multiplied by 2.

 

m11/m12 composition seems to be reliably returning the appropriate scale factor, dx seems to be always == dy (is there any case where dx != dy? can we use one of either one to set a var ScaleFactor?)

 

Dividing Top/Left by dx=dy=ScaleFactor seems to reliably returning the right Top/Left coordinates.