kelinger
commented
1 year ago I think there are some tweaks that still need to occur. In pre-release versions, we had an issue where OmniMount wouldn't catch failures and the results were less than ideal. Plex would be "up" but all videos would be missing, for example. The problem is that in Linux, you create an empty (ideally) directory and then mount a remote on top of it. The path is the same but the directory no longer looks empty. When the mount is dropped, the empty directory remains.
With Docker, we're essentially doing the same thing so you have an external directory mounted to something internal to the container. But since that external directory is actually your Google drive (for example) mounted over that empty directory, the sign of a failure is that the container now sees the empty directory, not a missing directory. Furthermore, when the mount is re-established (often in seconds or even under a second), Docker still has the empty directory mounted in the container despite the overlaid remote mount. This causes things like downloads or changes to be written (at best) to the empty directory causing it to a) no longer be empty which could cause mount issues later on and b) files not to be where you expect them to be.
Now, we have a much better process but it's also sort of brute force. Any failures immediately trigger a container restart. If only Plex loses its mount, only Plex will restart. But if OmniMount loses it, all containers dependent on it will also restart when OmniMount restarts.
If you find it is restarting way too frequently there are a few undocumented tweaks we have already setup for purposes like these. You can change OmniMount's caching, for example, by creating a file called vfs.conf in the root of the OmniMount configs directory. In it, put any combination of these variables with appropriate settings to see if these changes help (default values are shown here):
VFSMAX=100G
VFSAGE=48h
VFSPOLL=5m
VFSREAD=2G
VFSCACHE=yesDon't expect a lot of error checking here so be sure to use proper values as documented by Rclone. But, if disk space is minimal, for example, you'll want to reduce the cache size from 100G to something like 20G or maybe even turn off the caching with VFSCACHE=no.
There's also a variable called TURBOMAX in the configs. This isn't a menu option but you can edit the raw OmniStream config file with the omni edit command. Look for the line that says TURBOMAX=20 and change it to something lower. This represents how many parallel operations TurboSync will attempt when syncing files up to Google. I ran into similar issues when I was using a slower "less endowed" server for testing purposes and had to reduce it to 10. Before doing so, things appeared to work OK but if my server decided to add an entire TV series (versus one new episode) I'd find things in a really bad state otherwise. Honestly, it really won't be that noticeable unless you're sitting around watching it download/upload.
mahogl
omnimount_inspect.txt Dont know if it is just me, but for some reasons Omnimount restarts quite often, and then all the other containers that depends on Omnimount restarts. For me it often looks like its triggered by load, for it often happens when a download starts. It does fixes itself and everything is running afterwards, but sometimes i causes som failed downloads and Sonarr/Radarr tries do download another version.
Don`t know for sure when it startet, but it might be few months ago, first tought it was related to the server i was running on. But i have now changed the server and problem is the same. By the way, the backup/restore feature is working great i had the new server up running in no time.
Let me know if there is some data i can provide, so you can look into the problem when you have some time.