Plex HTPC feedback

SOLVED: I had to edit Plex-HTPC preferences and enable a lot of options which this latest version did not have turned on compared to the older versions.
I did it by entering the Snap Store app and clicking on the Installed apps tab and then clicked on Plex-HTPC, where there you will see the Preferences tab.

I am still encountering a few issues though (I’d hoped installing a different Linux version would solve my previous issues but haven’t)

I will play around with settings and if i have no luck in resolving these issues i’ll post what they are and logs.

Great!

About your question before the edit.

As for logs, i’m not sure how to perform a log without being able to lunch the Plex app and turn it on.

Plex HTPC creates logs in almost any scenario even in case it won’t open! This helped me a lot in the past. :wink:

Windows: yes. MacOS: I’m not sure anyone has tried it yet.

When does it increase? Is it during playback, browsing around, screensaver, idling? Are you using external shaders?

This may require the config=true to be set (which Is likely not possible to set from the mpv.conf file). One of the developers experimented with the console.lua script and got it working with dynamically adjusting keybindings to go to the script.

Could you be more specific? I examined the diff from 1.14 to current and there was no change to log verbosity, no change to mpv itself, and the only change to ffmpeg has nothing to do with logging.

During playback. Whenever I start playing back a movie (1080p or 4K does not matter - 4K files fill it faster) a portion of VRAM gets correctly occupied but after playback or when I exit the file the VRAM does not get flushed. With every following movie another portion gets occupied on top of the other one… Repeating this fills up the VRAM entirely and then swaps over to main memory. I attached a picture from the task manager showing this.

As you can see with every playback I start the VRAM usage increases further and further. After 7 started playbacks I´m already using over 4Gb of VRAM.

No shader - no external anything - just the included mpv-1.dll (or own one).

Ah okay.

The left one shows more info about what mpv is doing - the right one shows nearly nothing.

V. 1.14 log =>
Plex HTPC_v1.14.1.log (92,4 KB)

V. 1.13 log =>

Since you indicated earlier that you tried out a different build of the mpv library, can you try with it to see if you get anything different?

You turned off a bunch of logging. In your logs is:

Apr 18, 2022 19:59:20.713 [3324] DEBUG - [MPVEngine/mpv] cplayer: Reading config file C:/Users/mitzs/AppData/Local/Plex HTPC/mpv.conf
Apr 18, 2022 19:59:20.713 [3324] DEBUG - [MPVEngine/mpv] cplayer: Applying profile 'default'...
Apr 18, 2022 19:59:20.713 [3324] DEBUG - [MPVEngine/mpv] cplayer: Setting option 'vo' = 'gpu' (flags = 4)
Apr 18, 2022 19:59:20.713 [3324] DEBUG - [MPVEngine/mpv] cplayer: Setting option 'msg-level' = 'ffmpeg/video=status' (flags = 4)

That last line changes the msg-level. We set this to default to msg-level=all=v but your line in the mpv.conf changes this to msg-level=ffmpeg/video=status. I think what you want is msg-level=all=v,ffmpeg/video=status (see docs).

2 Likes

Oh yes, that did it for me! Thank you!! I should have looked this up in the manual before complaining. Sorry for wasting your time on this one!

Even with the self-compiled mpv lib it’s the same. (also with vo=gpu-next its happening)
Plex HTPC.log (534,8 KB)

So, in terms of tracking this down, there are some things to test/try:

  • Can you reproduce this with a recent build of the command-line MPV? The keep-open and keep-open-pause=no may be of use here.
  • Is the memory usage increase a per-playback or per-time? Basically if you play 20 2 minute items, is the memory increase faster than if you play a 40 minute item?
  • Is there a difference in the increase across different sized input files (does playing 720p, 1080p, 4k make a difference)?
  • Does enabling/disabling hardware decoding make a difference (hwdec=auto to enable on the CLI)
  • Is there a difference if you use the vulkan (gpu-context=winvk)? Note that our MPV library doesn’t support this yet.
  • There is an option gpu-debug which may be of help here because one of the things it prints out is the number of d3d device objects but it doesn’t appear to work from within HTPC (fails to initialize).

This is starting to look like a bug in MPV and if it reproduces on the CLI MPV that would be of a great help in diagnosing/reporting.

no - even with -keep-open=yes and -keep-open-pause=no I´m not able to reproduce this with the command line mpv player. When playback starts a small portion of VRAM is occupied, when the file ends and the next one in the folder starts playing VRAM usage drops (or rises) to the amount that is needed for the new file. When mpv is done playing all files in the folder and is showing the last frame of the last file (mostly a black frame) VRAM usage is as high as at the beginning of playing the last file. After quitting mpv VRAM usage drops to the amount before mpv was opened.

As far as I could test this it is per-playback - while playing back a file the VRAM usage does not increase significantly (I´ve seen some variation - high bitrate parts needed a bit more VRAM but that usage dropped to the first occupied amount after the high bitrate part was over)
But to be more precise I will test this with a longer file.

Yes,
4K files use the most therefore VRAM is filled faster - 1080p files are noticeable but not that extreme and 720p material is almost not noticeable.

The amount of VRAM that is used for a file is the same size as when played with the command line player.
(4K File ~ 200/300mb VRAM, 1080p File ~ 70-100mb)

