Hardware transcoding issue

Plex Media Server
312

Thanks…

So to recap:

  1. Same Nvidia drivers
  2. PMS 1.31.3 on the native host works
  3. PMS 1.29.2 in the container works
  4. PMS 1.31.3 in the container fails

That about it?

313

That’s 100% correct. Here are the logs for 1.29.2…

It is running totally fine.
Plex Media Server Logs_2023-03-16_16-04-54.zip (842.9 KB)

And really thank you for the support! I mean it.

314

Thank you. I will pass these on to the Engineer.

Stand by for

:bomb:

:fire:

LOL

315

I know it is really weird… I have been hitting my head for awhile until I decided to post it here.

316

you said 1.31.3 … you gave me 1.31.2 container logs.

Sorry to be picky but need this all exact. Did I misunderstand ?

Build 6810 fixed a lot of issues but more were fixed in the next.

317

I got instructions. Please hang in a sec. Writing them here now:

318

you are correct. I did a quick update using docker plexinc/pms-docker:latest tag

Here are the logs with 1.31.3.6819 where I have to install via dpkg.

Plex Media Server Logs_2023-03-16_16-34-00.zip (1.2 MB)

319

Instructions for us to use inside the container.

  1. Plex 1.31.2/1.31.3 is running inside the container

  2. Setup the debug (backtrace) environment so we can see why it’s failing.
    ( We do all the debugging inside the container )

docker exec -it  <container>  bash
apt-get -y install lldb
ps -ef | grep 'Plex Media Server'      # we want the pid number
lldb -p <pid_number>
b std::invalid_argument::invalid_argument
  1. Now attempt to transcode again.
    – It should never actually start to play
    – In the docker-exec window
load syms
bt

  1. This will load the symbol table (module names and line numbers) the backtrace the program stack.

  2. Please use the mouse to highlight the text in the terminal window.
    right-click the highlighted text → COPY

  3. Return to this reply window and PASTE that text in the “Reply” window and send it (so I get it here).

  4. I’ll reformat it if needed

1 Like
321

This is what I have from my attempt

root@ff07774b6978:/# ps -ef | grep ‘Plex Media Server’
plex 1058 286 1 17:26 ? 00:00:04 /usr/lib/plexmediaserver/Plex Media Server
root 2044 587 0 17:32 pts/0 00:00:00 grep Plex Media Server
root@ff07774b6978:/# lldb -p 1058
(lldb) process attach --pid 1058
Process 1058 stopped

  • thread #1, name = ‘Plex Media Serv’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #2, name = ‘PMS TimerPool’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #3, name = ‘PMS Logger’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #4, name = ‘PMS sigwait’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #5, name = ‘PMS HttpServer’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #6, name = ‘PMS HttpServer’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #7, name = ‘PMS HttpServerM’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #8, name = ‘PMS GTP’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #9, name = ‘PMS HttpClient’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #10, name = ‘PMS FileWatcher’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #11, name = ‘PMS FileWatcher’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #12, name = ‘PMS Timer’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #13, name = ‘Plex Media Serv’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #14, name = ‘PMS NetService’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #15, name = ‘PMS GTP’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #16, name = ‘PMS CPM’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #17, name = ‘PMS FileWatcher’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #18, name = ‘PMS HttpServer’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #19, name = ‘PMS GTP’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #20, name = ‘PMS FileWatcher’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #21, name = ‘PMS FileWatcher’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #22, name = ‘PMS FileWatcher’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #23, name = ‘PMS FileWatcher’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #24, name = ‘PMS FileWatcher’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #25, name = ‘PMS GTP’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #26, name = ‘PMS ReqHandler’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #27, name = ‘PMS GTP’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #28, name = ‘PMS ReqHandler’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #29, name = ‘PMS ReqHandler’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #30, name = ‘PMS ReqHandler’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #31, name = ‘PMS HttpClientC’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #32, name = ‘PMS ReqHandler’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14
    thread #33, name = ‘PMS LT ChangeSt’, stop reason = signal SIGSTOP
    frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
    → 0x7fbdb05a1739: retq
    0x7fbdb05a173a: jmp 0x7fbdb059e314
    0x7fbdb05a173f: pushq %r15
    0x7fbdb05a1741: pushq %r14

