INTERACT FORUM

Here's the thread... https://yabb.jriver.com/interact/index.php/topic,105230.0.html

The links referenced in there should also be read.

@AudibleImagery, does any of that feel familiar?
If you do your editing on the actual MC server rather than JRemote, are you still losing work?

I have actually been observing this no matter how I start playback or if I even play HDR at all. But it hasn't been causing any apparent playback issues as far as I can tell. It used to be perfectly stable, I wonder if something in the driver or Windows changed.
I'm working on a new presentation mode that may impact this, we will see.

Thanks, it's must have been a coincidence then. I agree that I haven't seen any detrimental impact of this weird fluctuation on playback, as reported earlier.

One suggestion, it would be great if you could provide in the JRVR OSD the peak target when doing HDR to HDR tonemapping, so that we can see the difference with HDR passthrough, as currently I don't think there is any. The original peak is reported for the input as HDR 10 peak, but there is no information reported the tonemapped peak. Maybe report "HDR to HDR (peak)" instead of "HDR Passthrough" when HDR to HDR tonemapping is enabled? Because technically, it's not passthrough if you tonemapped HDR to HDR, that's one of the reasons (along with the empty HDR metadata) why I thought HDR to HDR wasn't working.

I can't see any difference in the OSD at the moment that would help clarify the active mode (HDR passthrough vs HDR to HDR) at a glance.

Reporting the 3D LUT on the OSD (if active) as already discussed would also be helpful, but I'm aware that you don't have much room available in the OSD in SDR.

One thing I forgot to mention in the first post that might help explain the difference some of us experience between manually enabling OS HDR before playback and leaving it disabled, and possibly the dropped frames issue in HDR passthrough:

- When OS HDR is disabled before playback, if you look at the vSync info in the JRVR OSD it jumps all over the place. I don't think it reflects the actual vsync rate, as there is no more or less frames dropped or repeated, but it moves up and down like crazy. This never happens with madVR.

- When OS HDR is enabled before playback, the vSync info in the OSD is rock steady, as it should be: 119.880hz when playing 23p content at 119p.

Can you reproduce this behaviour, and does it help to understand what might be wrong for some users and not others? Could it be different depending on the processing/rendering path/hardware acceleration options etc?

I have actually been observing this no matter how I start playback or if I even play HDR at all. But it hasn't been causing any apparent playback issues as far as I can tell. It used to be perfectly stable, I wonder if something in the driver or Windows changed.
I'm working on a new presentation mode that may impact this, we will see.

Along with MC32.exe AVG Internet Security also gets suspicious of JRService.exe, JRWeb.exe and JRWorker.exe. To get around AVG's dislike of MC32.exe I suspend it for 10 minutes while I install a new version of MC32 and start it running. Although it also gets suspicious of the 3 JRxxxx.exe files AVG's inbuilt analysis routines cut in when 1 of them is activated and in less than 30 secs declares them safe; it also submits the relevant.exe and it's findings to AVG Labs. The same happens for both MC32.exe and the 3 JRxxxx.exe files the next 2 times I open MC32 as either client or server. One thing I have noticed though is for the last 5 updates AVG has not been suspicious of JRService.exe.

I'm guessing that AVG Internet Security on the Mac works in a very different way because it has never found anything wrong when downloading, installing or running MC32 on the Mac Mini.

There is no video filename rule but there is a audio file name rule when synching to handheld.  This makes it impossible to create the file name in a standard naming convention ex.  ([name] - [artist] - [album]

I have tons of individual music concerts files (not DVDS) that were ripped and I've added the name of the song to JRiver but not as the file name.  I would like to be able to send JRiver video files to a flash drive or Music player with the Name variable (JRiver Metadata) as the file name ([name] - [artist] - [album].

It would make sense to add this in for Images and Video under the Handheld synch options.  Is it possible to add this in?

There is no difference to DV processing depending on the target output. First all DV transformations are applied resulting in an (improved) HDR10 image, only then it is processed further (or not in case of pass-through). Tonemapping is not impacted by it at all. We don't even get the per-scene brightness data from DV right now to supplement the DTM (instead we do our own measurements as with all content), although I plan to add that in a future update, it just takes some work to pass the data from the source through the decoder to the renderer and requires a bunch of components to line up, including external ones.

Thanks a lot for the detailed explanation, much appreciated.

One thing I forgot to mention in the first post that might help explain the difference some of us experience between manually enabling OS HDR before playback and leaving it disabled, and possibly the dropped frames issue in HDR passthrough:

- When OS HDR is disabled before playback, if you look at the vSync info in the JRVR OSD it jumps all over the place. I don't think it reflects the actual vsync rate, as there is no more or less frames dropped or repeated, but it moves up and down like crazy. This never happens with madVR.

- When OS HDR is enabled before playback, the vSync info in the OSD is rock steady, as it should be: 119.880hz when playing 23p content at 119p.

Can you reproduce this behaviour, and does it help to understand what might be wrong for some users and not others? Could it be different depending on the processing/rendering path/hardware acceleration options etc?

I'll do the tests with the VRROOM as soon as I can, but I have to do *some* work today in between the testing

There is no difference to DV processing depending on the target output. First all DV transformations are applied resulting in an (improved) HDR10 image, only then it is processed further (or not in case of pass-through). Tonemapping is not impacted by it at all. We don't even get the per-scene brightness data from DV right now to supplement the DTM (instead we do our own measurements as with all content), although I plan to add that in a future update, it just takes some work to pass the data from the source through the decoder to the renderer and requires a bunch of components to line up, including external ones.

Decided to get the JBL 306P MKIIs after doing comparisons. Should be here in a day or two, I'm excited!

I hope you enjoy them!  I mentioned up thread that I've got a pair of the 308P's which are very similar and I like them a lot. 

There's a nice review here with a suggestion or two for DSP: https://www.audiosciencereview.com/forum/index.php?threads/jbl-306p-mk-ii-review-studio-monitor.18505/

I also occasionally see the super tiny window issue, but have been seeing it intermittently for years (on a Wayland session).  It's a "once every couple of months" kind of issue so I never tried to chase it down.

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.

I had the MC28 folder in the bin, ran MC 32 successfully and restored my media. Then I tried restoring my MC28 settings (on MC32) through the backup as well. MC32 said it needed to restart. And when it tried restarting it crashed in the same way it did before. So I had to reinstall MC32 in order to have it run again. So apparently there’s something particular about the MC28 settings, which didn’t prevent me from running MC28 earlier however (before I deleted it). I will attach the backup file to this post later.