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

server-docker

#16

Just so everyone is aware, this issue is still occurring on version 1.9.7.4460. I'm running the official Plex docker container on Ubuntu 17.10. I can't sync anything to my mobile devices that has an EAC3 5.1 audio stream.

Logs attached.

I guess I'll try to mount /tmp somewhere on my local file system when I get home from vacation in a week and report back if it works.


#17

@Mogul345 said:
Just so everyone is aware, this issue is still occurring on version 1.9.7.4460. I'm running the official Plex docker container on Ubuntu 17.10. I can't sync anything to my mobile devices that has an EAC3 5.1 audio stream.

Logs attached.

I guess I'll try to mount /tmp somewhere on my local file system when I get home from vacation in a week and report back if it works.

Is eae process running?

Nov 26, 2017 22:21:23.000 [0x7f16837fb700] ERROR - [Transcoder] [eac3_eae @ 0x18ac180] EAE timeout! EAE not running, or wrong folder? Could not read '/tmp/pms-8f54e2af-71f7-47b2-b9d3-e38a3d987449/EasyAudioEncoder/Convert to WAV (to 8ch or less)/a15c484b-ac3f-4da7-a2fc-e42836700251_7570-1-0.wav'

Best to get logs and test it after restart - that way other issues like number of watched directories could be checked for being over the limit - also can see the attempt to start eae


#18

@sa2000 said:

Is eae process running?

Nov 26, 2017 22:21:23.000 [0x7f16837fb700] ERROR - [Transcoder] [eac3_eae @ 0x18ac180] EAE timeout! EAE not running, or wrong folder? Could not read '/tmp/pms-8f54e2af-71f7-47b2-b9d3-e38a3d987449/EasyAudioEncoder/Convert to WAV (to 8ch or less)/a15c484b-ac3f-4da7-a2fc-e42836700251_7570-1-0.wav'

Best to get logs and test it after restart - that way other issues like number of watched directories could be checked for being over the limit - also can see the attempt to start eae

So I didn't think about checking for the EAE process before updating the docker image and replacing the container (since I was out of date). After updating, I'm running v1.10.1.4561.

Everything seems to have started up correctly. I tested a couple files with EAC3 and they worked. And in htop I see "Plex EAE Service" running. So that's weird.

I'm still attaching the new log from restart. Guidance as to how to figure out if I'm over the file watch limit (even though I do not think I am) would be helpful. Also, I'm a linux noob, any help in detecting if the EAE Service is dead and making the container auto-restart would be great, in case this gets flaky. The behavior manifests itself to the roku client as getting stuck at 13% buffering, so if that happens again I'll check to see if the EAE Service is running to see if I can repro this somehow.


#19

@Mogul345 said:

@sa2000 said:

Is eae process running?

Nov 26, 2017 22:21:23.000 [0x7f16837fb700] ERROR - [Transcoder] [eac3_eae @ 0x18ac180] EAE timeout! EAE not running, or wrong folder? Could not read '/tmp/pms-8f54e2af-71f7-47b2-b9d3-e38a3d987449/EasyAudioEncoder/Convert to WAV (to 8ch or less)/a15c484b-ac3f-4da7-a2fc-e42836700251_7570-1-0.wav'

Best to get logs and test it after restart - that way other issues like number of watched directories could be checked for being over the limit - also can see the attempt to start eae

So I didn't think about checking for the EAE process before updating the docker image and replacing the container (since I was out of date). After updating, I'm running v1.10.1.4561.

Everything seems to have started up correctly. I tested a couple files with EAC3 and they worked. And in htop I see "Plex EAE Service" running. So that's weird.

I'm still attaching the new log from restart. Guidance as to how to figure out if I'm over the file watch limit (even though I do not think I am) would be helpful. Also, I'm a linux noob, any help in detecting if the EAE Service is dead and making the container auto-restart would be great, in case this gets flaky. The behavior manifests itself to the roku client as getting stuck at 13% buffering, so if that happens again I'll check to see if the EAE Service is running to see if I can repro this somehow.

If there is a problem with the transcoder starting then the roku 13% may show. Would need logs for that and when it is arising - perhaps with logs from both sides - PMS and Roku app

With regards to the notifier system limit - that should not be the case for you as you appear not to have automatic library updates enabled

Dec 07, 2017 18:55:55.152 [0x7f92f5ffe700] INFO - LibraryUpdateManager path watching is disabled


#20

Ok, it happened again today. Tried to watch a .mkv with EAC3 5.1 using my Roku and it got stuck at 13%.

I checked in htop and the Plex EAE Service is running. Log was again full of errors about EAE timeout errors, and unable to read a .wav file in the /tmp directory.

