Windows app regression: unwanted refresh rate changes

[65535 4]

v2.219.2.0 has a bug where it changes my refresh rate despite everything being disabled:


Happens with SDR, HDR, 1080p, 2160p. It's changing to 24 hz, and I did try flicking the option on and off.

 

EDIT:
I don't know that the regression happened exactly on v2.219.2.0. Could've been earlier.
Also it might have to do with this change :

On 2/26/2025 at 4:10 PM, Emby Releases said:

[Xbox] Limit refreshrate to 60Hz max

I know it says [Xbox] but you can see there are no refresh rates listed higher than 60 hz in the screenshot above.

logs.7z

Edited February 28 by 65535

[65535 4]

I tested starting off from other refresh rates (set in Windows) and found that:

60, 75, 100, 120 = no switch, behaves as expected

144 = switches to 24 hz

But this is definitely a regression as it was not doing that a month ago.

Edited February 28 by 65535

[Thorman 2]

I can confirm same issue here. I have tried manually setting my refresh rate to 144, 120, 60, and 30. All of them cause refresh rate changes on my monitor when the source file is not one of the listed refresh rates, even when auto refresh rate is disabled. it doesn't happen on the old emby theater and it doesn't happen on the web player.

[softworkz 4492]

The observations are correct. The app hasn't been made for and been tested with excessive refresh rates and hence it ensures that it is operating with a reasonable refresh rate.

@65535 What you describe is intended behavior. The maximum rate might even be reduced in the future.

@ThormanThis is not how it's meant to be. It should be a one-time reduction only  and only if it's above 120 Hz

 

[Thorman 2]

41 minutes ago, softworkz said:

@ThormanThis is not how it's meant to be. It should be a one-time reduction only  and only if it's above 120 Hz

Upon further testing when the source file is 24fps the video plays fine without a refresh rate change. When the file is 60 fps I get a black screen for a second, and the message "refresh rate set to 60 Hz". When exiting the video I get a message that says "refresh rate set to 143.85 Hz". Neither of these 2 things happen on a 24 fps file and this also didn't happen until a recent update. I have attached photos of my settings and the messages when playing and stopping the 60 fps videos.

[kron0s 19]

This happens to me as well.  Usually I am set to 144hz but when I play a video it switches to 24hz even though the option to enable auto refresh rate switching is disabled. 

 

Edited March 5 by kron0s

[Boulvejak 0]

Confirmed this is still an issue.  It's making the app basically unusable on a general-purpose PC.  I'm having to manually reset my refresh rate every time I play media even with this setting disabled.

[frankmb 34]

I agree that any permanent change in refresh rate that the Emby Windows app makes and that remains after the app is closed is a big problem.

Is it possible for Emby to only make "temporary" changes in refresh rate? Video Games do this all the time, right?  

[kron0s 19]

When can this get fixed? @softworkzauto frame rate changing even when disabled is a big issue. 

[softworkz 4492]

I'd like to become clear of which kind of situation you're facing. Following question:

If your refresh rate is set to 120 Hz or lower, and you start the Emby app (with auto-switching disabled) and play a video - does any refresh rate switching happen?

[Thorman 2]

Yes the issue goes away when setting it to 120 Hz. 

Edited March 11 by Thorman
Set refresh rate on wrong monitor

[softworkz 4492]

The behavior is changed in the latest beta (and will get into public release soon). Now it:

• Only changes to the highest available refresh rate <= 120 Hz, regardless of the video being played
• It does no longer try to revert it on playback stop

Generally, I wouldn't recommand high rates for video playback (above 60 Hz), especially when experiencing performance issues or excessive GPU usage in high quality playback modes.

Thanks for reporting!

[65535 4]

11 hours ago, softworkz said:

Only changes to the highest available refresh rate <= 120 Hz, regardless of the video being played

This would be an improvement but:

11 hours ago, softworkz said:

It does no longer try to revert it on playback stop

I was hoping this was a typo or something, but it actually does leaves me at 120 hz regardless of the revert setting. Am I expected to change it back to 144 manually every time after using Emby? This is not a good experience.
 

On 3/4/2025 at 1:13 AM, softworkz said:

The app hasn't been made for and been tested with excessive refresh rates and hence it ensures that it is operating with a reasonable refresh rate.

@65535 What you describe is intended behavior. The maximum rate might even be reduced in the future.

Lowering to 120 hz temporarily is acceptable (if disruptive still), but reducing the limit further to 60 would be entirely unreasonable. 144 hz monitors were new 12 years ago.

Honestly though I've never encountered a PC media player that requires changing the refresh rate for it to function. I don't think it's unreasonable to not want my screen to go black for several seconds every time I click on a video. Imagine if MPV or YouTube did that. Is this frustrating workaround really worth it? For what it's worth I see the same low 3D utilization and a 20% "Copy 1" utilization at 144, 120, and 60 in the high quality preset, and that's what I've been using at 144 before the update prevented it.

[kron0s 19]

15 hours ago, softworkz said:

The behavior is changed in the latest beta (and will get into public release soon). Now it:

• Only changes to the highest available refresh rate <= 120 Hz, regardless of the video being played
• It does no longer try to revert it on playback stop

Generally, I wouldn't recommand high rates for video playback (above 60 Hz), especially when experiencing performance issues or excessive GPU usage in high quality playback modes.

Thanks for reporting!

Is the option to disable frame rate switching fixed?  Currently I have no way to disable it as it switches my 144hz to 24 hz every time I play a video and I don't want this.  Also where can I download the beta to test? 

Edited March 15 by kron0s

[Wizred1 0]

6 hours ago, kron0s said:

Is the option to disable frame rate switching fixed?  Currently I have no way to disable it as it switches my 144hz to 24 hz every time I play a video and I don't want this.  Also where can I download the beta to test? 

i too would like to know where i can access the beta as this is making the app nearly unusable

[parkesto84 2]

Having the same issue as the above users, posting here so I can follow the thread.

This has to be fixed, it reverting my 165hz panel to 23.96hz is a huge pain in the ass, it never did this before so I'm not sure why this was even added/changed. Never had any playback issues prior to this.

 

On 3/3/2025 at 6:13 PM, softworkz said:

The observations are correct. The app hasn't been made for and been tested with excessive refresh rates and hence it ensures that it is operating with a reasonable refresh rate.

@65535 What you describe is intended behavior. The maximum rate might even be reduced in the future.

@ThormanThis is not how it's meant to be. It should be a one-time reduction only  and only if it's above 120 Hz

 

I think everyone's question though is "why"? If I go change my refresh rate back to 165hz while the title is playing there are literally 0 issues so I'm not sure why Emby is switching my refresh rate even when this "feature" is disabled.

It's super intrusive and a massive annoyance to reset.

Edited March 18 by parkesto84

[softworkz 4492]

On 3/15/2025 at 1:39 PM, 65535 said:

I was hoping this was a typo or something, but it actually does leaves me at 120 hz regardless of the revert setting. Am I expected to change it back to 144 manually every time after using Emby? This is not a good experience.

The immediate intention is to have some clean and simple behavior.

The problem about reverting on app exit is this: Many users are leaving the Emby app open while doing other things, maybe even for days. A refresh rate change right before playing a video is has a clear and relatable cause and effect. But a refresh rate change on app close is totally unexpected and surely much more undesired for many than not doing it.

 

On 3/15/2025 at 1:39 PM, 65535 said:

Lowering to 120 hz temporarily is acceptable (if disruptive still), but reducing the limit further to 60 would be entirely unreasonable.

A reduction to 60 is not on the table at the moment and would only be an option in case of frequent issue reports which are caused by high refresh rates.

On 3/15/2025 at 1:39 PM, 65535 said:

144 hz monitors were new 12 years ago.

Yes that's true, but it's a matter of the overall bandwidth to which the refresh rate is just one factor. Others are bit depth,  screen resolution and chroma subsampling. An additional point of congestion is the HDMI standard. Even though I don't have outdated hardware, I can't even have a 4k@60Hz connection to the TV with HDR (it would be no problem with DisplayPort though). But that's just a side note. What matters is GPU processing.

Could you compare the GPU load between 60Hz and 144 Hz under the following conditions:

• Emby App is set to the "High Quality" preset for video playback
• Display resolution 4k
• HDR mode enabled for the display

