Debian VM unreliable playback

Server Version#: Version 1.14.1.5488
Player Version#:Current Roku and Roku Beta - Sony Playstation 4 - Android Player

I’m having an interesting time trying to determine some unreliable playback issues which seem specific to Live TV.

My setup is the following:

HP DL360p - Dual Xeon E5-2609 2.4ghz host with ESXi 6.0 CU3 Proliant image.
VM has dual sockets, 4 cores each with unlimited resources per vCPU and 8gb of memory which is overkill, yes, I’ll reduce later.

Storage - FreeNAS connected via iscsi with jumbo frames on.

Switching - Powerconnect 5548p

Live TV - HDRomerub Prime

OK - Now that’s out of the way - the issue I seem to be encountering is related to Live TV specifically. I seem to be able to play back movies and music no problem what so ever. The resources for both TV and movies seem to be about 80-90% per core that is transcoding.

While watching TV it will usually be good for about the first 30min to 1 hour, and then refresh once, and after that refresh, about 5 minutes later, drop out saying the server wasn’t fast enough to support the play back. So I’m curious if the resources in question are strictly compute relayed, or related to storage as well. Is anyone else experiencing similar issues? If it’s possible its storage related, can I set where the live recording happens? If it’s compute related, it’s definitely not slow hardware, so I wonder if it’s Debian not using it correctly?

I’d really like Plex to be my main source for watching TV so I can continue getting rid of set top boxes to save more and more money. Thanks for any insight!

  1. PMS in any VM is problematic. It is a layer of abstraction and resource waste.
  2. Configuring and using a VM, just because one can, serves no purpose.
  3. Jumbo Frames on Home LAN are incorrect usage. Most consumer grade equipment cannot handle them even when perfectly configured.

With all due respect, two things have been done because it’s “swoopy”. It is strongly recommended to go back to basics.

  1. Native PMS installation on Debian
  2. MTU = 1500 for all LAN (I get 800 MB./sec using MTU 1500 on my LAN)

Hey Chuck,

Thanks for the reply! This is setup as an enterprise environment with only enterprise equipment and jumbo frames must be used due to support my FreeNAS being used to house my datastores. I have absolutely zero consumer hardware in my network. So with that being said, is the best practice to not use any virtualization with PMS? How does enabling it in FreeNAS fair?

Finally, I’ve been considering building a 1u Mini ATX server with an 1151 socket and mounting some iscsi storage if direct hardware access is required. Thanks for the help!

Here is the problem, You’re sending to a consumer grade television app aren’t you?
It isn’t rated for enterprise.

Best practice on Linux is to not use a VM when possible.
You can backup, restore, relocate PMS with a simple tar file.

I guess I’m a little confused here. I’m not arguing with you about what Plex Media Server works best on, I’m asking. I’m also making sure you have a full picture of my environment which is setup in a very specific manner. For example, the jumbo frames are enabled, but frame size is configured per port, and those ports are where the storage network rests on. So if I need to alter how I’ve installed Plex, where I’ve installed it I’m willing to do so, I just can’t seem to find a hardened best practice white paper on what the defacto go-to method is.

It seems as though you’re saying baremetal installs are the best method, correct?

Cool, thanks! Is there a way of backing up Plex as a whole or do I need to move the data reindex/rename the media again?

Now, speaking to the enterprise equipment in a domestic environment…

Dial it back down. MTU=1500. You have the capability if enterprise equipment.
Make enterprise run in that domestic environment. I’m running 20 GbE in domestic with MTU=1500 and it’s flawless. 10GbE legs are solid. The “trick” is setting rsize and wsize options on the NFS mounts correctly. Gigabit is rated for 100 MB/sec. It actually can send 120MB/sec with of bits because of how the symbols are encoded and clocking speed. This is why 117 MB/sec is often seen.

Frankly, if you need more than 2x 117MB/sec of video streaming, You’re no longer domestic, home use.

This takes care of how to reposition / relocate the media
Split this task.

  1. Turn off the auto updating BEFORE moving PMS Library

  2. Tarball PMS’ ./Library and take that to the host OS side outside the guest.
    (comes from here)
    Moving PMS 'Library'

Think about what;s happening.

  1. Absolute path to media is changing so PMS auto updating must be turned off then addressed after PMS itself is relocated
  2. PMS from inside the VM is relocated to the native host. (second link above)
  3. Once running on the native host, each defined library section is updated to point to the new paths (the first link above)

Excellent, thanks for the guides!

Glad I can help.

While at it, please do turn down those MTUs. You will be happier in the long run (and I will be less frustrated… HAHAHA)

I’ll try it out and see how it responds. I’ll also be adding in a new 10gb storage switch stack.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.