Docker

[hooray4me 52]

question, linuxserver has published 4.7.8 container https://hub.docker.com/r/linuxserver/emby/tags but the offical emby repo has not. https://hub.docker.com/r/emby/embyserver/tags ...

Is that just a timing thing or are there issues with 4.7.8 ?

[dafthonk 0]

The beta tag of emby server on docker seems to be out of sync with the most recent version. The hash for the tag continues to match that of 4.8.0.17 and does not contain beta version 4.8.0.19 though it has been pushed very recently.

[Luke 37060]

18 hours ago, dafthonk said:

The beta tag of emby server on docker seems to be out of sync with the most recent version. The hash for the tag continues to match that of 4.8.0.17 and does not contain beta version 4.8.0.19 though it has been pushed very recently.

Hi, it just wasn't up yet at the time. Thanks.

[raudraido 43]

emby/embyserver:beta is still 0.17

Edited November 21, 2022 by raudraido

[NeoMatrix 3]

Just a generic question: using docker : lscr.io/linuxserver/emby:latest

Moving setup to new server and I have initiated the first scan.

Is it normal to only use one core when scanning for new content? #Curious

Thanks!

[Luke 37060]

3 hours ago, NeoMatrix said:

Just a generic question: using docker : lscr.io/linuxserver/emby:latest

Moving setup to new server and I have initiated the first scan.

Is it normal to only use one core when scanning for new content? #Curious

Thanks!

Hi, some parts of the scan, yes, although it will be getting faster in the upcoming 4.8 release.

[sandro_rocha_1982 1]

Good Morning. I installed OMV and in it, MergerFS, to merge two disks (sdb and sdc). When I install Emby via Docker and indicate the folder located in the MergerFS pool as the location of the Emby library, the program does not work. I need to indicate a folder outside the pool (in sdb or sdc). is there any way to resolve this? I searched the OMV forum but the most they did was mock my doubts. And I couldn't find support for Docker or MergerFS. Maybe you had any tips on how to indicate a folder inside the MergerFS pool as the location of the Emby library via Docker.

ps: installing Emby via deb file, doesn't work either. And in this case it's worse because Emby doesn't seem to get along very well with MergerFS and I can't change any folder locations.

[Q-Droid 642]

A few things about MergerFS - mount options, permissions and general usage.  I've researched MergerFS and might decide to use it but not sure if I want to put in the effort yet.

Mount options - allow_other: A libfuse option which allows users besides the one which ran mergerfs to see the filesystem. This is required for most use-cases.

Permissions - The underlying FS ownership and permissions still apply so make sure those are correct for Emby.

General usage - MergerFS (FUSE) doesn't support inotify (kernel) so the Real Time Monitoring (RTM) facility will not work for Emby. It might be better overall, and what I was planning,  to  use the native (underlying) paths for the libraries in Emby to preserve RTM then reference the MergerFS volume(s) when maintaining files and media outside of Emby to enforce the policies. This also means using a tree layout and path preservation policies that don't scatter files and directories too much so that Emby can find things where it expects.

Adding Docker to the mix should be fine as long as your volume mappings are correct.

[Sandro1982 0]

13 hours ago, Q-Droid said:

A few things about MergerFS - mount options, permissions and general usage.  I've researched MergerFS and might decide to use it but not sure if I want to put in the effort yet.

Mount options - allow_other: A libfuse option which allows users besides the one which ran mergerfs to see the filesystem. This is required for most use-cases.

Permissions - The underlying FS ownership and permissions still apply so make sure those are correct for Emby.

General usage - MergerFS (FUSE) doesn't support inotify (kernel) so the Real Time Monitoring (RTM) facility will not work for Emby. It might be better overall, and what I was planning,  to  use the native (underlying) paths for the libraries in Emby to preserve RTM then reference the MergerFS volume(s) when maintaining files and media outside of Emby to enforce the policies. This also means using a tree layout and path preservation policies that don't scatter files and directories too much so that Emby can find things where it expects.

Adding Docker to the mix should be fine as long as your volume mappings are correct.

I plan to use six or seven discs for my movies and tv shows. In that case the best option, to keep rtm working, would be to create the folders on each disk, point them to Emby and use the MergerFS mount point just to handle the files? Sounds like a lot of work to me and a recipe for messing things up. Maybe, if it's possible, having Emby scan the libraries from time to time is a better option, in my case. allow_other is already in the mountpoint settings and the permissions seem ok to me. I created a user just to work with docker containers and he has access to all the folders that Emby uses. 

[Q-Droid 642]

51 minutes ago, Sandro1982 said:

I plan to use six or seven discs for my movies and tv shows. In that case the best option, to keep rtm working, would be to create the folders on each disk, point them to Emby and use the MergerFS mount point just to handle the files? Sounds like a lot of work to me and a recipe for messing things up. Maybe, if it's possible, having Emby scan the libraries from time to time is a better option, in my case. allow_other is already in the mountpoint settings and the permissions seem ok to me. I created a user just to work with docker containers and he has access to all the folders that Emby uses. 

Basically yes, it does take some extra work though it should be a one time thing on setup and when you add more disks. Adding media to the MergerFS pool should distribute the directories and files to drives based on the policies used so it might take some tweaking of the policies for the results you want. But if you don't want the overhead and RTM is less important then scheduled library scans will also find new media just not as quickly.

If the user running Emby in the container is the same one that already has permissions to the pooled trees then I don't see why it wouldn't work. I think one restriction is that the container config should not be mapped to the pool but to a regular FS path instead. Also make sure that the Emby runtime user has access to all of the paths on all of the library drives. This means at every directory level not just the final directory.

 

[DaanSVK 0]

hi there, 

 