Executable module set to “/usr/lib/plexmediaserver/Plex Media Server”.
Architecture set to: x86_64-pc-linux-gnu.
(lldb) b std::invalid_argument::invalid_argument
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
(lldb) b
Current breakpoints:
1: name = ‘std::invalid_argument::invalid_argument’, locations = 0 (pending)

(lldb) load syms
error: ‘load’ is not a valid command.
(lldb) bt

  • thread #1, name = ‘Plex Media Serv’, stop reason = signal SIGSTOP
    • frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
      (lldb) load syms
      error: ‘load’ is not a valid command.
      (lldb) b
      Current breakpoints:
      1: name = ‘std::invalid_argument::invalid_argument’, locations = 0 (pending)

(lldb) bt

  • thread #1, name = ‘Plex Media Serv’, stop reason = signal SIGSTOP
    • frame #0: 0x00007fbdb05a1739 ld-musl-x86_64.so.1
      (lldb)
322

SIGSTOP is from hitting Control Z .

Did you suspend it?

323

Hold up please. I"ve been given partial info. I am learning as we go here.
(sorry for the delays)

324

No. I simply performed the following:

  1. updated to latest deb file to be at 1.31.3.6819 ( I had to manually update)
  2. Restart docker
  3. connect to docker
  4. check pid

image
image1764×163 6.01 KB

  1. perform lldb attached to pid ( I chose the first pid)

image

