I was just about to ask you to do that based on the errors in your logs. You might want to give the latest set of logs, I saw a lot of curl errors where Plex was trying to download/resolve addresses.
Here is the specific How-To for inotify.
Here you go:
(File removed)
Let me know which specific addresses it’s failing to resolve so that I can check my pihole DNS server if something’s getting blocked.
Right, that’s what I’ve been using as a guide. Although it specifically mentions that the default max is 8192 but I only have a total of 1369 folders in my media folders:
So I was wondering if that inotify issue can be causing this?
Is the transcode temp directory a local file system or a network mount?
Network mounts do not support the required file locking.
Depending on network share protocol, you might not see the changes for inotify to work properly.
The transcoder needs two features:
- Inotify slots (2 per transcode)
- lock() access to the audio file(s)
I did see your reply in past threads about that. The temp directory is local for both my Debian servers (ASRockk J5005-ITX and Intel NUC10). The media directory for the J5005 is also local but for the NUC the media directory is on a Synology NAS that is mounted in /mnt which shouldn’t be a problem with the transcoding. The problem happened on both systems and recreating the Codecs folder seemed to have fixed it, at least for now, but I still want to know why that is.
I would want to know why that is too.
The Codecs directory is read-only.
It implies the codecs were damaged somehow.
I forgot to mention that I migrated from using the LSIO docker container to installing PMS natively in Debian. After migrating the data folder, I only made sure that all folders and files were owned by plex:plex. Could that be the cause? I couldn’t think of any other.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