That would be very interesting. Unfortunately, my Eizos are for graphic design and not for gaming, which means there's a fixed rate of 60Hz (and the TV connectoin doesn't got beyond 60 either).

Thanks

[Thorman 2]

3 hours ago, softworkz said:

Yes that's true, but it's a matter of the overall bandwidth to which the refresh rate is just one factor. Others are bit depth,  screen resolution and chroma subsampling. An additional point of congestion is the HDMI standard. Even though I don't have outdated hardware, I can't even have a 4k@60Hz connection to the TV with HDR (it would be no problem with DisplayPort though). But that's just a side note. What matters is GPU processing.

Could you compare the GPU load between 60Hz and 144 Hz under the following conditions:

• Emby App is set to the "High Quality" preset for video playback
• Display resolution 4k
• HDR mode enabled for the display

What does any of this have to do with the fact that I paid extra for a 144 Hz monitor that me simply playing an emby video causes it to revert the refresh rate every time I watch a video? And the beta update is even worse with my 144 Hz monitor becoming a 120 Hz unless manually reset! WHY?!?!? All I want is for you guys to revert the update that caused this issue. I don't care that it uses more processing, but I definitely care that you guys altered my refresh rate even with disabling that setting! Can you please explain the reasoning here because I truly don't understand why you made this change? Like @65535 and @parkesto84 said

 

On 3/15/2025 at 7:39 AM, 65535 said:

Honestly though I've never encountered a PC media player that requires changing the refresh rate for it to function. I don't think it's unreasonable to not want my screen to go black for several seconds every time I click on a video. Imagine if MPV or YouTube did that. Is this frustrating workaround really worth it?

7 hours ago, parkesto84 said:

I think everyone's question though is "why"? If I go change my refresh rate back to 165hz while the title is playing there are literally 0 issues so I'm not sure why Emby is switching my refresh rate even when this "feature" is disabled.

It's super intrusive and a massive annoyance to reset.

 

Edited March 19 by Thorman

[65535 4]

@softworkzThank you for listening to feedback.

 

If you absolutely must, then reverting on playback stop seems the most sensible, but this is still far from ideal. I think you should just revert this change that from my perspective seems poorly thought out and unjustified. If there are underlying technical issues, addressing the root cause directly would be the correct solution, rather than forcing a disruptive and unusual workaround on everyone. I'll gladly help with testing on my 144 hz; perhaps someone else can help out with a more "unreasonably excessive" refresh rate if necessary.

 

Here are my results:

3840x2160 @ 144 hz, 10 bpc, RGB (aka 4:4:4, no subsampling), HDR enabled, high quality playback preset. This is over HDMI 2.1. Playing a 61.4 Mb/s bitrate 4k HDR remux.

At 144 hz:

At 60 hz:

Edited March 19 by 65535

[frankmb 34]

Even assuming that a user should know how to manually change their display refresh rate after the Emby app is closed is unacceptable. Most people posting in this forum probably know how to do this but the average user of the Emby Windows App should absolutely not be expected to know how to fix this problem.

[softworkz 4492]

3 hours ago, frankmb said:

Even assuming that a user should know how to manually change their display refresh rate after the Emby app is closed is unacceptable.

Someone who doesn't know about this, also doesn't care whether it's 120 or 144.

[softworkz 4492]

8 hours ago, 65535 said:

f you absolutely must, then reverting on playback stop seems the most sensible, but this is still far from ideal. I think you should just revert this change that from my perspective seems poorly thought out and unjustified. If there are underlying technical issues, addressing the root cause directly would be the correct solution, rather than forcing a disruptive and unusual workaround on everyone.

It was done in the light of seeing Xboxes crashing on refresh rates above 60 Hz. We don't have telemetry in our stable app releases, but MS Partner center prrovides some very basic figures, one of them being app crashes. There has been quite a high rate of app crashes on Xbox in the context of video playback. There's also a number of crashes on Windows, but for that app model (WinAppSDK vs. UWP on Xbox) you get even less information and it's not clear where those are coming from.
For the Xbox it was clear though, and that's why the 60 Hz limit was introduced. For Windows it was initially set to 100 but then increased to 120.

