INTERACT FORUM

Like I said above, I can't reproduce that at all. I have a HDfury Arcana, which doesn't add a OSD ontop of the video, but rather has its own tiny screen with the metadata, and it reports accurate values in all scenarios (although I have to manually refresh the data display using its button, which brings me the next part). Are you certain it refreshes properly in all scenarios? One thing that happens is that there is several mode changes in quick succession here - even more if you use refresh rate changing. First it sets the refresh rate, then it enables HDR, and then it sends the metadata. There is no method in Windows to set all the changes in one go, you can only set them step by step.

Ultimately, all we do is give the data to Windows. It is responsible for sending it out.

The more important question - if you play a high nits video, can you actually observe the TV still acting undesireable?

Any HD Fury will report this correctly (I have almost all of them including the Arcana as I'm a beta tester for HD Fury), whether on the actual device as on the Arcana or on the device OSD as in my screenshots. I'll double check that the VRROOM itself displays the correct info, in case it's a bug in the VRROOM, but I doubt it as SamuriHL experiences the same issue as I do. I'm 100% certain that it refreshes properly, I refresh it every time manually.

It might be caused by the refresh rate change. I use the JRiver refresh rate change due to some issues with the madVR one that we've already discussed.

Please could you use custom refresh rate to display 23.976 at 119 and 24.00 at 120 and test again? I'm quite sure that this happens also when switching to the native refresh rate, but I haven't checked that. I'll check along with the VRROOM metadata info and I'll confirm.

It's hard to say if this can cause issues on the content, as it all depends on what the display does when a title gives it empty HDR metadata. Depending on the actual metadata and the actual content, I can imagine situations where this would be worse. For example, if you have content with maxCLL up to 10,000nits (Mad Max Fury Road or S&M Demo material) but send empty metadata, the display my tonemap whatever it gets as if it was 4,000nits, which could darken the picture if JRVR has already tonemapped it to 1,000nits. I haven't done tests because I only managed to get HDR to HDR to work properly yesterday evening and I wanted to report these issues ASAP. Hopefully others will confirm they experience the same issue. AFAIK SamuriHL also has a VRROOM, so I'll double check that first. If the VRROOM reports the wrong info in the OSD (Which I believe I'd have noticed earlier unless it's very specific to this situation), I'll hook up the Arcana to confirm if I get the same results as you do or not.

Of course if it's a VRROOM bug then there is no impact on the content

I'm on windows 11 Pro x64, latest build, with the nVidia drivers I mentioned in post#1, in case that's another possible difference. I noticed the absence of HDR metadata when using JRVR HDR passthrough with all the drivers I've used, whether using HDR to HDR tonemapping or not.

Awesome, appreciate the follow-up, Thanks!

Just one minor note: restoring the settings of MC28 caused the program to crash again. So for anyone in the same situation, don't restore settings, only media.

When MC32 finds out that it's running for the first time on a machine that had a previous version of MC on it, it pulls in the old data and settings into MC32 and updates the settings to the current version. That explains why the failure dump was so short. It doesn't explain what the problem is. We could use some more info. The process hasn't failed in any of our testing and we haven't had any other user report of this.

Are you saying that you had MC32 running after your trick which prevented it from updating on the fly, THEN you restored the MC28 settings to MC28 and it crashed? Or did you restore the MC28 settings to MC32 and that crashed it??

Thanks for the report.

Like I said above, I can't reproduce that at all. I have a HDfury Arcana, which doesn't add a OSD ontop of the video, but rather has its own tiny screen with the metadata, and it reports accurate values in all scenarios (although I have to manually refresh the data display using its button, which brings me to the next part). Are you certain it refreshes properly in all scenarios? One thing that happens is that there is several mode changes in quick succession here - even more if you use refresh rate changing. First it sets the refresh rate, then it enables HDR, and then it sends the metadata. There is no method in Windows to set all the changes in one go, you can only set them step by step.

If the VRROOM has a button to swap data display pages or refresh the data, maybe worth cycling it to see if its just not showing the latest, like my Arcana does?
I imagine there might be similar software on these devices, just with different connectivity exposed and other features hooked up.

Ultimately, all we do is give the data to Windows. It is responsible for sending it out.

The more important question - if you play a high nits video, can you actually observe the TV still acting undesireable?

Not seeing it either in Ubuntu 24.04 LTS.

@Hendrik

I've added screenshots of my settings and of the VRROOM OSD in the first post to help debugging the need to enable OS HDR here in order to get the correct HDR metadata sent to the display. I should have used a non-1,000nits title, or changed my target peak in HDR to HDR to something else than 1,000nits to make this clearer to the non initiated, but as you'll see it doesn't change the fact that the correct HDR metadata is only sent by JRVR (not only here, @SamiruHL has the same issue, he might post later to confirm) if the OS HDR is enabled manually BEFORE starting playback.

I hope this will help you to reproduce the issue.

What Distro are you running?  I'm not seeing this issue with Gnome 46 on Arch Linux (I'm on 46.2 of both gnome-shell and mutter if that's helpful).  Do you see it on any other windows?

Even with authentication, changing playlists on any client connected to the server is likely to cause problems. I think I have some pages bookmarked regarding this issue but am not at my PC just now. IIRC, the "playlist id" gets messed up when the client syncs back to the server which causes much weirdness...

I have actually tested this just now with my HDfury to observe the metadata, starting from a SDR desktop, with HDR to HDR tonemapping setup to 270 nits just to have a unique value, and after playback start and letting the values refresh, the HDMI metadata reads 270 nits as expected.

I can confirm that with a lower target peak (I tried with 260nits on my laptop) I can reproduce the above, so there is no issue with HDR10+ processing in JRVR. I've updated the title and the first post to reflect this. I had to restart the ripping of one of my DV titles to mkv, so I'll post more about this later. About to test HDR metadata with the HTPC, will post screenshots soon.

Thanks for your reply and the information.