Araso

Just WebUI port. That's not a thing at the moment. I can't see any mention of it, at least. I feel like it's designed more to be connected to something else and searched from there, with a fallback to doing it manually if need be.

A quick and dirty workaround I'm using is: Settings -> Download Client -> then open whichever client you're using and set 'Initial State' to 'Pause'. This way torrents will still be grabbed but at least you can allow or reject manually if need be. Understandably, this might not work for everyone's situation. If nothing else, it can give you some breathing space to add extra custom formats to filter out the more... exotic naming schemes you'll undoubtedly find that you've never seen before. After all - this will scrape everything from everywhere and they're not all using scene-approved naming schemes.

There's this. You'd need a config file for it though. Where that should be located is asked in the post right above yours. There's some info here.

My only concern was to not fill up docker.img. Now that I know, this is working perfectly fine as it is. So no changes necessary. If it's not broken... Thanks for the container, it's working great.

Apparently so... As I say - I've never (or don't ever remember having) seen this before. Right-click and Properties shows 0 bytes used, which also now makes sense. Well, I best leave it well alone. Thanks for the pointers!

Hmm... I use Linux from where I mount my cache disk with SMB4K and from there I look in my appdata. I've always done this. At no point have I not been able to see the data in there, even if I've had to show hidden files. Using mc I can, indeed, see the postgres/data directory. Strange... So it seems my install is working correctly but for some reason the data is 'super hidden'? I've never encountered this before.

I have a postgres directory in 'appdata/binhex-bitmagnet/postgres' but it's empty, which is what led me to believe what I said about docker.img. That directory is empty even after a stop/start of the container which I did just to see if it would flush something to disk. It still retains all the crawled data after a restart.

What happens if you don't set up postgres? I haven't and after stopping and starting the container, the amount of items that were found before I stopped it are still there. In appdata there is no sqlite database or anything much, really. This leads me to believe that the data is being stored in docker.img - is that correct? Where is the data being stored if not using a postgres database?

I see here that you've pushed a version 3.2.0 but :latest still points to the old version. Unless I change the tag to :3.2.0 it will not update. I'd rather not apply a specific tag because at some point another update will come and I'll forget that I did that. Also, it means no-one else will get this update if they're on :latest.. I have a duplicate test container which I've switched to the :3.2.0 tag and after running a diff, the only difference I can see is that you've renamed: appdata/stable-diffusion/07-StableSwarm/ to: appdata/stable-diffusion/07-SwarmUI/ So this means all I really need to do before updating the container is to rename that single directory. Is that the only change?

Since the developer of Swarm has resigned from StabilityAI, the repo is being changed to a new independent Github. The ComfyUI dev has also resigned but that's another matter. You can read the latest here. To begin using the new repo, the migration guide is here. This is the way I did it: 1. Start the container without changing anything. This is to allow it to update as far as it can go from the old StableSwarmUI repo. 2. Stop the container. 3. Open a terminal in the 'appdata/stable-diffusion/07-StableSwarm/StableSwarmUI/' directory. 4. Type these commands one-by-one: git remote set-url origin https://github.com/mcmonkeyprojects/SwarmUI git pull 5. Start the container. It should pull from the new SwarmUI repo. The new repo has been updated in the past few hours and my container has, indeed, updated to the latest version which is as of now 'SwarmUI v0.9.0.1 (2024-06-22 03:41:43)'. @Holaf The repo will need to be changed to point to here, otherwise new installs will only pull the now deprecated version. To everyone else: Nothing beats the speed of ComfyUI but lots of things do beat its interface. I was using Forge until it died, so I moved back to Automatic1111 and everything was slow again. After reading a bit about Swarm, I watched this (it's worth it) and after installing Swarm I haven't looked back. It's stunning how much faster it is since it uses ComfyUI as a backend. Now the developers of both Swarm and ComfyUI (who both used to work at StabilityAI until they resigned in the past week) have now teamed up, which you can read here and here. Both devs are very active and as most people know - ComfyUI always get the newest features first. Since they're all teamed up, this will apply to SwarmUI as well.

The way I do it is to edit the WEBUI_VERSION key, separating my choices with a pipe: Then after saving, I get a nice an easy dropdown to select my preferred UI: Literally just add (or replace the existing value) this to the WEBUI_VERSION key: 02.forge It should be noted that at the moment, Forge development seems to have kind of stalled, unfortunately. Some things are broken, regional prompter being one of them. I use RP a lot so I switched back to standard A1111. If you're careful then the memory optimisations that Forge has that you lose don't really matter. Hopefully Forge picks back up again but at least there's a choice between the two.

