Server Version#: 1.14.1.5488
Player Version#: different clients from remote users so not sure
Server is CentOS 7 running Plex via the Linuxserver.io docker.
I’ve searched this error in the forum and didn’t find anything useful for my issue.
First, in the ‘Plex Media Server.log’ (I also found the error in the .1.log also) if you search for ‘EAE timeout’ you will see ‘EAE timeout! EAE not running, or wrong folder? Could not read ‘/tmp/pms-1e60b49e-8edd-49ad-8639-59d52256870f/EasyAudioEncoder/Convert to WAV (to 8ch or less)/0jumfstu2mt6ie2ugnhwpa7y_10334-0-1.wav’’ occurring multiple times.
I have seen this happen with files with EAC3 5.1 audio and Dolby TrueHD 7.1 audio.
The threads I did find with this error are here:
The first two threads mention the iNotify limit being reached but I couldn’t find any error in the Plex Media Server log with the error and within Plex I only have about 1,500 directories total (I followed @ChuckPa’s one thread in the Linux tips & tricks section to verify how many directories I have).
The last thread mentions deleting the Codecs folder and then restarting the container (the post immediately after that the user just restarted the container). I deleted the folder and then actually restarted the server (I needed to do this anyway, which is why I didn’t just restart the container). This fixed the issue for a few hours until a couple of hours ago when I saw a user’s stream buffering and it was trying to transcode from EAC3 to AAC (I believe that was the target codec). The user that just restarted the container said that the issue also came back for them.
I’m not really sure what to do to permanently resolve this. I don’t know if it’s a Linuxserver.io docker issue or a Plex issue. I switched from a FreeNAS 9.3 install of PMS to this CentOS 7 server using Docker and I didn’t have this issue, as far as I am aware, on FreeNAS, so I don’t know if this is a Linux issue or if it happens on other OSes.
Let me know what else is needed aside from the included logs.
As I said in the beginning, search on ‘EAE timeout’ and you’ll find the error.
Once I increased the inotify limit and restarted Plex (and ensured that my drive that has the transcode directory on it has plenty of space), everything seemed to work just fine.
I’m not sure if the same will be true for you, but hopefully this will help.
Based on your response I’m pretty sure I know why I’m having the issue. Since you mentioned making sure the drive that has the transcode directory has enough space, I confirmed where that was located on the actual system (since it’s in a docker container) and that is actually low on space.
Turns out when I setup the system and let it do the auto partition, I didn’t realize that it only made the root partition to be 50 GB (out of a 500 GB SSD, ~465 GB available after formatting) and made the /home partition 399 GB (15 GB for the swap).
Now I’m going to deal with figuring out how to fix the issue of not having enough space. I’m going to work on shrinking the home partition and expanding the root partition, which seems like it’s going to be a bit of a pain but I’d rather do that because 50 GB seems to small for the root partition and I’m barely using any space for the home partition, so I’d rather reduce that by 50-100 GBs.
Again, thanks for your reply as that helped me look in what should be the correct directions. I can’t say for certain at this point but I have a good feeling when I increase the space that it should fix my issue.
Rather than attempting to resize the root and home partitions, you could also try moving the transcode directory to use the home partition. I’m not sure if that would be an option for you. I actually have my transcode pointed to slower spinning disks, but all of my configs for plex (and other docker containers) stored in a centralized directory on my ssd.
For me, I’m running Ubuntu with root and home sharing a partition and separate swap. I found the space issue by accident because I had a disk fail to mount that had data auto-loaded into it (which filled my root/home partition) and caused a number of weird transcoder and playback issues.
Maybe the Plex team could include a filesystem space check in the server logs to help users troubleshoot out of space issues since it is not obvious from checking logs.
I did think of moving the transcode directory to either the home partition or a different disk, but given that the root has like 6.8 GBs free, I preferred to get that increased if possible to avoid other possible issues.
On this system my home partition isn’t really going to be used, so decreasing that partition size and increasing the root partition was the preferred method for me. I actually did manage everything resized, so I’m good on that front.
I’ve done a few tests and it looks like my issue is resolved but I’ll let my remote users that were experiencing the issues know for them to check.
Thanks again for pointing me in the right direction on this.
Hopefully this thread will help someone in the future if they have this issue.
EDIT: To add, @jmlw’s suggestion did not resolve my issue. I still have users buffering when trying to play files with EAC3 audio and requiring transcoding. I have plenty of space in my transcode directory and I increased the iNotify table to what should be more than enough for a while (524288).
Edit 2: Turns out I needed to restart the server for this to resolve. Don’t know if increasing the partition needed that to fully be recognized or the iNotify table (I did do sysctl -p so unless that didn’t actually take it probably wasn’t the iNotify table).
Hopefully somebody else will be able to chime in with some suggestions or ideas on how to resolve this.
Ok. This is still giving me an issue.
I’ll upload new logs if I actually get a reply from someone that will be able to look at them to diagnose, @ChuckPa or @sa2000
The partition where my transcode folder is definitely has enough space now and I increased my iNotify table to 524288, which should be overkill in my instance.
So I’m at a loss as to what to do next because none of the other threads on this issue have any additional information. I could re-encode the EAC3 audio to regular AC3, but I’m not actually going to go through my library to do that as I shouldn’t have to.
First: Docker is not my area of expertise so please take this into consideration:
From the logs of 15 days ago:
Jan 19, 2019 19:01:18.306 [0x7f4ef33ff700] DEBUG - Completed: [192.168.1.243:38526] 200 GET /library/metadata/32669/theme/1547938640 (35 live) TLS GZIP 60ms 961176 bytes (pipelined: 1)
Jan 19, 2019 19:01:19.001 [0x7f4ea8ff3700] ERROR - [Transcoder] [truehd_eae @ 0x1e3fbc0] EAE timeout! EAE not running, or wrong folder? Could not read '/tmp/pms-1e60b49e-8edd-49ad-8639-59d52256870f/EasyAudioEncoder/Convert to WAV (to 8ch or less)/0jumfstu2mt6ie2ugnhwpa7y_10334-0-0.wav'
Jan 19, 2019 19:01:19.002 [0x7f4eaefff700] ERROR - [Transcoder] [truehd_eae @ 0x1e3fbc0] error reading output
Jan 19, 2019 19:01:19.003 [0x7f4eae7fe700] ERROR - [Transcoder] Error while decoding stream #0:3: Input/output error
Jan 19, 2019 19:01:19.005 [0x7f4ed63fe700] DEBUG - Transcoder: session 0jumfstu2mt6ie2ugnhwpa7y indicated fallback to software decoding
Given this in a Docker container, where is the container’s /tmp mapped to? Is it mapped to a network share? If so, file notification will not work. iNotify is useless.
If NFS, Posix locking (NFSv3) or NFSv4.1 is needed.
Thank you for replying even though Docker is not your area of expertise.
Given I am not an expertise in Docker as well, hopefully my answer makes sense.
In my docker-compose.yml file I am only mounting 2 volumes.
The first is /opt/appdata/plex:/config which is using the host location and mounting the Plex library location to the /config directory in the container.
The second is /mnt/pool/Plex:/media which is mounting my media to the /media directory in the container.
Those are the only 2 volume mounts I have defined. Based on what I can tell, the container’s /tmp is either not mapped anywhere and is just using the default directory on the host that the container uses. If that isn’t the case, then I would think it’s mapped to the hosts root directory as the size of the root in the container is the same size as the root of the host.
Once I have nobody streaming from me, I can try mapping the /tmp folder of the container to a location on the host, possibly /opt/appdata/plex/tmp:/tmp and see if that resolves the issue.
The only thing is that after restarting either the container or host, it looks to take a little bit before the failure occurs so I won’t have results right away.
Thanks again @ChuckPa and if you happen to know anybody (even a forum member) that has more expertise with Docker containers that could be pinged, that would be appreciated.
If you would like, to aide in the debug. the number of retained log files before rolling over can be increased. Default is 25 MB, If you doubled, it’s still only 50.
To do this:
With PMS stopped
Locate and edit the Preferencecs.xml;
Within the XML scope brackets, declare LogNumFiles=“10” (or 15 if you wish)
Save the file.
Start PMS
Now, PMS will give us a wider window for capturing and examing issues.
I made the switch to map the /tmp folder to a different location on the host so I want to see if that resolves the issue.
If it does, I’ll switch back to how it was, make the change you mentioned and ask my remote users to let me know when they start experiencing the issue again. Once they do that I will reproduce the issue on my end and upload the logs for you to look at.
Of course if my change doesn’t work I’ll also do what you suggested.
One quick question for you. Should I stop Plex and backup and remove the current PMS log and then reproduce the issue so it’s clean logs or does it matter? And I know you’ve given instructions before on supplying logs. Can you confirm that it was to reproduce the issue and then wait a minute and then grab the logs using the Download Logs button in the Settings -> Troubleshooting section?
THere’s no need to delete the logs and start again unless there is a major change. In this case, changing configuration / temp directory, It makes for a clear delineation so yes, let’s start fresh each configuration base.