(lldb) process attach --pid 305
Process 305 stopped

  • thread #1, name = ‘Plex Media Serv’, stop reason = signal SIGSTOP
    frame #0: 0x00007f2f05fb3739 ld-musl-x86_64.so.1
    → 0x7f2f05fb3739: retq
    0x7f2f05fb373a: jmp 0x7f2f05fb0314
    0x7f2f05fb373f: pushq %r15
    0x7f2f05fb3741: pushq %r14
    thread #2, name = ‘PMS TimerPool’, stop reason = signal SIGSTOP
    frame #0: 0x00007f2f05fb3739 ld-musl-x86_64.so.1
    → 0x7f2f05fb3739: retq
    0x7f2f05fb373a: jmp 0x7f2f05fb0314
    0x7f2f05fb373f: pushq %r15
    0x7f2f05fb3741: pushq %r14
    thread #3, name = ‘PMS Logger’, stop reason = signal SIGSTOP
    frame #0: 0x00007f2f05fb3739 ld-musl-x86_64.so.1
    → 0x7f2f05fb3739: retq
    0x7f2f05fb373a: jmp 0x7f2f05fb0314
    0x7f2f05fb373f: pushq %r15
    0x7f2f05fb3741: pushq %r14
    thread #4, name = ‘PMS sigwait’, stop reason = signal SIGSTOP
    frame #0: 0x00007f2f05fb3739 ld-musl-x86_64.so.1
    → 0x7f2f05fb3739: retq
    0x7f2f05fb373a: jmp 0x7f2f05fb0314
    0x7f2f05fb373f: pushq %r15
    0x7f2f05fb3741: pushq %r14
    thread #5, name = ‘PMS HttpServer’, stop reason = signal SIGSTOP
    frame #0: 0x00007f2f05fb3739 ld-musl-x86_64.so.1
    → 0x7f2f05fb3739: retq
    0x7f2f05fb373a: jmp 0x7f2f05fb0314
    0x7f2f05fb373f: pushq %r15
    0x7f2f05fb3741: pushq %r14
    thread #6, name = ‘PMS HttpServer’, stop reason = signal SIGSTOP
    frame #0: 0x00007f2f05fb3739 ld-musl-x86_64.so.1
    → 0x7f2f05fb3739: retq
    0x7f2f05fb373a: jmp 0x7f2f05fb0314
    0x7f2f05fb373f: pushq %r15
    0x7f2f05fb3741: pushq %r14
    thread #7, name = ‘PMS HttpServerM’, stop reason = signal SIGSTOP
    frame #0: 0x00007f2f05fb3739 ld-musl-x86_64.so.1
    → 0x7f2f05fb3739: retq
    0x7f2f05fb373a: jmp 0x7f2f05fb0314
    0x7f2f05fb373f: pushq %r15
    0x7f2f05fb3741: pushq %r14
    thread #8, name = ‘PMS GTP’, stop reason = signal SIGSTOP
    frame #0: 0x00007f2f05fb3739 ld-musl-x86_64.so.1
    → 0x7f2f05fb3739: retq
    0x7f2f05fb373a: jmp 0x7f2f05fb0314
    0x7f2f05fb373f: pushq %r15
    0x7f2f05fb3741: pushq %r14
    thread #9, name = ‘PMS GTP’, stop reason = signal SIGSTOP
    frame #0: 0x00007f2f05fb3739 ld-musl-x86_64.so.1
    → 0x7f2f05fb3739: retq
    0x7f2f05fb373a: jmp 0x7f2f05fb0314
    0x7f2f05fb373f: pushq %r15
    0x7f2f05fb3741: pushq %r14
    thread #10, name = ‘PMS HttpClient’, stop reason = signal SIGSTOP
    frame #0: 0x00007f2f05fb3739 ld-musl-x86_64.so.1
    → 0x7f2f05fb3739: retq
    0x7f2f05fb373a: jmp 0x7f2f05fb0314
    0x7f2f05fb373f: pushq %r15
    0x7f2f05fb3741: pushq %r14
    thread #11, name = ‘PMS FileWatcher’, stop reason = signal SIGSTOP
    frame #0: 0x00007f2f05fb3739 ld-musl-x86_64.so.1
    → 0x7f2f05fb3739: retq
    0x7f2f05fb373a: jmp 0x7f2f05fb0314
    0x7f2f05fb373f: pushq %r15
    0x7f2f05fb3741: pushq %r14
    thread #12, name = ‘PMS FileWatcher’, stop reason = signal SIGSTOP
    frame #0: 0x00007f2f05fb3739 ld-musl-x86_64.so.1
    → 0x7f2f05fb3739: retq
    0x7f2f05fb373a: jmp 0x7f2f05fb0314
    0x7f2f05fb373f: pushq %r15
    0x7f2f05fb3741: pushq %r14
    thread #13, name = ‘PMS Timer’, stop reason = signal SIGSTOP
    frame #0: 0x00007f2f05fb3739 ld-musl-x86_64.so.1
    → 0x7f2f05fb3739: retq
    0x7f2f05fb373a: jmp 0x7f2f05fb0314
    0x7f2f05fb373f: pushq %r15
    0x7f2f05fb3741: pushq %r14
    thread #14, name = ‘Plex Media Serv’, stop reason = signal SIGSTOP
    frame #0: 0x00007f2f05fb3739 ld-musl-x86_64.so.1
    → 0x7f2f05fb3739: retq
    0x7f2f05fb373a: jmp 0x7f2f05fb0314
    0x7f2f05fb373f: pushq %r15
    0x7f2f05fb3741: pushq %r14
    thread #15, name = ‘PMS NetService’, stop reason = signal SIGSTOP
    frame #0: 0x00007f2f05fb3739 ld-musl-x86_64.so.1
    → 0x7f2f05fb3739: retq
    0x7f2f05fb373a: jmp 0x7f2f05fb0314
    0x7f2f05fb373f: pushq %r15
    0x7f2f05fb3741: pushq %r14
    thread #16, name = ‘PMS CPM’, stop reason = signal SIGSTOP
    frame #0: 0x00007f2f05fb3739 ld-musl-x86_64.so.1
    → 0x7f2f05fb3739: retq
    0x7f2f05fb373a: jmp 0x7f2f05fb0314
    0x7f2f05fb373f: pushq %r15
    0x7f2f05fb3741: pushq %r14
    thread #17, name = ‘PMS GTP’, stop reason = signal SIGSTOP
    frame #0: 0x00007f2f05fb3739 ld-musl-x86_64.so.1
    → 0x7f2f05fb3739: retq
    0x7f2f05fb373a: jmp 0x7f2f05fb0314
    0x7f2f05fb373f: pushq %r15
    0x7f2f05fb3741: pushq %r14
    thread #18, name = ‘PMS GTP’, stop reason = signal SIGSTOP
    frame #0: 0x00007f2f05fb3739 ld-musl-x86_64.so.1
    → 0x7f2f05fb3739: retq
    0x7f2f05fb373a: jmp 0x7f2f05fb0314
    0x7f2f05fb373f: pushq %r15
    0x7f2f05fb3741: pushq %r14
    thread #19, name = ‘PMS FileWatcher’, stop reason = signal SIGSTOP
    frame #0: 0x00007f2f05fb3739 ld-musl-x86_64.so.1
    → 0x7f2f05fb3739: retq
    0x7f2f05fb373a: jmp 0x7f2f05fb0314
    0x7f2f05fb373f: pushq %r15
    0x7f2f05fb3741: pushq %r14
    thread #20, name = ‘PMS HttpServer’, stop reason = signal SIGSTOP
    frame #0: 0x00007f2f05fb3739 ld-musl-x86_64.so.1
    → 0x7f2f05fb3739: retq
    0x7f2f05fb373a: jmp 0x7f2f05fb0314
    0x7f2f05fb373f: pushq %r15
    0x7f2f05fb3741: pushq %r14
    thread #21, name = ‘PMS ReqHandler’, stop reason = signal SIGSTOP
    frame #0: 0x00007f2f05fb3739 ld-musl-x86_64.so.1
    → 0x7f2f05fb3739: retq
    0x7f2f05fb373a: jmp 0x7f2f05fb0314
    0x7f2f05fb373f: pushq %r15
    0x7f2f05fb3741: pushq %r14

