Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[voodoo5_6k]

I'm using Win 10 Pro 64-bit (fully patched) and the latest version of JRiver, with Red October HQ (madVR) playback (log & system info attached). The library is remote (Debian VM as library server on the NAS), files are *.iso however. Hence, they are downloaded and then played back (i.e. local files effectively).

Recently, I've noticed that I couldn't play back NTSC DVDs anymore (or I thought, the issue was with the NTSC DVDs). There was enormous stuttering (huge clock deviation, lots of dropped & repeated frames). After a while (like ca. 30s) everything would settle down somewhat, but still, playback wasn't smooth.

First, I thought: Driver issue? So, I went back to the "known good" driver for my system. No change in behaviour. After looking at other DVDs (PAL this time), I noticed comparable issues.

After a while I identified Videoclock as sort of being the culprit. After turning it off, everything works much better. However, I didn't turn on Videoclock by accident. It has always been on, since the initial install of JRiver. And it had worked great.

What has changed? Or, has something changed? I can't pinpoint it to a specific upgrade of MC27 because I'm using the system not often enough to actually evaluate each update with something like a test suite.

Today, I tested the setting again, after:

• Uninstalling JRiver
• Removing the nVidia driver with DDU
• Rebooting
• Installing the nVidia driver
• Installing JRiver

Then, I activated Videoclock and selected a DVD (PAL) via TheaterView. After the file was received from the library server, it was mounted by VirtualCloneDrive, and then played back via JRiver. No interaction with the system after the playback started. The DVD will bring up the menu, wait, and after some time will automatically start the main feature. After ca. 2 minutes, I did capture a screenshot of the madVR overlay and stopped the playback. Then, I "ejected" the *.iso and closed JRiver.

Now, I restarted JRiver, deactivated Videoclock and selected the same DVD as before. Again, download, playback, no interaction, screenshot at roughly the same time.

The difference is like night & day, with Videoclock being deactivated, there is only the slight initial stuttering that's always there, but then everything is smooth (however, not as smooth as it used to be-- the estimated time for frame drops/repeats used to be in the several hours or even higher range). With Videoclock enabled, the stuttering lasts much longer and there is massive frame drop/repeat. Also, the clock deviation is much higher (ironically, as Videoclock should do the opposite-- and it did, not too long ago).

Thanks already for looking into this...

PS: I'm aware that MC27 is kind of EOL, so maybe this topic belongs somewhere else now? If so, then I'm sorry and please feel free to move it respectively.

[JimH]

Try testing (separately) playback of a local file and playback with Red October Standard, just to see what you can learn.

Have you modified madVR settings?

Antivirus is always a suspect when playback is skipping.  Read the thread on Windows Defender and follow the directions there.

[voodoo5_6k]

Thanks Jim!

The files are already local. They are transferred from the library server to C:\Users\...\AppData\Roaming\J River\Media Center 27\Temp\. VirtualCloneDrive mounts the "Data File - ....iso" from there. Network is only involved during transfer of the file to the HTPC. But playback is only initiated after VCD mounts the local copy, per Windows autoplay.

Using Red October Standard makes a slight difference. The stuttering ends a few seconds earlier. But the identical symptoms. Videoclock on --> massive frame drops/repeats, Videoclock off --> significantly less frame drops/repeats (almost nothing at all, except for the usual stuttering when initiating DVD menu playback and at the beginning of a video).

Excluding JRiver folders per the "Taming Windows Defender" thread lead to no improvement, neither for Red October Standard nor HQ. For the same sequence the frame drops now reached over 2500 and the frame repeats over 4000. Disabling Videoclock results in 173 frame drops and 218 frame repeats for the same sequence again. Windows Defender doesn't seem to impact this.

Yes, madVR settings are modified. But they have not been modified since some time last year, when I set up the HTPC. Also, Red October Standard does show the same symptoms. Hence, madVR settings shouldn't be the causative agent for the frame drops/repeats (only for the few seconds difference between Red October Standard and HQ, but these few seconds of stuttering are not the issue here).

[JimH]

Can you eliminate Virtualclonedrive from the playback chain?

ISO is not so much in use now.  I think most people use makeMKV.  MC28 will have makeMKV integrated for ripping.

[voodoo5_6k]

Yes, I just uninstalled VCD and used Windows Explorer instead for mounting the *.iso. But no change, unfortunately.

