Emby Config path problem

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Knorki wrote:

      I have tried that with a share out of the mergerfs mountpoint, but with the same result. Restart after 4 seconds
      So that doesn't work, my config is on a totally separate independent drive and it works, yours works if it's on your system drive, so either you leave the config on the system drive or add another drive if possible.

      What does work is you could create a share, let's say call it EmbyServer on your mergerfs, leave the config on the system drive during setup of the docker point that EmbyServer to /mnt/share3. Emby will then start inside Emby you point the cache, metedata, and transcode options to /mnt/share3 thereby moving that option away from your system drive. Hope that makes sense, I have done this previously and it works.
      Raid is not a backup! Would you go skydiving without a parachute?
    • geaves wrote:


      What does work is you could create a share, let's say call it EmbyServer on your mergerfs, leave the config on the system drive during setup of the docker point that EmbyServer to /mnt/share3. Emby will then start inside Emby you point the cache, metedata, and transcode options to /mnt/share3 thereby moving that option away from your system drive. Hope that makes sense, I have done this previously and it works.
      Sorry,

      but I did not understand exact what you mean. Can you please explain it a bit more.



      getName() wrote:

      This is an intersting one. I guess its fuse that has problems with mergefs. Maybe this will be a starting point for some research, if you plan on fixing this.
      Of course I'm interesting in to solve this problem. I don't like to have the config daa on my systems drive

      Stefan
    • Knorki wrote:

      but I did not understand exact what you mean. Can you please explain it a bit more.
      I'll try, leave the config on your system drive, on your mergerfs create a share call it as you have before EmbyConfig, when you set up Emby Docker point that share to say /mnt/share3 (I have /mnt/share1 for Movies, /mnt/share2 for TvShows and /mnt/share3 which we'll use when setting up Emby during the wizard setup)

      So when Emby is running under manage server -> settings under advanced point the cache path to /mnt/share3, then under Library -> advanced point the Metadata path to /mnt/share3
      You then do the same with the transcode temporary path. This will tell Emby to use /mnt/share3 to store that information, I know this works because that is how I had it all set up originally.
      Raid is not a backup! Would you go skydiving without a parachute?
    • geaves wrote:

      Knorki wrote:

      but I did not understand exact what you mean. Can you please explain it a bit more.
      I'll try, leave the config on your system drive, on your mergerfs create a share call it as you have before EmbyConfig, when you set up Emby Docker point that share to say /mnt/share3 (I have /mnt/share1 for Movies, /mnt/share2 for TvShows and /mnt/share3 which we'll use when setting up Emby during the wizard setup)
      So when Emby is running under manage server -> settings under advanced point the cache path to /mnt/share3, then under Library -> advanced point the Metadata path to /mnt/share3
      You then do the same with the transcode temporary path. This will tell Emby to use /mnt/share3 to store that information, I know this works because that is how I had it all set up originally.
      For some reasons I was not able to use /mnt/share3 for setting up Dockers - Secure Emby with LetsEncrypt and Nginx Reverse Proxy on a subdomain

      Dockers - Secure Emby with LetsEncrypt and Nginx Reverse Proxy on a subdomain from blackhole's guide, small problem
    • geaves wrote:

      I'll try, leave the config on your system drive, on your mergerfs create a share call it as you have before EmbyConfig, when you set up Emby Docker point that share to say /mnt/share3 (I have /mnt/share1 for Movies, /mnt/share2 for TvShows and /mnt/share3 which we'll use when setting up Emby during the wizard setup)
      So when Emby is running under manage server -> settings under advanced point the cache path to /mnt/share3, then under Library -> advanced point the Metadata path to /mnt/share3
      You then do the same with the transcode temporary path. This will tell Emby to use /mnt/share3 to store that information, I know this works because that is how I had it all set up originally.
      OK, now it's clear. But this will not store the config data about the server himself, installed plug-ins, user and user rights etc. and thats not what I#m looking for.

      Or am I wrong?

      Stefan
    • Knorki wrote:

      But this will not store the config data about the server himself, installed plug-ins, user and user rights etc
      No that will stay on your system drive, as you have already shown that using your system drive works and the space that it takes up is minimal compared to the cache and metadata.

      My library is not very big, the one thing I could do is to test this for myself using only my Movie folder, but creating an Emby config folder on my mergerfs mount point.
      Raid is not a backup! Would you go skydiving without a parachute?
    • I can confirm using mergerfs for Emby config does not work;

      To test I stopped Emby, created a share on the mergerfs mount point, within the container I pointed /config to newly created folder under /srv/<fuse mount point> after about 30 seconds it went into a restarting loop.

      Now this could be related to the default plugin settings for mergerfs under options, not sure though.
      Raid is not a backup! Would you go skydiving without a parachute?
    • Hello,

      after a long time of searching the internet, I have finally solved my problem. Problem was caused by mergerfs. In the config from mergerfs I have to delete the option direct_io because mmap (used by many docker containern) does not work when direct_io is enabled. But this will cause double caching of files and therefore less memory for caching generally so I have enabled dropcacheonclose to help with this problem.

      Maybe this will help others, not only with Emby. I have had the same problem with bitwarden for example.


      Best regards

      Stefan
    • Knorki wrote:

      Hello,

      after a long time of searching the internet, I have finally solved my problem. Problem was caused by mergerfs. In the config from mergerfs I have to delete the option direct_io because mmap (used by many docker containern) does not work when direct_io is enabled. But this will cause double caching of files and therefore less memory for caching generally so I have enabled dropcacheonclose to help with this problem.

      Maybe this will help others, not only with Emby. I have had the same problem with bitwarden for example.


      Best regards

      Stefan
      Hi there,

      Any chance of a bit more info on how to use these options please? I tried just substituting direct_io with dropcacheonclose and it stopped my pool mounting.