@sa2000 - Attached are the PMS and Roku app logs.

After I collected the logs, I restarted the container, and it started working again. Weird!


#21

@Mogul345 said:
Ok, it happened again today. Tried to watch a .mkv with EAC3 5.1 using my Roku and it got stuck at 13%.

I checked in htop and the Plex EAE Service is running. Log was again full of errors about EAE timeout errors, and unable to read a .wav file in the /tmp directory.

@sa2000 - Attached are the PMS and Roku app logs.

After I collected the logs, I restarted the container, and it started working again. Weird!

Will have a look at the logs - but may be you do not have an installation as per the documented setup.

Just noticed you have tcp port 32401 for local network IP - how did that happen ?
192.168.1.230:32401
Are you using two routes to the server?
local ports 32400 and 32401 are reserved for use by plex media server

Can you please check your setup and make sure it is a setup as per the guidelines here
https://github.com/plexinc/pms-docker/blob/master/README.md


#22

With regards to EAE - when you do the streaming that needs EAE for audio - can you see if the directories are actually being written to and files being created by the EAE process

The directory structure would be below
/tmp/pms-7ffc530d-1e2c-446e-8db7-4f33ca8e8ded/EasyAudioEncoder/
eg

/tmp/pms-7ffc530d-1e2c-446e-8db7-4f33ca8e8ded/EasyAudioEncoder/Convert to WAV (to 8ch or less)/8abb22c9cb126688832b0734995d6e8a_25754-1-0.wav

This is an example - it may be different subdirectory below EasyAudioEncoder

and is /tmp accessible to the docker process ?


#23

I'm running a multi-server environment right now, as I have my original PMS install on my windows machine running alongside my PMS install in docker that is having the EAE issue. The windows PMS server is running on 32400 public, so for my docker install, I've set the public port to 32401.

According to the section about manual port forwards in the Troubleshooting Remote Access guide, this should be a valid external port to use. The internal port should still be set to 32400. You can check me, here's the command I use to create my docker container:

docker run --restart=always \
        -d \
        --name plex \
        -p 32401:32400/tcp \
        -p 3005:3005/tcp \
        -p 8324:8324/tcp \
        -p 32469:32469/tcp \
        -p 1900:1900/udp \
        -p 32410:32410/udp \
        -p 32412:32412/udp \
        -p 32413:32413/udp \
        -p 32414:32414/udp \
        -e TZ="America/Los_Angeles" \
        -e PLEX_CLAIM=$CLAIMTOKEN \
        -e ADVERTISE_IP="http://192.168.1.230:32401/" \
        -e PLEX_GID=$GROUPID \
        -e PLEX_UID=$USERID \
        -h DOCKER-PLEX \
        -v $CONFIGDIR:/config \
        -v $TRANSCODEDIR:/transcode \
        -v /mnt/data:/data \
        plexinc/pms-docker:plexpass

I am a docker newb, but if I understand how docker networking works, the line -p 32401:32400/tcp should be the equivalent of mapping the external port 32401 to the internal port 32400 in the port forwarding documentation. On my router, I have 32401 forwarded to my docker host (which has a static IP set to 192.168.1.230). I'm manually setting my external port to 32401 in PMS settings as well.

Is this not a valid setup? Do I have to make my router map 32401 -> 32400 on my docker host, and then map 32400 into 32400 on the container?


#24

You have misread the documentation

Two errors above

-p 32401:32400/tcp \

and

-e ADVERTISE_IP="http://192.168.1.230:32401/"

These should be

-p 32400:32400/tcp \

and

-e ADVERTISE_IP="http://192.168.1.230:32400/"

and separately from this

If you wish your Plex Media Server to be accessible outside of your home network, you must manually setup port forwarding on your router to forward to the ADVERTISE_IP specified above. By default you can forward port 32400, but if you choose to use a different external port, be sure you configure this in Plex Media Server's Remote Access settings. With this type of docker networking, the Plex Media Server is essentially behind two routers and it cannot automatically setup port forwarding on its own.

So in your router public / wan port 32401 is port forwarded to port 32400 on 192.168.1.230
(note some very basic routers do not allow you to have different wan port from lan port - if this is so, you need to look for alternative router)
and in Remote Access server setting, tick manually specify port and enter 32401 as the public port


#25

Roger. For simplicity's sake, I just fully decommissioned my old server, created a new container using the updated the docker run command as you indicated, and updated the port forward in my router to 32400 external -> 32400 internal.

