primeval_god

I believe that the script itself would be responsible for ensuring that only a single instance can run at a time. Adding one of the solutions from this page https://unix.stackexchange.com/questions/48505/how-to-make-sure-only-one-instance-of-a-bash-script-runs would probably do the trick.

Not that i am aware of. Thats basically all that is available. The ability to rearrange "cards" in their respective columns.

I would suggest using docker-in-docker to play around with scan. docker pull docker docker run --rm -it --entrypoint /bin/sh -v /var/run/docker.sock:/var/run/docker.sock docker should get you into a temporary container with the docker cli installed and connected to the daemon on unRAID. Then use the instructions on the github page https://github.com/docker/scan-cli-plugin#how-to-build-docker-scan to install the cli plugin in the container. (replacing curl with wget). And you should be able to scan.

You should just be able to use an absolute path in your volume configuration see here. Dont try and update compose containers via the normal docker gui. At the moment there is no easy control for updating components of a compose stack.

Not sure at this point, I am not familiar with the usage of the Docker Folder plugin. If it requires integration with the gui components of this plugin then that will likely be a ways down the line. The compose.manager GUI is still in the very early stages of development.

My vote is clone, mostly because i think it looks more snapshot like. But i also think i am using cubes for the compose plugin.

I tend to default to something from font-awesome for plugins. @Squid do you know what version unRAID uses off the top of your head?

Best guess (from a non-Emby user), Emby didnt rescan your media library after you moved the files and thus was unaware that anything had changed. Furthermore is it possible that you tried to play a file that you had recently played? If so maybe emby had an already transcoded version in its cache and didnt bother trying to actually read the file?

Yes it would be on the container developer to support bind mounts as well as volumes.

So the way that i have seen others handle this in the past, and the way i have built unRAID style containers, is to not pre-populate mount directories at build time. Rather the default files are placed in another directory and the entrypoint script or scripts check the mount point at runtime and copy the default files in if they do not already exist.

Can you give an example of the commands you are trying to use?

No is the settings that i use. As to what is the best, i am not really sure. I am not certain of the specific use-case of deleting the swapfile on stop. I am not the original author of the swapfile plugin and i am not completely familiar with the history of all of its options.

Putting the swapfile on the array is not a recommended configuration. For one it will tend to keep the disk it is on spun up at all times (and thus also parity). I am not certain if the plugin code explicitly forbids the configuration but I would advise against it. I have used a USB2 flash drive for mine in the past, it works ok but the speed of the drive is not great. In such a configuration i recommend settings swappiness to very low or even zero so that the system will tend not to use swap unless memory pressure demands it. One other warning though, flash drives are not the highest quality flash memory and heavy swap usage on one will tend to wear it out fairly quickly (Not an issue with SSDs).

Both this plugin and its precursor work just fine on xfs. The reason there is so much talk of BTRFS in this thread is that this newer plugin also supports BTRFS where the previous version did not.

I am not certain how clear the help text makes it but you should specify a non-existing folder location when on BTRFS, the plugin will then create a subvolume at that path and place the swapfile in it. I am really not sure what the best way to communicate this to the user is as it is non-intuitive.

The plugin should already do this when creating a swapfile on a btrfs filesystem. It should create a new subvolume with the proper BTRFS attributes when the location is set to a BTRFS file system.

I dont really know if one or the other filesystem performs better for swap. I am currently using btrfs and it has been working fine.

So far as i know there are no plans to replace the unRAIDs template format with compose yaml files. As for my goal with this plugin, it is a lot simpler than people are speculating. The interface I am working on (very slowly i know but I have been busy lately) is little more than a way to create and edit compose files in the webui, plus a few buttons to trigger compose up and compose down. Basically the user.scripts plugin for compose files. Personally I think that docker compose will always be secondary to templates on unRAID. There are a few useful application stacks that are just hard to build up with unRAID templates however for the most part the applications that unRAID users use are single container and easily added via unRAIDs template interface.

On nitpick, while you can copy everything from the build context into your image like you are above, it might be cleaner to COPY only the bot.py script.

It depends on how you want to go about it. knex666's comment above suggested bind-mounting the your source code into the container (using a -v flag in docker run). That would make it easier to make changes to the source (bot.py) without recreating the container. On the other hand what you have above is most of what you need to build your bot.py directly into the container, which would make it easier to distribute. To finish building your code into the container you need to add a COPY line in you dockerfile to copy bot.py to a location within the filesystem of your image and a WORKDIR line to ensure your container begins running from the proper internal directory.

No docker is still the best choice.

I dont know for sure but i would suspect it is the file integrity plugin. The "Changed" time reported by stat is the last time that file metadata was changed (most docs list permissions as an example of metadata). The file integrity plugin stores its hash value in the extended attributes. What i dont know is if extended attributes are considred metadata in this instance, but i would suspect so.

Yeah sorry I was slow on the response here, what you did is exactly what i was recommending, the official python base image (which you used) was what i was thinking.

Any gui component i implement will be little more than a text editor for compose files. As for what versions of compose files are supported by the version of compose i have baked in I think the answer is all, so long as the version of Docker on unraid also supports that version of the compose spec. https://docs.docker.com/compose/compose-file/compose-versioning/ If i understood that fairly confusing page correctly the latest version of the compose spec has been supported by compose since v1.27.0