no - also with hwdec=no in the cli player I could not trigger the problem.
Plex HTPC with hardware decoding deselected/disabled still shows the problem of VRAM usage increasing after each file. The VRAM usage per file is lower tho (same in the mpv cli player)

YES!!! With gpu-context=winvk being set in the mpv.conf VRAM is flushed correctly after each file.
This applies to vo=gpu and vo=gpu-next + hwdecoding enabled/disabled
(hwdec being dxva2-copy only)

Logs:
Plex HTPC-gpu-next-winvk.log (360,0 KB)
Plex HTPC-gpu-next-winvk-hwdec.log (406,6 KB)
Plex HTPC-gpu-winvk.log (189,7 KB)

For testing purposes, I set Plex HTPC to use angle (Playback quality “Normal (Angle)”) and also with this gpu-context VRAM is flushed correctly after playback. So this is a gpu-context=d3d11 issue of some sort although I was not able to reproduce it with the standalone player.


The mpv version I used in the cli - it is the same one I used to test this behavior with Plex HTPC.
If desired I can provide this mpv build to you.

[cplayer] mpv 0.34.0-265-g305332f8a0 Copyright © 2000-2022 mpv/MPlayer/mplayer2 projects
[cplayer]  built on Sat Apr 16 16:39:38 UTC 2022
[cplayer] FFmpeg library versions:
[cplayer]    libavutil       57.24.101
[cplayer]    libavcodec      59.26.100
[cplayer]    libavformat     59.22.100
[cplayer]    libswscale      6.6.100
[cplayer]    libavfilter     8.33.100
[cplayer]    libswresample   4.6.100
[cplayer] FFmpeg version: git-2022-04-15-4e98cc29f
[cplayer]

(I hope my explanations are understandable - I´m not a native English speaker)

1 Like

Please make it so we can use a mouse to explore and interact with the app.

Thanks for testing all these cases out. It does look like it’s an issue with the d3d11 context. It may be due to the setup/teardown of a child window that it does there which is inducing the issue. If you want to test this, then this may work in the mpv.conf wid=-1. This would make HTPC pop up a new window for the video playback. If the VRAM leak doesn’t occur there, then that does narrow down the culprit code. My guess is that it won’t occur.

I did have you perform some more tests than I did on my own but thus far your results are consistent with mine. At least this narrows things down to a smaller portion of the MPV codebase.

As answered in this thread previously (multiple times), if you want an app where you use a mouse interface, then use Plex for Mac/Windows. Plex HTPC is intended to be used without a mouse (though it supports limited mouse operation).

Can you check this again? In my testing turning off hardware decoding doesn’t leak VRAM. Do note that simply browsing around can increase VRAM usage because the UI is GPU rendered so it’s best to see the value just before playback, play, stop, repeat and see if there’s an increase.

Unfortunately, it also occurs with wid=-1 set. I can easily reach 3Gb of used VRAM like before.

Indeed it does not occur with hwdec disabled in Plex HTPC. No idea what happened there on my tests. Sorry!

Same. That means the issue is not where I thought it was but somewhere else. See below:

Well, to add more mystery to this, it appears that (at least in some cases) it does reproduce with hardware decoding not set.

Anyway, we’ve narrowed it down to actually reproduce it in the CLI MPV. If you can confirm this, we’d appreciate it as it helps figure out where in the MPV codebase to look:

  1. Name your file something easy (I used HDR.mp4 in the MPV directory in my tests)
  2. Start monitoring VRAM usage
  3. Run mpv --idle=yes HDR.mp4
  4. Hit up arrow to skip to the end
  5. Window will go away at the end
  6. Go back to the CLI and see that MPV is still running.
  7. Type a backtick, followed by loadfile HDR.mp4 and hit enter (which is fun because you won’t see what you type)
  8. It’ll play the file again
  9. Repeat from step (4) until satisfied with the test

Just tried this and yes I can confirm it! (mpv.com --hwdec=d3d11va --idle=yes HDR.mkv) After 6 repetitions I hit the 2,2Gb VRAM mark so it’s definitely not flushing the VRAM.

So, in the process of trying to localize the issue, it turns out one of the diagnostic tools stops the leaks. So if you add gpu-debug=yes to your mpv.conf file, it seems to not leak anymore. Try that out.

1 Like

Heisenbug!

1 Like

Or perhaps there is code that’s currently only executed when debug is engaged but should be executed in general. I’m looking at mpv/ra_d3d11.c at a2d86333f4a484abcd5d2f7e505befdb388d70c2 · mpv-player/mpv · GitHub as potentially that.

Edit: Confirmed that the above code is the factor. When it is patched to execute even when gpu-debug isn’t set, the leaks stop. MPV devs have been informed and they are looking into it.

2 Likes

Hi,

Is someone able to confirm if the HDR support that was added with Plex HTCP “gpu-context=d3d11” was also added to Plex for Windows when using the same “gpu-context=d3d11”?

Thank you!

--gpu-debug=yes to no one surprise also fixed this on my side. (:

Yes. Though you don’t need to put the gpu-context in the mpv.conf anymore as it’s now part of the quality settings.

1 Like