dark_slayer

supervisord.log hoping this attached properly

Thinking I’ve got this same issue. On 6.12.2, no zerotier, no tailscale, bridged network mode, pia user. Logs get to starting webui and successfully start just can’t access webui from any browser. The arr dockers can still access/use deluge. Will upload logs tonight

Hey Binhex, First - Thanks for all the great dockers you maintain for the community. Really top notch Sonarr is setup and working very well for me for quite sometime now. However this past couple of weeks I started to notice some strange behavior and I can't narrow it down to anything in particular in the logs. I have a screenshot here of my recent logs, and it looks like for some reason Sonarr just stopped everything on Tuesday night. Today (Thursday) I went to check why my Wednesday night shows never showed up, and I could not access the webui. I restarted the docker from the unraid menu, and everything returned to normal and it queued up my past episodes. I couldn't see anything in the log. This happened once last week as well. Is there anything else I can do to capture what is going on here? System - Sonarr.pdf

Sorry, I realize this is an old thread. I'm new to unraid, and enjoying the massive file structure conversion so far ... it is definitely worthwhile in the end This statement about "missing the point" by having a docker use UNC paths makes sense from a logical standpoint. That being said, peek behind the curtain at Plex and you'll find an annoyance that could easily be sidestepped if only the docker would allow for UNC paths like other versions of Plex The annoyance is how Plex "serves" when choosing transcode/stream/play. If you have a client requesting a media file from the docker, and the docker has (at the endpoint after translation) assigned that path to something along the lines of /mnt/disk/movies/etc(year)/etc(year).ext --> then your playback app (Plex) is going to take a stroll out to the network and say "I can't access /mnt" so please stream this file to me, oh mighty plex docker. That results in the file being cut-up by the docker and served out across the network. If you have a beefy server with plenty of disk io for the container or do something clever with where the docker chooses to "cut-up" the movie then there is never any resource issue. Note this is essentially the same thing as transcoding, but the difference is there is much less CPU overhead since it is only choosing to break up the file as opposed to encoding it on the fly. If you lower down the "allowed" bitrate on the client it will do the same thing, but request your CPU to encode small bits of the source file then begin serving them to the client. Higher bitrates and "original quality" settings on the client will not get around this issue if the playback client cannot directly access the file it is playing. The only way around this is to have a library with UNC paths that the brainless plex "clients" can see Also, FWIW, pointing your plex libraries to a large user share would be a very streamlined way to setup plex