@ionblue FYI those look like my logs.
@ChuckPa the network issue really shouldn’t be a problem. I found the cause, and it was just because of a docker container on a different network was flapping. Is Plex really doing anything in response to this? The logs indicate that it’s aware nothing changed. Either way, this is fixed now.
As for the transcoder, /tmp/ is just a normal directory within the docker container, so it’s really just writing to a local disk.
Point is, it shouldn’t have been flapping. If Plex sees it, it has to rescan it.
As for the flapping, looks pretty lousy to me if a container is causing that much of a system-level disturbance.
As for what is there to fix? Unknown…
This is why I don’t use docker.
Glad you have it working.
@kevin.oconnor7 Well crap. I didn’t even notice that. For me I only have one other docker running and it’s on the same server. It’s pretty minor though. Ubooquity for my comics.
@ChuckPa so if this wasn’t from my logs, what the heck is causing my issues and only with files with TrueHD? Is that docker related? If it is, it’s the official one from Plex.
About the only thing else i could do is migrate back to my Mac Mini, but then all the files would still need to be on the server. This would likely cause other issues since network shares tend to drop off Mac’s with no good reason.
I’m hitting my head against a wall here.
I should clarify that EAE issues still persist. I only got rid of the log spam from the network changes.
Thanks. Guess I’ll just sit tight and hope for the best. And use Infuse Pro in the meantime.
Hey @kevin.oconnor7 and @ionblue I’ll be available tomorrow to resume investigating this. In the mean time could you try running an older version of PMS? Since you are both using Docker (forgive me if I got this incorrect) you can change the Docker path from
plexinc/pms-docker to plexinc/pms-docker:1.16.6.1592-b9d49bdb7
This will downgrade you back to 1.16.6
If you still have transcoder issues then something other than our transcoder update is affecting your TrueHD decoding
Thank you for your patience 
Thanks. I’ll give this a try in the morning and will report what I find.
The one thing I don’t like about PMS in a docker is that I have no idea if the thing updates on its own after a restart. This issue popped up after I was away for a week and I had the server off. Anyway…
Thanks again. Will let you know.
I forgot I could test this on my iPad while my wife and I are watching something else on Netflix. 
So bad news… the same thing happens on this version. Or at least that’s what I’m assuming. I downgraded, immediately launched a 1080p file that has TrueHD which happens to be The Matrix, and it failed. Then I launched another movie that is DTS, Deadpool, and it started up after the drive spun up. And then I tried The Matrix again and still no joy.
I can upload the logs from this if you like, but I figure it’s much the same.
One thing I should mention is that I think, and I stress think, that I got an update notification on the PMS docker recently. I don’t recall seeing those for before. I usually see an update is available in the forums and I restart the docker to get it in play. So this may be nothing about nothing.
Correct me if I’m wrong, but on iPadOS the server would definitely be transcoding DTS just like it would TrueHD. Right?
@chrisallen I’ll try that and get report back later.
For now I just had it reproduce again. I’ve seen previous threads about EAE issues and I’ve tried to see if any of the root causes in those threads are the case here. Here’s what I’ve found:
root@plex:/# ls -la /config/Library/Application\ Support/Plex\ Media\ Server/Codecs/EasyAudioEncoder-eae-69c1
de6-41-linux-x86_64/
total 40
drwxr-xr-x 3 uuidd plex 3 Sep 25 00:45 .
drwxr-xr-x 4 uuidd plex 5 Sep 25 00:45 ..
drwxr-xr-x 2 uuidd plex 3 Sep 25 00:45 EasyAudioEncoder
So the PMS is complaining about a missing wav file, which is indeed missing, hence the I/O error. There are a few .ec3 files, but that’s it.
Finally, if I pkill "Plex EAE Service" and retry playing the file, it works! So something is going wrong with that service over time that’s not being captured in the normal plex logs. I tried to dig around a bit but couldn’t find logs for this service, do they exist somewhere?
sorry if this is immensely ignorant, but why is the user:group
uuidd:plex
?
I was going to ask the same thing. That’s inside the docker so maybe that’s normal.
Well that’s progress I would say! Appreciate you continuing to dig around. Hopefully this helps get it fixed.
Not 100% sure. I do explicitly set the UID of the plex user to 105, and indeed the plex user in the container does have that uid:
$ id -u plex
105
But it turns out user uuidd also has that id:
$ id -u uuidd
105
Which is a bit wonky (having two users with the same uid, but it should be rather benign. I should adjust the uid to see if I can get these untangled, but that’s a project for another day.
The permissions are consistent when things are working and not working.
Considering y’all are getting permission errors 
You can call 105 the user plex, but user IDs are reserved and not mapped.
It’s owned by the user that’s written in /etc/passwd, as a user named uuidd.
I was sort of asking rhetorically based on a bit of reading, but I lost the link
and don’t understand dockers enough to be sure of much.
I did register that, but hey, what else do we have that’s obvious?
Agreed it’s weird, but it’s not the culprit. Restarting the Plex EAE Service shouldn’t magically fix a permissions issue.
We could dig deeper into what user owned the process, versus what user you then ran it as.
I haven’t done anything with regard to permissions. unRAID has its own permissions and the docker does as well. I assume the docker sets up whatever permissions it needs when run. I ran the utility that sets docker safe permissions at the beginning of this mess, but that only touches files not in the appdata space.
In my mind, I can’t see how one type of audio causes the stream to fail and another one streams with no issues. And both should be getting transcoded. If one works then all should work if it’s a permissions thing.
@ionblue the EAE service is responsible for truehd and eac3 decoding, and eac3 encoding. So it is entirely possibly that there is some issue that occurs in some rare cases that it stops converting audio data after some time. I say rare, be cause I run the same setup as you do and have never run into this issue. based on usage metrics docker is also a very popular platform so this error is not that common.
@ionblueI am happy to help via a TeamViewer session (please PM the details) if you would like to work together to try and understand why this issue is occurring?
Sure. We can do that. I’ll pm you.
I guess what I don’t get is why out of the blue this started happening with everything being rock solid before. And it sounds like something I certainly couldn’t have done anything to cause.
Hey All, I have a quick teamviewer session with @ionblue and it turns out something somehow had changed the permissions on the codecs within the codecs directory to 644 which was preventing EasyAudioEncoder from launching as it was no longer marked as “executable”.
By correcting the permissions (or deleting the “EasyAudioEncoder” folders in the Codecs directory so it gets downloaded again) the issue was resolved the next time playback was attempted.
I’ll raise a ticket with engineering to see if we can correct permissions, if we find they have changed since we downloaded the codec (permissions are correct when we downloaded the codec)