After doing this, I managed to break things one more time by playing videos with EAC3 audio streams (last night, I figured out I could reliably break things by playing a video with an EAC3 audio stream, and seeking after play started. Once the Roku got stuck at 13%, the whole server is down, and no client would be able to connect to it until the container was restarted). I was tailing the server log at the time, though, and the EAE timeout error wasn't occuring. So I restarted the container and have tried to break it again, and haven't been successful. So for now, I guess I'll call this fixed. Thanks for the help @sa2000.


#26

Ok @sa2000 it started happening again today. Here's the command I used to run the container:

docker run --restart=always \
    -d \
    --name plex \
    -p 32400:32400/tcp \
    -p 3005:3005/tcp \
    -p 8324:8324/tcp \
    -p 32469:32469/tcp \
    -p 1900:1900/udp \
    -p 32410:32410/udp \
    -p 32412:32412/udp \
    -p 32413:32413/udp \
    -p 32414:32414/udp \
    -e TZ="America/Los_Angeles" \
    -e PLEX_CLAIM=$CLAIMTOKEN \
    -e ADVERTISE_IP="http://192.168.1.230:32400/" \
    -e PLEX_GID=$GROUPID \
    -e PLEX_UID=$USERID \
    -h DOCKER-PLEX \
    -v $CONFIGDIR:/config \
    -v $TRANSCODEDIR:/transcode \
    -v /mnt/data:/data \
    plexinc/pms-docker:plexpass

Attached is the PMS logs. I didn't get the Roku logs this time. Restarting the container fixed everything, as usual. I checked in htop and the Plex EAE Service was running.


#27

@sa2000 said:
With regards to EAE - when you do the streaming that needs EAE for audio - can you see if the directories are actually being written to and files being created by the EAE process

The directory structure would be below
/tmp/pms-7ffc530d-1e2c-446e-8db7-4f33ca8e8ded/EasyAudioEncoder/
eg

/tmp/pms-7ffc530d-1e2c-446e-8db7-4f33ca8e8ded/EasyAudioEncoder/Convert to WAV (to 8ch or less)/8abb22c9cb126688832b0734995d6e8a_25754-1-0.wav

This is an example - it may be different subdirectory below EasyAudioEncoder

and is /tmp accessible to the docker process ?

Somehow I missed this post, sorry. I am not binding my host's /tmp dir to the containers /tmp dir. But I did go into the container and I saw that inside the containers filesystem there is a /tmp dir, and I did see that there were some dirs there for EasyAudioEncoder, following the pattern you mention above. Next time it happens I'll get into the container again and see if the failing file is really there or not.

UPDATE: It happened again, and this time I went into the container and checked out the filesystem. I can confirm that the directory structure was there, but the .wav file was not. So it's as if it can't write the file.

Could this be happening b/c the temporary files are being written inside the container's filesystem rather than on the host directly?


#28

I had to bind my /tmp to a directory outside of the container to get my eac
to work reliably. Not sure how the overlay filesystem in the container
causes this but confirmed.


#29

After it happened again, I bound /tmp to the same directory I bind /transcode to.

Looking at the plex logs, I wonder why the value for the EAE_ROOT var is set to /tmp in the first place. Why isn't it in the same directory used for transcoding? And I wonder if we can override that somehow?


#30

@Mogul345 said:
After it happened again, I bound /tmp to the same directory I bind /transcode to.

Looking at the plex logs, I wonder why the value for the EAE_ROOT var is set to /tmp in the first place. Why isn't it in the same directory used for transcoding? And I wonder if we can override that somehow?

I believe it was set differently for EAE because of relying on iNotify notifications for EAE to work and with /tmp it is more likely that this would be supported


#31

So mounting /tmp to the same transcode directory on my host seems to have helped. I've been up 2 days without issue.

Again, I'm a docker newb here. But regardless of this problem, shouldn't we always being binding /tmp to the transcode directory on the host? Audio files aren't exactly small, and aren't you supposed to be writing data in bind points, not in the container filesystem? Why would it make sense to transcode audio in the container, but video outside it?


#32

You are 100% correct. Just doesn't make sense. I had originally assumed
that eac would honor the transcode directory setting. When I ran in to this
issue and discovered the use of tmp I was a bit baffled. A lot of times we
will bind tmp to a host scratch space with docker (but not by default).

I'm guessing this somehow works for Plex in their Plex cloud use and that's
why it is this way (but just speculation on my part).


#33

FWIW: I was having a similar issue with the official PlexMediaServer - unRAID docker.

ERROR - [Transcoder] [eac3_eae @ 0x149f9e0] EAE timeout! EAE not running, or wrong folder? Could not read '/tmp/pms-61b92191-10d4-442c-8e76-fa679ed12790/EasyAudioEncoder/Convert to WAV (to 8ch or less)/iqwqc5rj3jdml3mehndz5myo_7489-1-0.wav'

