EAC codec issues & iNotify still an issue?

Server Version#: 1.41.8.9834
Player Version#:

I’m still periodically running into issues when playing files remotely and transcoding. I suspect it’s an issue with EAC encoded files.

I’ve seen a good number of historical posts about this either being a case of deleting the files from inside the Codecs folder and letting Plex redownload them fresh, but also quite a bit about it being the 8192 limit with Linux inotify tables jamming up EAC playback if that table fills up.

Specifically @ChuckPa wrote some (as usual) excellent directions a few years ago to increase this limit:

However, I’ve read some other posts more recently that suggest newer versions of the kernel shouldn’t have this issue?

Since I’m running DSM 7.2.2 on a DS920+ would this inotify issue still be a possible culprit and thus increasing the inotify limit as per @ChuckPa may still be relevant?

Synology still has the issue.

the newer kernels have a variable value

count your folders (just as is done in FAQ16) if > 8192, add the configuration option and be done with it.

1 Like

I am having this same issue on TrueNAS. I turned off automatically monitor and still have issues both remote and local. With Roku and the Shield Pro.

@Brodieman37

Please do the following:

  1. Ensure DEBUG logging is enabled and VERBOSE logging is disabled.
  2. Restart PMS
  3. Do nothing for 3 minutes (startup sequences running)
  4. Grab server logs ZIP file
  5. Attach here please.

@ChuckPa

I was able to find a old TrueNAS post that pointed me to the issue. The TrueNAS Plex app was not able to rename the EAC3 codec folder after it unzipped it and had a “.tmp” at the end of the folder. Once I removed the “.tmp” EAC3 files were playable again. I am not focusing on why the Plex Docker app was not able to remove that.

Thanks!

As long as it’s solved, that’s good enough for me too.

Thanks for letting me know.

I will keep my eye on the unzipping which failed

1 Like

@ChuckPa

Thanks! I THINK it’s a TrueNAS Docker app issue but I am not 100%.

I saw these in the logs and it pointed me down a hole to the solution.

Aug 08, 2025 05:29:05.768 [140000482679608] INFO - [Req#41c39/Transcode/e064eb4a2f6efa27-com-plexapp-android] CodecManager: obtaining EAE

Aug 08, 2025 05:29:06.255 [140000482679608] ERROR - [Req#41c39/Transcode/e064eb4a2f6efa27-com-plexapp-android] Unzip: could not set executable bit on output file
Aug 08, 2025 05:29:06.255 [140000482679608] ERROR - [Req#41c39/Transcode/e064eb4a2f6efa27-com-plexapp-android] CodecManager: failed to extract zip

Aug 08, 2025 05:29:06.255 [140000482679608] ERROR - [Req#41c39/Transcode/e064eb4a2f6efa27-com-plexapp-android] Error configuring transcoder: Decoder install failed: eac3_eae

If you can get into the filesystem and go to where Plex keeps its files,
you should be able to get into the Codecs directory and start cleaning out where it failed (junk / temp files).. or just delete everything in there and let it start over.

Remember to stop PMS first.

@ChuckPa I can yes, the config dir is mapped. I deleted the codecs folder and every time it recreates it, it has the .tmp and cannot change it but I can manually.

can you please show me the ls -la listing of

  • Plex Media Server
  • Codecs (get the recursive list here please)

Something is wrong with permissions. I suspect parent dir.

@ChuckPa

sure you can use “apps” as owner?

@PunkleJones

This is a TrueNAS app with all permission that are supposed to be setup already. There is a workload that sets permissions when the container is launched as shown here. I realized that it’s likely a permissions issue I am just not sure what or how. I am also not sure, if I change those, if the permission workload will change them back after.

In one of the links I posted they talked about creating a Plex user in TrueNAS, but again, not sure why that is not in the docs and not part of the permissions workload. Trying to reach out on their forums as well.

Here is other information from the app.

@PunkleJones @ChuckPa

I did just notice that permissions for apps was “modify”, I changed it to “traverse”. I think that adds execute?

Edit. That did not allow the app to run

Edit 2! Changed permissions to that dataset for the Apps use to Full Control (to test). Still does not remove the .tmp from the codec (I renamed the folder to force Plex to recreate it). So for the Plex folder dataset the owner is apps and the apps user has full control. I will full admit Linux permissions confuse me, always have, but this seems like it should be able to rename that folder?

Edit3: I created the Plex user with 972 gave it full permission to the dataset recursively. Edited the app to run as that user and still cannot remove the .tmp from the codec. I am not going to deny that its permissions but I am out of ideas. I am not sure how the app can created the codec folder, when it’s deleted, but then be unable to rename a folder under it?

Newer used TrueNas or know much about it all tbh :face_with_hand_over_mouth:

Directory permissions should resolve to the 0755.
Linux permissions mode for directories: Execute == Traverse.
(you don’t execute a directory, you traverse it).

0 = no super user privileges
7 = Owner has Read, Write, Execute
5 = Group has Read, Execute
5 = Other (world) has Read, Execute

@ChuckPa I was on the Git for the TrueNAS Apps and he told me this if it help

Permissions container will only apply changes if the directory is empty. ie set initial permissions.
But Plex specifically also handles some permissions itself. But in this case it seems that the unzip program have issues setting those permissions. The container has all the needed capabilities to do so.

So its either the ACL type blocking this operation, or plex launches unzip in a way that loses the capability to set permissions (in this case the executable bit)

I’m setting up a PMS server on my TrueNAS Community Edition box.

PMS is loading media now (from the file server)

It will be ready by my morning (8 or so hours) .. it will run Scheduled Tasks here ina bit. (good timing)

Please check –

root@truenas:/mnt/pool/chuck# sysctl -a | grep inotify
fs.inotify.max_queued_events = 16384
fs.inotify.max_user_instances = 1024
fs.inotify.max_user_watches = 506503
user.max_inotify_instances = 1024
user.max_inotify_watches = 506503
root@truenas:/mnt/pool/chuck# 

Now count the number of directories (in total) you’re using for all media which PMS is monitoring