Server-Linux (Ubuntu Server 16.04.6 LTS) - Plex failing to play numerous videos recently

Server Version#: 1.16.3.1402
Player Version#: 2.38.0.999

For the past few weeks a number of videos are unable to play through Plex, either using a web client or the Plex Media Player app - instead of opening the file Plex throws up an error box with the following:

Playback Error
There was an unexpected error during playback. Please visit our forums if you continue to experience problems.

So that’s a massively informative error message.

Absolutely none of these files has any problems being played through another player like Media Player, the Windows 10 Video app or Media Player Classic - they all work 100% fine using anything but Plex.

Looking through the forums tonight I found a lot of people complaining about current builds - is this a common error?

I have saved a log from the Plex Media Server, but haven’t posted it because it’s usually a terrible idea posting logs to public forums…

Please post logs and hopefully someone will be able to help:

Ok here are the logs:
Plex Media Server Log (1.8 MB)
Plex Media Player Log (98.2 KB)
Plex Web Client Log (89.8 KB)
Plex Web Client Chrome Capture Log 1 (28.5 KB)
Plex Web Client Chrome Capture Log 2 (28.3 KB)

Anyone?

Bueller?

Wow so there is no official Plex support for paying Plex customers, only these forums, and on these forums you can’t even get anyone to reply to your threads? Plex is deteriorating to the point where it’s not much more than a glorified catalogue - I’m playing most of the video files from Media Player Classic atm. It seems as simple as a lack of codecs, but hey I’m not a software engineer. There’s nothing clever or fancy going on with my Plex server, it’s just Plex (latest build) installed on top of Ubuntu Server and that’s it.

So where do I go from here? Seriously, anyone?

@TrevorX

I’m sorry that I was away and only getting here now.
I am a part-time employee with limited hours.

Thank you for the logs. So far, I am spotting

Jul 31, 2019 20:02:39.909 [0x7fa8b4ff9700] WARN - NAT: PMP, got an error: Not Supported by gateway.
Jul 31, 2019 20:02:39.909 [0x7fa8b4ff9700] DEBUG - HTTP requesting GET https://180-150-89-65.a2350c8d5b394e9ab98856562c74c0e4.plex.direct:32400/identity
Jul 31, 2019 20:02:39.910 [0x7fa8b4ff9700] ERROR - Error issuing curl_easy_perform(handle): 7

I will unfortunately need you to turn VERBOSE logging back off. Verbose provides packet-level logging which only hampers diagnosis. It hampers because it only allows default log buffers (26 MB) to retain about 2 minutes of elapsed time.

Please keep DEBUG on and VERBOSE off until requested.

I now would like you to recreate the problem you are seeing with the following steps:

  1. Verify logging
  2. Start playback
  3. Play until failure (which seems nearly immediate)
  4. Wait 30 seconds
  5. Settings - Server - Troubleshooting - Download Logs
  6. Drag & drop (upload) the ZIP.

Thanks.

Hi Chuck,

Thanks for replying. I understand your constraints and I’m happy to be patient, the issue was that there didn’t seem to be any active support.

I’m confused that the debug level seemed to show that verbose logging was turned on - I don’t have verbose logging enabled. Here’s a screenshot of the General settings page, where you can see that verbose logging is not enabled:

image

All I did was open the web page to the Plex server, go to that page and take a screenshot - I haven’t changed anything.

What I’ve done is manually disable logging, reboot, re-enable logging, then rebooted again, and hopefully this time it won’t use the verbose option. I can confirm that the verbose logging checkbox has not been checked at all during this process.

Here’s the log, produced after rebooting and attempting to play four files that failed with the error in question, and then waiting 30 seconds before downloading the log.

Plex Media Server Logs_2019-08-06_17-17-08.zip (1.8 MB)

Thanks for your help,

Trevor

Thanks for the logs.

I think I found the ominous offender :slight_smile:

