INTERACT FORUM

All it can do is act on the information Windows gives it. It gets the current mode from Windows and compares it to the configured mode. If Windows lies or rather is confused by 23/24 again, then there is little we can do about that.
But I'm adding some extra logging to tell us what Windows reports exactly.

Thanks, looking forward to testing a new build with the extra logging.

Well that's fun.  It would seem you have some bug fixing to do, Hendrick. 

Here's what I can say.  Desktop set to 23.976.  Set custom res in display settings in MC to 23.976.  Set the delay to 0.5.  It doesn't give me metadata.  Now here's the fun part that's going to drive Hendrick absolutely nuts.    Go set the delay to 1, play it again.  Metadata ensues like I'd expect.  BUT....if I THEN go set it back to 0.5 and play it again, it MIGHT sometimes have metadata.  LOL  The 1s delay always gives me metadata in every scenario I've tested.  But the idea that it's not doing anything with refresh rate when you have it set to custom and they match seems to be slightly untrue.  It may not be explicitly setting the refresh rate (or maybe it is and you don't see it because, well, they are the same) but it's definitely acting as though it's being set.

Thanks for testing and reporting. It still doesn't explain why the delay fixes it for you and doesn't do anything for me, but hopefully the additional logging will help Hendrik to figure out what's happening.

I'll try with native frame rates when I get a chance (desktop 23p and 23p/24p for 23p/24p), but you might want to try with 119p desktop and 119p/120p custom for 23p/24p, which is what I'm using. There might be a different behaviour if you try to reproduce what I'm actually using.

We should really try to reproduce the same parameters so that our configurations are as close as possible when testing this. It doesn't make sense that the delay works for you and doesn't work for me, we have the same OS, same GPU family, same driver, and it doesn't look like there is anything different in our nVidia or JRiver settings.

Assuming that MC is displaying your cover art (wherever it may be stored), select all the relevant tracks, then right click and select Library Tools > Update Tags (from library).

The Image tag listing in MC will then show the cover art as being "inside file".

Me too. I want to turn off the volume control on JRemote or at least keep it at 100% permanently.

Tune Talks you are about to enter the "Cranky World of the Apple OS" because, unless you have an ap that can uninstall/remove other aps, the only way to remove MC32 is to "Send it to the Bin" and then once you are satisfied nothing adverse has happened emptying the bin to get back the disk space MC32 was previously occupying.

But the idea that it's not doing anything with refresh rate when you have it set to custom and they match seems to be slightly untrue.  It may not be explicitly setting the refresh rate (or maybe it is and you don't see it because, well, they are the same) but it's definitely acting as though it's being set.

All it can do is act on the information Windows gives it. It gets the current mode from Windows and compares it to the configured mode. If Windows lies or rather is confused by 23/24 again, then there is little we can do about that.
But I'm adding some extra logging to tell us what Windows reports exactly.

Well that's fun.  It would seem you have some bug fixing to do, Hendrick. 

Here's what I can say.  Desktop set to 23.976.  Set custom res in display settings in MC to 23.976.  Set the delay to 0.5.  It doesn't give me metadata.  Now here's the fun part that's going to drive Hendrick absolutely nuts.    Go set the delay to 1, play it again.  Metadata ensues like I'd expect.  BUT....if I THEN go set it back to 0.5 and play it again, it MIGHT sometimes have metadata.  LOL  The 1s delay always gives me metadata in every scenario I've tested.  But the idea that it's not doing anything with refresh rate when you have it set to custom and they match seems to be slightly untrue.  It may not be explicitly setting the refresh rate (or maybe it is and you don't see it because, well, they are the same) but it's definitely acting as though it's being set.

I'm watching a movie at the moment as my long weekend is coming to a close.  However, if I get a minute before I go to bed after the movie is done I'll run a quick test and let you know.  Personally at this point I'm keeping the desktop at 120 and with the delay set to 1s everything just works.  But I'll set it to 23.976 as a test and set the delay back to 0.5.  I seriously doubt this will make any difference and I expect it'll just work but we'll know for sure later.

I don't have any more time for testing tonight.  But up until I changed that setting I had this issue and it was most definitely reproduceable.  But then I've always had the option to change refresh rate enabled since I stopped using madvr.  (And even when I switch back to madvr for, e.g. hdr testing to see how much they've improved it, I keep jriver's refresh rate changing active).  It's entirely possible I didn't have this issue when the refresh rates matched but who realistically keeps their desktop at 23.976, as an example?  It was always set to 60 on the desktop.  So I'm guessing that's why I always saw this problem.  When they match, I doubt the delay makes any difference whatsoever since it's not used but I can't confirm if that was true for me in the past at this point as, like I said, I never had the desktop at 23.976 so refresh rate changing would always happen.

I did keep my destop to 23p to limit the number of refresh rate changes, but of course I prefer to have it at 119p as it is now

I'm not saying that you didn't have the issue when the frame rate match, just that it's a good way to test if the delay actually makes a difference or not.

I think it would be interesting to see if you can get the issue back, because for me the delay makes zero difference, and it looks like it shouldn't make a difference either in your case if the issue doesn't come back when there is no refresh rate change, as Hendrik has explained that the delay was ignored when there was no refresh rate change.

I don't have any more time for testing tonight.  But up until I changed that setting I had this issue and it was most definitely reproduceable.  But then I've always had the option to change refresh rate enabled since I stopped using madvr.  (And even when I switch back to madvr for, e.g. hdr testing to see how much they've improved it, I keep jriver's refresh rate changing active).  It's entirely possible I didn't have this issue when the refresh rates matched but who realistically keeps their desktop at 23.976, as an example?  It was always set to 60 on the desktop.  So I'm guessing that's why I always saw this problem.  When they match, I doubt the delay makes any difference whatsoever since it's not used but I can't confirm if that was true for me in the past at this point as, like I said, I never had the desktop at 23.976 so refresh rate changing would always happen.