I must admit, I didn't think to do this. I expect, at most, to remove the env but to leave everything else in place whenever I start the container. But since there's nothing there I've customised or need to keep, I've gone ahead and deleted everything. I imagine since you said you don't use Kohya that you delete the whole directory regularly, which I don't do, and that's why we've been getting different results sometimes. The entire log now (after three starts): [migrations] started [migrations] no migrations found usermod: no changes ─────────────────────────────────────── _____ __ __ _____ _____ _____ _____ | | | | __|_ _| | | | --| | |__ | | | | | | | | | |_____|_____|_____| |_| |_____|_|_|_| _____ __ __ _ __ ____ | __ | | | | | | \ | __ -| | | | |__| | | |_____|_____|_|_____|____/ Based on images from linuxserver.io ─────────────────────────────────────── To support LSIO projects visit: https://www.linuxserver.io/donate/ ─────────────────────────────────────── GID/UID ─────────────────────────────────────── User UID: 99 User GID: 100 ─────────────────────────────────────── [custom-init] No custom files found, skipping... App is starting! [ls.io-init] done. Local branch up-to-date, keeping existing venv Channels: - defaults Platform: linux-64 Collecting package metadata (repodata.json): ...working... done Solving environment: ...working... done # All requested packages already installed. Channels: - conda-forge - defaults Platform: linux-64 Collecting package metadata (repodata.json): ...working... done Solving environment: ...working... done # All requested packages already installed. Requirement already satisfied: pip in /config/70-kohya/env/lib/python3.10/site-packages (24.0) 15:20:04-388204 INFO Python version is 3.10.14 | packaged by conda-forge | (main, Mar 20 2024, 12:45:18) [GCC 12.3.0] 15:20:04-556792 INFO Submodule initialized and updated. 15:20:04-562357 INFO Installing python dependencies. This could take a few minutes as it downloads files. 15:20:04-563542 INFO If this operation ever runs too long, you can rerun this script in verbose mode to check. 15:20:04-565226 INFO Kohya_ss GUI version: v23.0.15 15:20:04-567755 INFO Installing modules from requirements_linux.txt... 15:20:04-570023 INFO Installing modules from requirements.txt... 15:20:04-575680 INFO Installing package: -e ./sd-scripts 15:20:27-118198 INFO Configuring accelerate... 15:20:27-120563 WARNING Could not automatically configure accelerate. Please manually configure accelerate with the option in the menu or with: accelerate config. LAUNCHING KOHYA_SS ! 15:20:32-792246 INFO headless: True Sorted! Now you can check the forum without expecting yet another list of errors from me. Cheers for all your work!

OK, tested: To start with, I simply started the container without touching the env or anything else: kohya-log-first-start.txt So there's a message in the log: Remote branch is ahead. If you encouter any issue after upgrade, try to clean venv for clean packages install There was also an error: error: Your local changes to the following files would be overwritten by checkout: README.md library/sdxl_original_unet.py Please commit your changes or stash them before you switch branches. Aborting fatal: Unable to checkout '6b1520a46b1b6ee7c33092537dc9449d1cc4f56f' in submodule path 'sd-scripts' 22:47:26-432880 ERROR Error during Git operation: Command '['git', 'submodule', 'update', '--init', '--recursive', '--quiet']' returned non-zero exit status 1. So I deleted the file 'Delete_this_file_to_clean_virtual_env_and_dependencies_at_next_launch' and started the container again while I watched to make sure it wiped the env correctly. It did, so that was all working as intended. Here's the log: kohya-log-second-start.txt I still got that error: error: Your local changes to the following files would be overwritten by checkout: README.md library/sdxl_original_unet.py Please commit your changes or stash them before you switch branches. Aborting fatal: Unable to checkout '6b1520a46b1b6ee7c33092537dc9449d1cc4f56f' in submodule path 'sd-scripts' 22:54:37-118317 ERROR Error during Git operation: Command '['git', 'submodule', 'update', '--init', '--recursive', '--quiet']' returned non-zero exit status 1. Then I stopped and started the container again for a third time: kohya-log-third-start.txt This also had the same error as above. All three times I started the container I could still load the UI without problems. What I haven't done, because it takes such a long time to do, is to actually test creating a LoRA. For all I know it might work without any problems or it might fail. As I say - it takes a long time to test something like that. I've never made any changes to those two files: README.md library/sdxl_original_unet.py So it's not a conflict there to prevent overwriting user-modified files. There's something odd here because I imagine it's pretty much an identical process for all UIs but I don't see these problems in A1111 or Forge. So it's something specific only to Kohya, as far as I can tell. But they're all only downloading the latest branch from Github, so they should all work in the same way.

I might be worth mentioning that the last commit, as you can see here was 5 days ago. So the env that was there should have been fully up to date and not requiring an update at all. All of these reinstall have been happening well after the last commit. So I think it's maybe a bad idea to prevent normal updating procedure. I think it's something else - maybe some sort of conflict somewhere. But at the very least, there is now the possibility to delete the file to wipe the env if needed if you do go down that route.

This is fixed and all existing files were moved over. Nice! This also is fixed. This, unfortunately, is not fixed. I keep getting this every time: Remote branch is ahead. Wiping venv for clean packages install Updating 6162193..5bbb4fc Full logs for the first three starts after installing this new version: kohya-log-first-start.txtkohya-log-second-start.txtkohya-log-third-start.txt