Aug 06, 2019 17:15:24.569 [0x7fcb07fff700] WARN - [Notify] Received unexpected inotify event: 8192
Aug 06, 2019 17:15:24.569 [0x7fcb07fff700] WARN - [Notify] Received unexpected inotify event: 8192
Aug 06, 2019 17:15:24.569 [0x7fcb07fff700] WARN - [Notify] Received unexpected inotify event: 8192
Aug 06, 2019 17:15:24.569 [0x7fcb07fff700] WARN - [Notify] Received unexpected inotify event: 8192
Aug 06, 2019 17:15:24.569 [0x7fcb07fff700] WARN - [Notify] Received unexpected inotify event: 8192
Aug 06, 2019 17:15:24.569 [0x7fcb07fff700] WARN - [Notify] Received unexpected inotify event: 8192
Aug 06, 2019 17:15:24.569 [0x7fcb07fff700] WARN - [Notify] Received unexpected inotify event: 8192
Aug 06, 2019 17:15:24.569 [0x7fcb07fff700] WARN - [Notify] Received unexpected inotify event: 8192
Aug 06, 2019 17:15:24.569 [0x7fcb07fff700] WARN - [Notify] Received unexpected inotify event: 8192
Aug 06, 2019 17:15:24.569 [0x7fcb07fff700] WARN - [Notify] Received unexpected inotify event: 8192
Aug 06, 2019 17:15:24.569 [0x7fcb07fff700] WARN - [Notify] Received unexpected inotify event: 8192

You have more than 8192 total directories being monitored based on this message.

I would like you to tally the total number of directories in use from all the media you have indexed in plex.

find /nfs/nas-videos -type d -print | wc -l

If you also have music indexed, you can add it to the same find command.

As example:

find /nfs/nas-videos  /nfs/nas-music /nfs/nas-anything-else-here -type d -print | wc -l

When you get that total, I expect you’ll be well over 8192.
Please let me know what you get and I’ll show you how to address this.

Hi Chuck,

Looking through the forums I did see this was an error others were experiencing, but I didn’t think it applied to my circumstance. Here’s the output from that command:

image

Just 1643 directories seems a lot fewer than 8192…

Just for clarity, here’s a summary of all the volumes accessible to the Plex server:

image

There is no music directory mapped to Plex. Why do you think it would be showing the error related to a large number of directories in the index if there are only a fraction of those number? Do you think it could be caused by some sort of cache overflow?

Is Plex in a VM / container / snap ?

If any of these, I will suspect underlying permissions problems at the transfer point into the file system.

Yes, Plex is installed on Ubuntu running within a VM on a Hyper-V 2016 server, but I’m not sure how that’s relevant… Hmm, the folder that Plex accesses is a mount point within the Plex Ubuntu VM that maps to an NFS share from a FreeNAS box. The share is mounted as /nfs/nas-videos. I just checked the permissions of that folder from the console and got this:

image

I checked the subtree and UID 1001 is listed throughout. However, checking the /etc/passwd file, there is no account that corresponds to that UID.

I perform folder management and permission delegation using Windows. There’s a user account with read permissions called NAS_Plex that has permissions for the root share and subtree, but I don’t see how that account is related to the Ubuntu VM - there’s certainly no reference to it in the passwd file.

Do you think this is related to the fact that it’s running from a VM, or is it more likely to be to do with permissions to the mounted network share?

The fact you’re running Linux, in a VM, on Windows.

From the technical perspective, this is a net performance loss.
I have no way of knowing or being able to support the underpinnings.

  1. Under the VM
  2. Hyper-v (Windows – which I do not use nor understand)
  3. CIFS shares most likely.

I do know, PMS does not work well in this configuration because of file locking.
It would not surprise me at all if this is the eventual root cause.

I also know hardware transcoding through this is impossible.

My advice to you is either run native Linux or native Windows.

Hi Chuck,

Sorry, I haven’t explained it properly. Let me try again.