I really know how annoying such behaviors can be for users, espcially for knowledgeable ones. But it's also true that this is always just a very small margin. The vast majority of of users (be it 95 or 99%) won't ever even notice when their rate is getting switched down once from 144 to 120, neither do they care. 
But what they do care about is when an app is crashing. Even I don't have a lot of patience in this regard: when I try an application and it is crashing, I drop it and I rarely ever give it second chance. On top of that, I'll tell everbody not to use it because I've seen it crashing. And like most others, I walk away silently, without notice.

Only two users reports came in about the the Xbox crashes, but the figures from the store were in a totally different range. When you don't know what's going on exactly, you have not other chance than making a defensive decision for the moment, because - I'll say it like it is: annoying a small number of enthusiasts is a much smaller evil than dozens or hundreds of "silent walkaways" from users seeing the app crashing (especially when new they're new to Emby). 

This is in no way meant to disregard your feedback on the subject. But you also need to see that the app is still brand-new, released just 3.5 months ago. The immediate measure has been defensive to be on the safe side, while looking into it further. 

For the moment, the situation is that when you leave your Windows desktop at 120Hz or less, it's all fine. If you insist that it's gotta be 144, then I acknowledge that it's troublesome. In no way though does it mean that it has to stay like this for all times.

 

9 hours ago, 65535 said:

If you absolutely must, then reverting on playback stop seems the most sensible, but this is still far from ideal

I do not want to do that, because this is enforcing rate switching happening all the time and that's really too intrusive, totally different from a one-time switch to 120.

But what we could do as a quick measure is to make sure that when you actually enable the rate switching feature, you will be safely switched back to 144 on stop. 

I'm running out of time, but I'll respond to the performance aspect in shortly. 

Thanks

[65535 4]

17 hours ago, softworkz said:

The immediate measure has been defensive to be on the safe side, while looking into it further. 

17 hours ago, softworkz said:

[...] I acknowledge that it's troublesome. In no way though does it mean that it has to stay like this for all times.

Thank you for that. You should have communicated that sooner. Your earlier responses come off as dismissive and doubling down. I'm glad we're on the same page now though. I appreciate the position you're in. Crashes are a serious roadblock to retaining users.

I have two proposals on what to do next with regards to this issue:

1. Beta telemetry and testing:

You implied that the beta releases have enhanced telemetry. Consider disabling the behavior only in the beta and let people in this thread partake. This could give you valuable telemetry data from high refresh rate users while simultaneously addressing our primary concern. Seems like a win-win. If there will be crashes as a result of this, it will be the kind of user that knew what he was getting into and can come back here and report it.

2. Customizable refresh rate switching:

Expanding on this:

17 hours ago, softworkz said:

what we could do as a quick measure is to make sure that when you actually enable the rate switching feature, you will be safely switched back to 144 on stop.

Under Display Control, you could let us customize which of the supported refresh rates will be considered for automatic switching. It should default to the highest enabled rate when none of them divide evenly. With that, one could uncheck everything except 120 hz and have it revert to 144 hz on playback stop, and without being forced into lower refresh rates.

This feature would be valuable beyond just addressing the current issue. A display may report a rate as "supported" but in practice have all kinds of issues that make it unusable. On my Samsung TV, for example, very low refresh rates like 24 hz add a ton of latency (fail lipsync) and force a switch to a different color calibration profile. On other displays I've experienced flickering and visual noise at low rates. So if someone has a display that "supports" both 24 and 48 hz (or 72), but 24 hz is broken, they can disable just that refresh rate and still enjoy perfect frame pacing at 48 hz. Without this option, they'd have to give up on automatic switching as a whole.

[frankmb 34]

I looked quickly at how Kodi handles the refresh rate switching. By default the Adjust Display Refresh Rate is off.

If the Adjust Display Refresh Rate is option is active, then refresh rate changes are made on playback start/stop or on start only depending on the setting.

Then when the Kodi program is closed, the refresh rate is reverted to what it was when the program started.

I think this last part is very important. My major issue with the Emby Windows app was that it was always setting my refresh rate to 24 to play video and then leaving it like that after I closed Emby.  

https://kodi.wiki/view/Settings/Player/Videos#Adjust_display_refresh_rate