is there a way to kill a rogue stream via the docker console? How would I go about doing that? 

[amateurgod 26]

does anyone know how i can increase the 

max_user_watches

max_user_instances

For the docker container? i have increased these on the host OS but they don't seem to be taking affect inside of docker too?

[Q-Droid 642]

What OS and which container image? The docker container is running in the same kernel so those settings and values should be inherited.

[amateurgod 26]

I'm running Ubuntu server 22.04 and the docker image is the official emby image 

[Q-Droid 642]

Are you getting errors in Emby and can you attach a log?

What are your current values for fs.inotify.max_user_watches and fs.inotify.max_user_instances?

Did you restart after making the changes?

[amateurgod 26]

3 hours ago, Q-Droid said:

Are you getting errors in Emby and can you attach a log?

What are your current values for fs.inotify.max_user_watches and fs.inotify.max_user_instances?

Did you restart after making the changes?

No errors in the logs but its only detecting new episodes that are added when a library scan is ran, however when i was running emby on baremetal rather than in docker, it was detecting the new episodes being added automatically, i also have sonarr and radarr set to notify emby when new episodes are added.

cat /proc/sys/fs/inotify/max_user_watches = 9830400

cat /proc/sys/fs/inotify/max_user_instances = 16384

 

[Q-Droid 642]

1 hour ago, amateurgod said:

No errors in the logs but its only detecting new episodes that are added when a library scan is ran, however when i was running emby on baremetal rather than in docker, it was detecting the new episodes being added automatically, i also have sonarr and radarr set to notify emby when new episodes are added.

cat /proc/sys/fs/inotify/max_user_watches = 9830400

cat /proc/sys/fs/inotify/max_user_instances = 16384

 

Baremetal on the same host, OS and storage? If you're not seeing errors in the Emby log related to inotify limits then this detection problem might be tied to how the storage is presented to the container. I've seen a number posts about the *arrs not being able to trigger updates in Emby so that function sounds unreliable.

[amateurgod 26]

3 hours ago, Q-Droid said:

Baremetal on the same host, OS and storage? If you're not seeing errors in the Emby log related to inotify limits then this detection problem might be tied to how the storage is presented to the container. I've seen a number posts about the *arrs not being able to trigger updates in Emby so that function sounds unreliable.

Yes when I did it baremetal the storage was on the same host as the OS, it still is just now I'm using docker to localise everything because of dependancy conflicts with other software I wanted to run

This is my first time using docker, I usually do everything baremetal, I just mounted the storage to the docker via a bind mount in portainer. 

[Q-Droid 642]

My tests work with bind mounts in docker. The library paths are watched and new media detected and scanned. What type of filesystem are you using for the media libraries? If you attach an emby server log we could see if there are errors thrown.

[amateurgod 26]

5 hours ago, Q-Droid said:

My tests work with bind mounts in docker. The library paths are watched and new media detected and scanned. What type of filesystem are you using for the media libraries? If you attach an emby server log we could see if there are errors thrown.

When I went through the logs the only error was that the filepath for one folder was too long,

 

I'm using a mergerFS mount with the settings for cachine files etc, however I do have ~100Tb of media on my server 

[Q-Droid 642]

Ah, that's it. You can't expect MergerFS (FUSE) to work with inotify. Is MergerFS a new addition as part of the change to Docker container? I don't know how RTM could have been working before if you were already using MergerFS unless the setup was as I described a few posts above.

 

[amateurgod 26]

3 hours ago, Q-Droid said:

Ah, that's it. You can't expect MergerFS (FUSE) to work with inotify. Is MergerFS a new addition as part of the change to Docker container? I don't know how RTM could have been working before if you were already using MergerFS unless the setup was as I described a few posts above.

 

No, I've been using mergerFS for years to have all my drives under one mount point, mergerFS works fine with inotify with the right settings, if you have "cache.files=partial" or better it usually works fine with inotify

[Sandro1982 0]

36 minutes ago, amateurgod said:

No, I've been using mergerFS for years to have all my drives under one mount point, mergerFS works fine with inotify with the right settings, if you have "cache.files=partial" or better it usually works fine with inotify

I needed to set "cache.files=full" for Deluge to work and even then Emby's real-time monitoring doesn't work.

What is the correct configuration for both Deluge and Emby to work correctly? That's all it takes for me to completely migrate my server. 

[Q-Droid 642]

1 hour ago, amateurgod said:

No, I've been using mergerFS for years to have all my drives under one mount point, mergerFS works fine with inotify with the right settings, if you have "cache.files=partial" or better it usually works fine with inotify

Hmmm. Have you tried different caching options? When you say "partial" or better you mean higher level/more caching? I wonder how the kernel change notifications are tied to mergerfs caching levels. I don't know what else you're using this server for but since media is not exactly a high perf, high IOPS application is there any real benefit to caching in FUSE. I haven't used it though I do find it interesting that you had inotify working which contradicts all of the literature I've found for mergerfs.

Another thing - is the runtime user for the emby container the same one that was running the bare metal installation? If you had tweaked your mergerfs mounts to where the old emby user was working but running the container by a different one that might also be a factor.

 

[amateurgod 26]

56 minutes ago, Sandro1982 said:

I needed to set "cache.files=full" for Deluge to work and even then Emby's real-time monitoring doesn't work.

What is the correct configuration for both Deluge and Emby to work correctly? That's all it takes for me to completely migrate my server. 

I don't use deluge however when I was running emby bare metal, "cache.files=auto-full" worked for me for the RTM, when I'm back home at my PC I'll SSH into the server and share my full mergerFS settings for you as they all worked for me for RTM when I was running baremetal, I also had to increase my max watch instances and max watch users but you shouldn't need to do that unless you have a large library with a lot of files to watch