I have a Hyper-V server. This isn’t ‘Windows’, it’s Hyper-V, which is just a hypervisor. The VM doesn’t care that it’s a VM, it’s just running Ubuntu Server. Running Ubuntu on Hyper-V is the same as running it on baremetal hardware as far as the VM is concerned.

The files reside on a FreeNAS box, which runs on FreeBSD. The Videos folder is shared via NFS, not CIFS. So as far as the Ubuntu mount-point is concerned this is the same as connecting to any Linux-native NFS share.

Most of the PCs in the house are Windows boxes, and I control access to files on the NAS using Active Directory. However, I’ve just realised that because the way that the Plex Ubuntu VM is connected to the folder via an NFS share, the Microsoft AD permissions settings are irrelevant - NFS doesn’t respect them.

To reiterate, even though my environment includes Windows clients, neither the VM nor the media files reside on or have anything to do with Windows.

Yes, there is no hardware transcoding (it’s disabled in settings), but generally that provides a lower quality result anyway. The server it’s running on has dual Xeon E5-2667v2 CPUs running at 4GHz, it has bucketloads of power on tap for transcoding. Almost everything runs at native resolution anyway - it’s running across a gigabit network to devices running everything at native 1080p, so I don’t know that there’s any conversion actually being performed.

What doesn’t make sense is the fact that Plex has been working fine like this for a couple of years, but a few months ago a new show wouldn’t work - none of the files would play through Plex. Since then I’ve seen it happen to about a dozen TV shows, while others are sometimes ok. This behaviour hasn’t affected any previously working files, but it’s occuring more and more frequently to new ones. All of these files, without exception, always play fine using any other method.

I think at this point it would be best to just treat this as Plex running on Ubuntu Server 16.04.6 LTS connecting to an NFS share and deal with those basics - there’s no point overcomplicating things by focussing on factors that are essentially irrelevant. If everything else appears to be fine then of course other factors must be taken into consideration, but we’re a long way from that being a relevant consideration.

I’d be interested to know if/how we could test permissions issues to one of the relevant folders… I’m thinking I could move one of the ‘problem’ files into a folder for a show I know to work fine and change its name to one of the existing files - if it’s a permission issue this test should work fine, as the file will have the same permission settings as the folder it’s residing in…

So I tried my test - I copied one of the files that wasn’t playing into the folder of another show that worked fine, removed one of the video files, renamed the copy of the problem file, removed the link in Plex and recreated it (by rescanning the library folder) and then Plex was able to successfully play the file. So not a codec issue at all, just a permission issue.

Then I tried creating new folders for the problematic videos and moving the files into the new folders, deleting the originals, then getting Plex to rescan them. Unfortunately that didn’t work. However, creating new folders, copying (instead of moving) the video files, then replacing the original folders with the new ones did work - Plex is now able to access and play these videos fine.

I’ve checked permission settings in both Windows and Linux - comparing the original folders with their new replacements, they appear identical. So I don’t think it’s as simple as a permission issue. There must be something about the way the folders have been created that resulted in them not registering with Plex correctly somehow. I’m not certain of the precise cause, but my workaround seems to have solved the issue nonetheless.

Thanks for your help Chuck, most appreciated.

When problems like this come up, it’s really helpful to bring them up right away. (future reference? ) Coming in a few months after the fact , through all the versions and database migrations with each version, can make diagnosis and repair difficult.

I would like to request we start collecting actual data to show what’s not happening.

  1. Settings - Server - General: DEBUG logging ON, VEROSE logging OFF
  2. Now start the playback of one problematic file.
  3. let it play for 30 seconds or until failure (whichever occurs first)
  4. Stop playback
  5. wait 30 seconds for logs to settle.
  6. Settings - Server - Troubleshooting - Download Logs
  7. Attach the ZIP file it gives you here with your next reply (drag, drop, allow to upload, reply)

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