Bumping again; this is continuing to be a pain point and anecdotally is getting to be more prevalent. At this point I’m restarting plex multiple times per day.
Bumping again as this continues to be a problem. @chrisallen anything else you can suggest?
I’ll need to reach out to a colleague as I’m not sure what is causing the issue. I run PMS myself in docker and have not had the issue you are experiencing. i wonder if something has changed on your system that causes inotify to run out of handles so EAE cannot see data provided to it from Plex Transcoder…
I would expect to see more issues in logs if inotify were running out of handles. Regardless, I did attempt to increase the max_user_watches limit from 8192 to 32768 and didn’t see any change.
I also wouldn’t expect restarting Plex Transcoder to fix the issue unless it’s holding onto an excessive number of handles.
Did another round of debugging tonight to confirm that inotify limits aren’t the problem. I dumped a list of all the processes with inotify handles using:
for foo in /proc/\*/fd/*; do readlink -f $foo; done |grep inotify |cut -d/ -f3 |xargs -I '{}' -- ps --no-headers -o '%p %U %a' -p '{}' |uniq -c |sort -n
The total number of open handles is low… 30-ish. But more importantly I can see:
1 23461 plex /usr/lib/plexmediaserver/Plex Transcoder -codec:0 h264 -codec:1 eac3_eae -eae_prefix:1 poplapbscsip4hmeilljx7kb_ -ss 0 -noaccurate_seek -analyzeduration 20000000 -probesize 20000000 -i /data/Videos/TV/<SNIP>.mkv -filter_complex [0:1] aresample=async=1:ocl='stereo':osr=48000[0] -map 0:0 -codec:0 copy -map [0] -metadata:s:1 language=eng -codec:1 aac -b:1 256k -f dash -seg_duration 5 -init_seg_name init-stream$RepresentationID$.m4s -media_seg_name chunk-stream$RepresentationID$-$Number%05d$.m4s -window_size 5 -delete_removed false -skip_to_segment 1 -time_delta 0.0625 -manifest_name http://127.0.0.1:32400/video/:/transcode/session/poplapbscsip4hmeilljx7kb/cd4cf45d-2876-4c91-97ac-a09fcb1690f3/manifest -avoid_negative_ts disabled -map_metadata -1 -map_chapters -1 dash -start_at_zero -copyts -vsync cfr -y -nostats -loglevel quiet -loglevel_plex error -progressurl http://127.0.0.1:32400/video/:/transcode/session/poplapbscsip4hmeilljx7kb/cd4cf45d-2876-4c91-97ac-a09fcb1690f3/progress
2 31096 plex Plex EAE Service
So both Plex Transcoder and EAE have a inotify handle.
Some additional things I’ve tried
- Earlier in the thread there were concerns about the plex processes running as
uuidd. This was just due to a uid conflict between the host machine and the container. However, I changed the uid for plex so that they no longer conflict. - Changed the transcode directory to map to a folder on the host side rather than use a docker volume.
- Fully destroyed the container/volumes/network and rebuilt them.
Any updates? This is still an on-going problem for me 
I haven’t had an issue since the permissions got fixed. Sucks you’re still having trouble.
@chrisallen as my last ditch effort, is there any debug version I can try to use?
Otherwise my next step is going to be to migrate plex out of a docker container and see if it persists.
I just hit this same bug. Took me a while to find this post. But once I renamed the folder I was able to play the video and the folder recreated itself ok.
Any idea what the cause of this is or when there will be a perm fix? I am new and only found it searching the log files. Other people could be pulling their hair out for weeks.
Do you need to have /tmp set both within the Plex app and the container settings? Or Either or? or just in the App?
Sorry I don’t have a debug version. Did you try moving out of the docker container and seeing if the issue persists?
So far I am not aware of any other users experiencing this issue other than yourself.
Moving it out of Docker has worked thus far. Strange too since it’s the same machine, same config, same library. ¯\_(ツ)_/¯
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