Yeah, I know, many prefer "streamable" formats. But I physically collect all these discs, and I do like the menus etc. That's why I keep everything as an exact copy of the original (i.e. *.iso, or before that, VIDEO_TS folder rip). I've read about the planned makeMKV integration over in the MC28 area (I have never used makeMKV). I can imagine this being greatly appreciated by many of the users preferring streamable formats. Maybe I'll test it too once it is out (my upgraded Master License already includes MC 28), but I don't see me moving away from *.iso. On my server, there are exactly 5 *.mkv videos, everything else is either *.iso or VIDEO_TS folder rips. Even if I wanted to use *.mkv (which I don't), it would require quite an effort to convert everything.

[tij]

Make sure Temp folder were .iso are extracted is exluded from Defender scanning. Also ... make sure optical drives are excluded from Defender as virtual moumted drive act as optical drive.

If that doesnot work ... try disabling hardware decoding of videos.

EDIT: try checking your HDD on local machine with tools like CrystalDiskInfo to see if HDD are OK

[voodoo5_6k]

Thanks tij!

This also didn't help.

I decided to bite the bullet and kill the system... I did a fresh install of Windows etc., restored my JRiver license, settings and all... And it seems to work as it used to be, yay 

So, thanks for all your help and time, JimH & tij!

[tij]

Just a thought ... there are some types of programs that update their screens even though they are not in focus (usually to update the progress of something they are doing or something they are monitoring).

If these run while video is playing ..  it will cause stutter  drop/repeated frames and presentation glitches.

[voodoo5_6k]

Yeah, but this is a dedicated machine, there is nothing installed except VCD and JRiver (and drivers etc. of course). And only JRiver has access to the internet, everything else is blocked.

Also, this was directly related to the setting. Switching Videoclock on, starting playback --> massive frame drops/repeats. Stop playback, switching Videoclock off, starting playback --> very few frame drops/repeats. Stop playback, switching Videoclock on, starting playback --> massive frame drops/repeats again...

[zybex]

From the screenshots it looks like you have the display set to 50Hz, so you likely also enabled the "automatic change mode" option to have the display match the movie's refresh rate (or maybe that's just how VideoClock shows up). Correct me if I'm wrong, but I think this is much better than using Reclock/VideoClock (which does audio resampling), and in fact completely eliminates the need for it. If your monitor/TV supports 24/25/30/50/60hz modes, then this is the way to go. I've had this enabled in MadVR for years, and every single movie is smooth, with zero (or very low) frame drops/repeats. No need for audio resampling/speedup/slowdown, it just works.

Even in your "good case" above, there's a frame repeat every few seconds - with Automatic Mode Change, it's usually a frame repeat every few *hours*.

[voodoo5_6k]

madVR does the mode switching. But that alone isn't good enough with nVidia drivers- at least in my case. Hence, Videoclock is active too. And it works great. I don't notice the audio resampling. In my opinion (and that's it, an opinion), the advantages outweigh the disadvantages.

The "good case" you are referring too is what it looked like without Videoclock before I decided to reinstall the system (when Videoclock seemed to cause issues). If you look at the last screenshot from yesterday, it says "no frame drops/repeats expected" (if I recall this correctly, it is equivalent to several days between expected frame drops/repeats). This is on a fresh install with madVR mode switching plus Videoclock activated.

However, I agree with you. If the display drivers (nVidia in my case) did a better job of actually matching the desired refresh rate, there wouldn't be a need to mess with audio or the video or audio clock at all. But I never had any luck with the custom resolution options (from e.g. madVR), it didn't get me where Videoclock gets me. If one day it ever gets better or someone comes up with an even better solution for the video/audio clock issue, I'm all ears.

What GPU are you using?

[zybex]

I have an HTPC with a simple embedded Intel UHD 600. I use MPC-HC as external player for MC, with MadVR for presentation - mostly using DXVA scaling as the HTPC is underpowered for most of MadVR's algorithms (and frankly I don't see much difference with them enabled).
https://yabb.jriver.com/interact/index.php/topic,126065.msg873605.html#msg873605

Since I'm not using the embedded MC player, I need to setup MadVR manually. I entered the supported modes on the TV config section:
 - Display modes that MadVR may switch to: "1080p23, 1080p24, 1080p29, 1080p50, 1080p59, 1080p60"
 - Treat 25p movies as 24p (requires Reclock/VideoClock): OFF

