Print

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

[mwillems]

So here's another weird one.  A while back I had an issue on one machine where JRVR was detecting the wrong framerate and choosing 50Hz instead of 60Hz.  Hendrik and bob tracked down the issue and fixed it, and it fixed video playback on that machine.  See this thread for details: https://yabb.jriver.com/interact/index.php/topic,132724.msg919768.html 

I don't use theater view a lot on that machine, but I noticed a few days ago that I'm seeing really weird judder in theater view on just that machine, but on none of my other machines.  The machine has a dedicated video card that can handle fairly high settings in JRVR, but seems to really stutter in theater view.  Other machines I have that use low-end integrated graphics on Linux have a much smoother theater view experience using the exact same server library.  I tried adjusting all the theater view settings I could reach on Linux (anti-aliasing, etc.), with no joy, but then it occurred to me that this was the same machine that had the frame rate problem in JRVR previously.  Is it possible that theater view is still using the old logic that JRVR previously used to set the framerate and its setting an incorrect framerate?  I can't figure out a way to get theater view to report a framerate on Linux or I'd know for sure, but it sure looks a lot like the issue I had previously with JRVR.

I tried many of the same troubleshooting steps I tried when I had the previous issue with JRVR:
- I tried toggling hardware acceleration with no effect.
- I tried changing my desktop refresh rate with no effect.
- I tried turning on and off the Nvidia composition pipeline settings in the nvidia-settings application, and specifying a mandatory 60Hz output, but those also had no effect.
- Ordinarily I would test on Wayland as well, but wayland support for Nvidia hasn't landed in Debian 11, so I can't test that easily.
- I also tried using a clean local library to make sure it wasn't some legacy setting, and I saw the same problem with default settings.

The machine is running debian stable (11) with the Gnome desktop and the system's graphics card is an NVidia 960 GTX, which is running the mainline nvidia-driver.  The graphics card works perfectly smoothly for JRVR video playback and other non-media graphics tasks.  It's just theater view that's acting strange.  Please let me know if I can provide any other details.

[Hendrik]

The previous fix would have also affected Theater View, so the detected frame rate should be accurate. But its also not really using it much, rather its just rendering against VSYNC, since it can just generate frames on demand rather then needing to present pre-determined frames at the right time.

The one thing I could imagine is that the timer on that system is rather coarse so its waiting in some spots too long, but thats really just guessing.

[mwillems]

The previous fix would have also affected Theater View, so the detected frame rate should be accurate. But its also not really using it much, rather its just rendering against VSYNC, since it can just generate frames on demand rather then needing to present pre-determined frames at the right time.

The one thing I could imagine is that the timer on that system is rather coarse so its waiting in some spots too long, but thats really just guessing.

Hmm, thanks for ruling that out.  Is there any way to get more information about theater view rendering (something like the Ctrl-J menu for JRVR)?

It really is night and day different than other systems in the house, it's fairly noticeable on UI interactions like basic menu navigation; on the problem machine it looks like it's just jerking from one menu item to another with either no animation or clipped animations. it looks like it's rendering at 20-25FPS or something.  One place that it's particularly noticeable is in fast scrolling in long lists.  If I hold the down button in a TV Guide view or a long album list, on most of my machines the animation is fairly fluid and still shows enough information to know when to stop holding the scroll button.  On the problem machine if I hold down the down button the UI just kind of blurs and freezes on the last screen before the scrolling started, and doesn't "catch up" and start rendering again until a few seconds after I release the button.  It makes it hard to navigate long views in theater view, so I'd like to find a way to get to the bottom of it. 

Let me know if there's any info I can provide that might be helpful!

[Hendrik]

I made some changes for the next build to try to improve the presentation logic, but with issues that only affect very specific systems its hard to make guesses on what might be causing it.

[mwillems]

I made some changes for the next build to try to improve the presentation logic, but with issues that only affect very specific systems its hard to make guesses on what might be causing it.

Thank you, I really appreciate you trying to run this down with me.  I'll report back once the build drops. 

And I hear you on idiosyncratic system issues.  I'm tempted to just blame nvidia because it's the only nvidia machine in my house, but I'm sure other people are successfully using nvidia cards with MC for Linux.