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.
