Tab is empty when using headless server about sd-webui-comfyui

[PladsElsker]

We added comfyui flag forwarding from a1111. I think the issue is that you are passing the url and port flags directly to comfyui.

If you want to pass flags to comfyui, you can pass --comfyui-[flag] to your a1111 args, where [flag] is a comfyui flag.

For example, you would use --comfyui-port 8188 as an argument to your a1111 launch script in order to start comfyui on that port.

[ljleb]

parser.add_argument("--comfyui-listen", action='store_true', default=None)

Yeah the option is listed as a flag, but it should accept str. Needs to be fixed

[jjohare]

I thought I understood that, but --comfyui-listen {ip address] errors as an unrecognized argument. Thanks though I'll keep trying
I should be clearer, I pass an IP to comfy when it's running on it's own, otherwise it doesn't work, 0.0.0.0 default is loopback only.

[ljleb]

Thanks, I'll take your suggestion.

By default if --listen 0.0.0.0 is passed to comfyui, we will fallback to 127.0.0.1. The behavior can be overridden by setting the client url explicitly through the command line or through the extension settings.

[jjohare]

I have tested this in a cloud system with the following command style (adapt for your needs):
Start-Process -NoNewWindow -FilePath 'ssh' -ArgumentList '-L 7860:localhost:7860 -L 8188:localhost:8188 login@$IP
It works great now: Also need to add --listen and the local IP into the comfyui extensive boxes as discussed above.

[jjohare]

Apologies, that is expected, I didn't even try it without. I left this note for people to follow later. Everything works.

[jjohare]

Thanks, this feels closer. I can set the port with comfy-port but obviously --listen is just a flag here. In comfyui I can pass the IP address in too which is required for my setup.

python ./main.py --listen 192.168.n.n

[PladsElsker]

To pass the url to comfyui, you also need to pass the url in the forwarded -listen flag, which is --comfyui-listen [url], where [url] is your url.

You don't need to start comfyui manually, the extension is supposed to start it on its own through the webui.

[PladsElsker]

here's a list of the current forwarded comfyui flags at the time of writing, if you need other flags:
--comfyui-port
--comfyui-listen
--comfyui-dont-upcast-attention
--comfyui-use-split-cross-attention
--comfyui-use-pytorch-cross-attention
--comfyui-disable-xformers
--comfyui-highvram
--comfyui-normalvram
--comfyui-lowvram
--comfyui-novram
--comfyui-cpu

[jjohare]

I did see that. Glad I am reporting an actual bug tbh! Thanks

[ljleb]

@John-WL if you're busy I can take this one, it should take 5 minutes.

[PladsElsker]

yes you can do it, I'll review it

[ljleb]

This took a little bit more tinkering that I thought. @jjohare does it make sense for your use case to specify a different address for the ComfyUI server and the address used by the extension? If you know one thing or two about networking, I'd like to know if you think it makes sense to be able to specify 2 different addresses (1 for the ComfyUI server, and 1 for the webui client to refer to the ComfyUI server). I added an option for the address used by the client that falls back on the server URL, but maybe this is unnecessary.

[jjohare]

I don't think so, they're both on the same system for ME, but they could hypothetically be separated out onto two machines. I feel that would imply parallelisation which seems like it's a more complex proposition. So long as images came back to the UX from both nodes through the UX it might be a nice provision though. Oh hang on you mean specify the UX IP address? That's totally doable yes. There's three system level components in play here right?

[ljleb]

There's three system level components in play here right?

Sorry, I don't know what a system level component refers to.

IIIUC there are 4 addresses here at play:

• 2 for the webui: the address used to refer to the webui from within the webui server, and the address used to refer to the webui from your web client
• 2 for ComfyUI: the address used to refer to ComfyUI from within ComfyUI's server, and the address used to refer to ComfyUI from your web client

IIUC, these could all be different. Is that the case for your setup? Is there always a way to refer to ComfyUI using a single url?

For example, in the case of passing --listen 0.0.0.0 to comfyui, it seems that I need to use http://127.0.0.1:8188 to refer to it from a web client for it to load (http://0.0.0.0:8188 doesn't work). My question was, are there other cases like this that would not be trivial? If so, we probably need a separate config value for the url used by the web client.

[jjohare]

In a cloud cluster context yes there could be 4, agreed I am using this in an intranet context so this collapses to either 1 or 2. I normally use1 as I can reference localhost for webui and comfy using the same intranet "local network" IP. One is therefore fine for my issue but does not generalise to the possible 4 that a cloudy cluster implies for your plugin. The problem with 0.0.0.0 is its explicitly loopback not localhost. I therefore could not easily engineer round it with port mapping and SSH tunnels from my client, which is a perfectly good approach for cloud too. Documenting that and using the more permissive 127.0.0.1 might work best for this edge case so as not to introduce complexity?

[ljleb]

Thanks for testing, glad it works now.

Also need to add --listen and the local IP into the comfyui extensive boxes as discussed above.

Is that unexpected? What would you expect to have to do if that is the case?