Executable module set to “/usr/lib/plexmediaserver/Plex Media Server”.
Architecture set to: x86_64-pc-linux-gnu.
(lldb)

  1. Ran b std::invalid_argument::invalid_argument

image

  1. tried to open a channel but I was not even able to load them

image
image920×544 26.8 KB

325

No worries!

326

I will be sending you a PM with a link to download a file you need for this.

plexmediaserver_1.31.3.6819-2ef591a4c

This is what you have installed?

327

We’ll pick this up tomorrow. It’s fighting me every step of the way inside the container. Outside the container, the debugger is trivial.

328

That’s correct.

The file I used was plexmediaserver_1.31.3.6819-2ef591a4c_amd64.deb

329

After reading the entire thread it looks like I’m having the same issues as @Ossalingur in post 206. I know the “me too” post doesn’t help so I will try and expand on this.
Im trying to get PMS to use the Nvidia Quadro p400 in my system. The system it’s self is a Xeon based server with 2 x E5-2630 v3 CPU’s. This is where my issue is the same as previous, Hardware encoding seems to fail with this cpu’s, even though I’m trying to use the gpu. The stream simply stops when trying to transcode from source format to anything.

I have tried a number of solutions with no success including trying different Nvidia drivers 525 and 515. Also different PMS versions, Version 1.31.2.6810 and also 1.28.0.5999. Again same issue stream stops when selecting different quality in the web player.
My set up is the same as Ossalingur as I’m using Proxmox as the hypervisor with PCI passthrough, have tested this on both ubuntu 20.04 and 22.04 with the same results. No hardware transcoding. The passthrough works as I am able use the card inside VM’s.

Sorry for the essay in my first post, more than happy to help try and get to the bottom of this.
All I keep seeing in the logs is:

