ERROR - [Transcoder] [ac3_eae @ 0x2fd4f40] EAE timeout! EAE not running, or wrong folder ....

Plex Media Server NAS & Devices
61

Actually that only helps to kill the current encode, and skip to the next one.

The errors only happen for media with EAC3 audio codec.

62

I managed to fix my issue by increasing the inotify count on the host system ! Hooray !

63

Normally it would be easy to spot this from server debug logs captured after launch - if you have library auto update enabled in server settings, then it would add a notify entry for each directory and when limit is reached, an error would be logged

64

maybe indeed it would have shown in the logs, but it is very weird that the inotify limit has something to do with transcoding issuesā€¦

65

That is how the interface between the Transcoder/EasyAudioEncoder/Plex Media Server works. Notifications are used for file changes

66

Any updates on this? Iā€™m having the same issue with the official docker image. The inotify limit didnā€™t help, so Iā€™m now trying the tmp volume mount. Hopefully this works long-term.

67

such an issue is a local configuration issue and not a Plex Media Server bug

The debug log would show if there is some specific error beyond the normal case where it is to do with execute permissions / notify limit

68

I have to say I really disagree with you on this not being a PMS bug. My PMS was rebuilt completely from scratch in September and thus something, somewhere in the packaging of the container isnā€™t doing itā€™s job properly.

What appears to have resolved a very long running issue of needing to restart the container daily for me is the 777 fix to the binary for EasyAudioEncoder under the codecs folder. The pertinent log section is:

Mar 13, 2019 15:33:54.001 [0x7f36edfff700] ERROR - [Transcoder] [eac3_eae @ 0x34ef440] error reading output
Mar 13, 2019 15:33:54.002 [0x7f36f0fff700] ERROR - [Transcoder] Error while decoding stream #0:1: Input/output error
Mar 13, 2019 15:33:57.001 [0x7f36ebfff700] ERROR - [Transcoder] [eac3_eae @ 0x34ef440] EAE timeout! EAE not running, or wrong folder? Could not read '/tmp/pms-892e7e2c-510c-478a-bc76-07359384eac6/EasyAudioEncoder/Convert to WAV (to 8ch or less)/1c39e7ba-dea1-46a8-a36d-493813b57b34_961_359-0-981.wav'

Having narrowed this finally down to EAC audio I can now reliably reproduce this issue. Mapping /tmp and /transcode externally did squat. As did changing the inotify limits.

So my question is this. Why doesnā€™t the container startup script check and modify the permissions of itā€™s codec binaries as required? Seems like a bug to me.

2 Likes
69

You sir are a gentleman and a scholar. I had been dealing with that issue for so long and this fixed.

Tried googling the EAE timeout error and there are just sooo many results and none of the fixes worked for me, who would have thought it was a permissions issue. I donā€™t know how it happened in the first place (or whoā€™s fault it was), but Iā€™m happy it was resolved. Thanks!

70

CentOS User Here

My Centos 6, then 7, builds had the same problem. After 3 years of giving up and re-encoding to AAC, ā€œfs.inotify.max_user_watches=16384ā€ was the fix. I think this is the first time Iā€™ve directly played EAC3 (web/roku/etc) w/ Plex.

As previously suggested to change on live system:

sysctl fs.inotify.max_user_watches=16384

Restart Plex

Add ā€œfs.inotify.max_user_watches=16384ā€ (sans quotes) to /etc/sysctl.conf to keep it persistent.

No advice to offer for those still having the same issue after increasing ā€œfs.inotify.max_user_watchesā€

71

This fixed the issue for me, at least 775 to EasyAudioEncoder. Sloppy the ACL was messed up, but never the less now it workes again.

1 Like
72

I am encountering this issue. I have set fs.inotify.max_user_watches=524288 and I have mounted /transcode instead of allowing it to be internal to the container. I still encounter the same issues and I have to restart plex every day or so to correct.

73

Can you elaborate a little on this? My transcoder directory is local to the host of the container, but all my media is located on a NFS network share. Is there additional setup I have to do in my case?

74

Media on a network share does not benefit from User Watches unless they are being added to from the host side (NFS nor SMB propagate notification does not include iNotify due to the age of both protocols).

What happens when the transcode temp is on a network share is :slight_smile:

  1. Transcoder tells EAE where to write the file
  2. EAE opens and starts writing
  3. Transcoder, expecting to see the open() , doesnā€™t get one.
  4. This is where the logic breaks down, and thinks the EAE has died.
2 Likes
75

Moving the/tmp folder outside the docker container finally solved this one for me. I had done all the previous suggestions, but was still experiencing daily issues, and in frustation I was reading every single post on the subject, and finally @ChuckPaā€™s description above made me think of the temporary folder being used by the EAC3 codec.

2 Likes