[softworkz 4492]

7 hours ago, 65535 said:

1. Beta telemetry and testing:

You implied that the beta releases have enhanced telemetry. Consider disabling the behavior only in the beta and let people in this thread partake. 

I think the Windows/Xbox app was the first time that we even had some kind of telemetry, but it wasn't anything custom either, we just had used https://appcenter.ms/ with default configuration and it's just sligtly more than what you get from the MS Store. It has the same shortcoming that it is focused on UWP apps. Anyway, AppCenter is shutting down and we have completely removed it from the betas.

In terms of transparency - for anybody who might find this topic by searching for the word "telemetry", this is the kind of information we get from it:

{
  "length": 0,
  "offset": 0,
  "id": "72afc314-b8e9-4170-bf03-7b39777d4ac5",
  "exception": {
    "type": "System.Net.Sockets.SocketException",
    "message": "A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.",
    "stackTrace": "   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken)\r\n   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource.GetResult(Int16 token)\r\n   at System.Net.Sockets.Socket.<ConnectAsync>g__WaitForConnectWithCancellation|277_0(AwaitableSocketAsyncEventArgs saea, ValueTask connectTask, CancellationToken cancellationToken)\r\n   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()"
  },
  "properties": {
    "sender": "",
    "senderType": ""
  },
  "appId": "7f1477aa-dede-4356-bc56-ace8dc4aa571",
  "installId": "e1073994-e55c-4405-a612-144f65c207ed",
  "isTestMessage": false,
  "timestamp": "2025-03-18T03:25:22.6296895Z",
  "sid": "c2a6a322-0c79-4e91-8801-dead4c853971",
  "device": {
    "sdkName": "appcenter.winui",
    "sdkVersion": "5.0.6",
    "model": "Vostro 3710",
    "oemName": "Dell Inc.",
    "osName": "WINDOWS",
    "osVersion": "10.0.26100",
    "osBuild": "10.0.26100.3476",
    "locale": "en-AU",
    "timeZoneOffset": 480,
    "screenSize": "1920x1080",
    "appVersion": "2.209.0.0-BETA+b29e8e74315e0e87610a968052b6e0cfc0a96fe3",
    "appBuild": "2.209.0.0",
    "appNamespace": "Emby.Client.WinUI"
  }
}

 

As you can see, it is not much. Often people assume that there's a lot of information included, even more than logs are showing, but the opposite is true (at least in this case): The logs are including much more information and are much more valuable than this. Due to the async programming models in modern apps the stack traces are of little value either because they do not span across async invocations, to it's rately possible to even see where the invocations are coming from (from where in our own code).

In turn, I just rarely used it to see whether there are any big-figure issues and then trying to guess where it might come from.

7 hours ago, 65535 said:

This could give you valuable telemetry data from high refresh rate users while simultaneously addressing our primary concern. Seems like a win-win. If there will be crashes as a result of this, it will be the kind of user that knew what he was getting into and can come back here and report it.

So, no - this doesn't give any information about refresh rates or anything else than exceptions like above. Also there is no way to correlate those messages to a specific user and we have no intentions to ever do that. Due to the shutdown of AppCenter it's already removed anyway.

What I'm hoping for instead is an opportunity to borrow a gaming monitor for a few days from somebody to do some testing and analysis. There are two areas actually:

• High Refreh Rates
  and
• Dynamic Refresh Rates
  This is no longer limited to games. Meanwhile there are also some Windows desktop features making use of this, like for boosting the refresh rates during animations or other kind of situations where a higher rate might be advantageous (while the base rate remains low)

The second part is also intesting in the following way: The dynamic boost of refresh rate on-demand is a complex feature. Why do they spend so much effort on this? Why not have everybody use 144 Hz permanently instead? Clearly because there are drawbacks in doing the latter, and that's why it's important to analyze and understand in which ways it affects our app.Depend on these results we'll figure out the best approach to handle it in the future. 
I can't predict the results. Maybe it turns out to be safe for all hardware setups, then we can remove the limit altogether - but that's just one possible outcome we'll have to see, but the goal is to make everybody happy in the end.

 

Edited March 20 by softworkz
split long post into two