Mar 16, 2023 21:52:23.054 [0x7fc63a515b38] ERROR - [Req#278/Transcode] [FFMPEG] - libva: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
Mar 16, 2023 21:52:23.054 [0x7fc63a515b38] ERROR - [Req#278/Transcode] [FFMPEG] - Failed to initialise VAAPI connection: -1 (unknown libva error).
Mar 16, 2023 21:52:23.054 [0x7fc63a515b38] DEBUG - [Req#278/Transcode] Codecs: hardware transcoding: opening hw device failed - probably not supported by this system, error: I/O error
330

@2neon

The errors about vaapi and the CPU are correct.
The transcoder is probing to see if it can support the requested transcode which Xeon E5-2630 v3 cannot ( my E5-2690 v4 can’t either )

“PCI passthrough” is vague to me.

You only want to pass through , as devices, “/dev/dri” from the filesystem

Regarding ProxMox and VM… My recommendation is to use a LXC.
The container environment is much lighter than a full abstraction and ‘heavy’ OS install.

I use LXC’s here on my server. They require only 200-300 MB for a full installation.

331

Thank you ChuckPa.
I understand that the cpu can’t transcode. That’s not a problem I’m more than happy to ignore those errors.
By PCI passthrough I was referring to the config on Proxmox. I have add the GPU to the virtual machine and giving it full access to the p400, therefore it cant be used by any other virtual machine. Therefore the quadro shows up in ubuntu vm. I went for the full vm rather than the LXC as I run a few things on this vm with my media.
On my ubuntu PMS I can see /dev/dri/renderD128 but it the stream stops when I change the quality to use the hardware transcoding.
I will look at using LXC I didnt realise it was the preferred option.
Is it possible to get the full ubuntu vm working, I can post full logs if required?

332

For what it’s worth. I have made a big discovery regarding my issue.

My issue was that I wanted to run PMS in a rack server. And I was only getting PMS working properly in a non-rack desktop PC’s. After a lot of trial and error on various different rack servers. I have finally found a configuration where PMS is working like it should, and without issues, in a rack server.

To clarify. I can get PMS working on all rack servers. But there are random & intermittent playback issues across the board that start showing up on the rack servers. These issues affect STARTING PLAYBACK as well, and affect different clients to a varying degrees. But it seems really really hard to pin down what’s happening, and when it’s going to happen. It seems related to how long since the server was rebooted, how much load there is, etc etc. All kinds of variables.

But I figured that when switching quality works in Chrome, then everything else also works much more reliably. So I can use that easy to reproduce issue to gauge if a PMS setup is going to work reliably or not.

Now I have tried probably over 10 different Xeon servers, with no luck. Changing quality in Chrome never works. All these servers are dual socket and have 2 CPU’s installed.

I tried EPYC server with dual 7742. 128/256T core monster server. Changing quality also never works. As expected random intermittent reliability issues show up after running for few days.

Tried a system with a single Threadripper PRO. Changing quality works fine. Other issues gone as well.

The EPYC & Threadripper PRO are very similar CPU, almost just the server & consumer version of the same CPU.

I installed proxmox on both systems. And tested running the same Guest VM on both machines. Same behavior. No issues when the VM is running on Threadripper PRO. Unable to switch quality and other random issues when VM runs on the EPYC server.

Since the EPYC server is a dual socket system. Half the memory is on one CPU, and the other half is on the other CPU. Also the PCI-e slots are spread between the CPU’s. I confirmed that on my server, the NVIDIA card is on NUMA node 0. I tested adding the following line to Guest VM proxmox configuration
numa0: cpus=0-127,hostnodes=0,memory=131072,policy=bind

This makes Proxmox assign the memory and CPU cores/threads from the same NUMA node. Now the VM is only getting assigned resources from the NUMA node 0, which also has the NVIDIA GPU. Suddenly all the issues are gone. PMS is now running flawlessly without any issues on the Guest VM running on the EPYC server, and now it’s also, very noticably, possible to switch quality in Chrome.

It is interesting to note, that NVIDIA transcoding on Jellyfin & Emby work the same whether running on a single or dual socket systems. So there seems to be some fundamental difference in how they are doing it.

I am exhausted from all this testing and after discovering this I have stopped, since I finally got it running properly in a rack. I hope this investigation could prove helpful in understanding & fixing these issues.

2 Likes