Turns out is was an issue with _execute _ permissions on the EasyAudioEncoder file where my plex appdate resides.

Find EasyAudioEncoder in your Plex directory using a terminal/PuTTY.. In my case, the location was:

/mnt/user/appdata/PlexMediaServer/Library/Application Support/Plex Media Server/Codecs/EasyAudioEncoder-141-linux-ubuntu-x86_64/EasyAudioEncoder

Using "ls -lah" command to list contents of directory, I found that EasyAudioEncoder was read/write only (rw-rw-rw-):

root@Maximus:/mnt/user/appdata/PlexMediaServer/Library/Application Support/Plex Media Server/Codecs/EasyAudioEncoder-141-linux-ubuntu-x86_64/EasyAudioEncoder# ls -lah
total 2.8M
drwxrwxrwx 1 nobody users 32 Jan 15 16:45 ./
drwxrwxrwx 1 nobody users 32 Jan 15 16:45 ../
-rw-rw-rw- 1 nobody users 2.8M Jan 15 16:45 EasyAudioEncoder

Enter the following command to give the file execute permissions:

chmod 777 EasyAudioEncoder

Permissions now changed to rwxrwxrwx:

root@Maximus:/mnt/user/appdata/PlexMediaServer/Library/Application Support/Plex Media Server/Codecs/EasyAudioEncoder-141-linux-ubuntu-x86_64/EasyAudioEncoder# ls -lah
total 2.8M
drwxrwxrwx 1 nobody users 32 Jan 15 16:45 ./
drwxrwxrwx 1 nobody users 32 Jan 15 16:45 ../
-rwxrwxrwx 1 nobody users 2.8M Jan 15 16:45 EasyAudioEncoder

Now everything is working again!! This fix could have been just specific to my situation, so YMMV, but I wanted to share it in case anyone else has been banging their head against a wall like me.


#34

Thanks, this solved my docker issue as well.
My symptoms in case it helps someone else:
playback of certain files (I now assume EAC encoded files) would fail, but only on specific client applications. It would fail on Firefox, Chrome, & Amazon Firestick, but would not fail on a Roku Ultra.

Thanks for the insightful tip.

@bobbykarate said:
FWIW: I was having a similar issue with the official PlexMediaServer - unRAID docker.

ERROR - [Transcoder] [eac3_eae @ 0x149f9e0] EAE timeout! EAE not running, or wrong folder? Could not read '/tmp/pms-61b92191-10d4-442c-8e76-fa679ed12790/EasyAudioEncoder/Convert to WAV (to 8ch or less)/iqwqc5rj3jdml3mehndz5myo_7489-1-0.wav'

Turns out is was an issue with _execute _ permissions on the EasyAudioEncoder file where my plex appdate resides.

Find EasyAudioEncoder in your Plex directory using a terminal/PuTTY.. In my case, the location was:

/mnt/user/appdata/PlexMediaServer/Library/Application Support/Plex Media Server/Codecs/EasyAudioEncoder-141-linux-ubuntu-x86_64/EasyAudioEncoder

Using "ls -lah" command to list contents of directory, I found that EasyAudioEncoder was read/write only (rw-rw-rw-):

root@Maximus:/mnt/user/appdata/PlexMediaServer/Library/Application Support/Plex Media Server/Codecs/EasyAudioEncoder-141-linux-ubuntu-x86_64/EasyAudioEncoder# ls -lah
total 2.8M
drwxrwxrwx 1 nobody users 32 Jan 15 16:45 ./
drwxrwxrwx 1 nobody users 32 Jan 15 16:45 ../
-rw-rw-rw- 1 nobody users 2.8M Jan 15 16:45 EasyAudioEncoder

Enter the following command to give the file execute permissions:

chmod 777 EasyAudioEncoder

Permissions now changed to rwxrwxrwx:

root@Maximus:/mnt/user/appdata/PlexMediaServer/Library/Application Support/Plex Media Server/Codecs/EasyAudioEncoder-141-linux-ubuntu-x86_64/EasyAudioEncoder# ls -lah
total 2.8M
drwxrwxrwx 1 nobody users 32 Jan 15 16:45 ./
drwxrwxrwx 1 nobody users 32 Jan 15 16:45 ../
-rwxrwxrwx 1 nobody users 2.8M Jan 15 16:45 EasyAudioEncoder

Now everything is working again!! This fix could have been just specific to my situation, so YMMV, but I wanted to share it in case anyone else has been banging their head against a wall like me.


#35

@bobbykarate said:
chmod 777 EasyAudioEncoder

Linux Plex Media Server (not docker) running Version 1.11.1.4768 and I had the same problem and this worked for me. Thank you!