This last option is important - if the TV supports 24p (23.976), then it should be off. I'm not sure how MC sets this up.

[voodoo5_6k]

That's one nice looking mini PC

Previously, I had my HTPC in this case: https://www.supermicro.com/en/products/chassis/Mini-ITX/101/SC101i

I had chosen Mini-ITX so that it is easier to upgrade. Given, the footprint obviously needs to be bigger than the NUCs or lookalikes, but still nice and tiny. When leaving PowerDVD behind and testing madVR, I too used the integrated GPU (of the i5-7500T). It was good enough for Lanczos + AR for DVD upscaling (to 1080p).

When I went madVR NGU (and JRiver), I added the GTX 1080 and moved the hardware to this case: https://www.fractal-design.com/products/cases/node/node-202/black/

Nice looking case, and not too big. Needed a few upgrades though

Re your madVR settings: I use exactly the same configuration, a defined list of valid modes and deactivated treat 25p as 24p

[Hendrik]

If you are using the internal MC media player, I would recommend setting up MC to do the mode switch, because it can do it before any part of the playback chain gets initialized, reducing risk of confusing eg. the audio renderer or videoclock from a sudden rate change, because madVR can of course only do it once madVR loads, which is much later in the initialization chain.

[voodoo5_6k]

Thanks for the tip Hendrik! I will change the config next time the system's running.

Edit: Oh, and thanks for creating something cool like LAV, by the way

[zybex]

Ditto, thanks for LAV And good tip - maybe I should have MPC-HC do the switching instead of MadVR, it might eliminate the initial stuttering.

Fractal Design is always a great choice - the Node 202 is nice for a living room. My primary concern is always noise, so I tend to get stuff without fans or with just a single slow/silent fan. Hence the Brix NUC, with the compromises it has.

[voodoo5_6k]

I have discovered an quite interesting behavior of MC27. I had activated the automatic mode switching in MC27, and deactivated it in madVR, as per Hendrik's suggestion. Everything seemed to work fine.

I didn't look into it any further, because I was working on my library. A few days ago, I finished the work on the *.iso, and shifted to the few remaining files (all *.mkv). On importing them, MC27 struggled quite a lot. It took forever (10 minutes or so) to import 6 (!) *.mkv, and in the end they were classified as media type "Data". Well, interesting. Seems to correlate to this here: https://yabb.jriver.com/interact/index.php/topic,127675.0.html (as my library server runs Debian). Was this ever solved?

Anyhow, after having re-tagged these files as "Video" and completing their information, I wanted to test them. MC27 streams them fine (just a quick test though), but it won't switch the display mode. It keeps the display at 50Hz. And that's why I initially though it would work, as this is the correct mode for PAL DVD (that's what was watched recently). I doublechecked, and madVR's mode switching option is disabled. I went back to the MC27 options and set specific modes for each sub-option. But no dice. Turning it off, and back on in madVR, it works instantly. Switching everything back to MC27 control... Nothing...

[Hendrik]

MC uses the FPS information in the library to do mode switching, so make sure that field is actually filled, which might be your issue if you had import issues of some sort.

[voodoo5_6k]

Thanks again Hendrik

This did the trick. I had assumed, MC would get this information when starting playback instead of relying on a potentially manipulated entry in the library.

I deleted the 6 *.mkv entries from the library, activated internet access for the VM and redid the import. This time, MC27 seemed to have installed what it needed to analyze the file on import. Maybe this should be installed automatically when setting up MC initially? On the other hand, my system may be a special case. The library server (VM) is offline (as is everything in my network that doesn't need or shouldn't have internet access), and it only has read-only access to all the data directories. Tagging etc. is done on another workstation (the workstation on which I also do the ripping etc.).

Anyhow, all fields got populated now, and testing this on the client (HTPC) was successful. Mode switching now works as intended.

[Hendrik]

I had assumed, MC would get this information when starting playback instead of relying on a potentially manipulated entry in the library.

Ah but the manipulation can be a feature, for example if you want to play a PAL DVD in 24p instead, because it was sped-up like many PAL DVDs are. All has its pros and cons.

[voodoo5_6k]

I see. Good & interesting point (PAL speed-up). I'll keep that in mind. Thanks!