Could you just DISABLE THE MANDATORY FETCH ComfyRegistry Data?
V3.31.9 manager in comfy portable
I set COMMANDLINE_ARGS=--dont-fetch-updates in comfy launch nvidia gpu.bat. It works only when starting the webui, after the webui is loaded in browser, the fetch process start again!!!!
Everytime I launch comfy UI it takes a f******** long time to fetch comfyRegistry Data, it is ridiculous that this time consuming event should not be unconditioned! IT WOULD TAKE MORE THAN 2 MINUTES TO fetch all 90 registry
I tried this:
To disable FETCH DATA, you can change network_mode to private or offline. https://github.com/ltdrdata/ComfyUI-Manager?tab=readme-ov-file#config
This is from https://github.com/Comfy-Org/ComfyUI-Manager/issues/1629
However, in my custom node directory this is no "ComfyUI-Manager" directory, there is only a folder named "ComfyUI-Manager-main" while the cmd treat is like ComfyUI-Manager folder, there is NO config.ini in this folder. I even manually creat a config.ini and add network_mode = private, but it does not work. It still FETCH those registry data. IT'S JUST HORRIBLE WE DON'T HAVE SO MUCH TIME IN LIFE
there is NO config.ini in this folder. I even manually creat a config.ini and add network_mode = private, but it does not work.
The 'config.ini' is not located in the 'ComfyUI-Manager' folder inside your 'custom_nodes' folder. It is located in your root 'ComfyUI' folder under 'user/default/ComfyUI-Manager/'
Everytime I launch comfy UI it takes a f******** long time to fetch comfyRegistry Data, it is ridiculous that this time consuming event should not be unconditioned! IT WOULD TAKE MORE THAN 2 MINUTES TO fetch all 90 registry
You don't have to wait for this process to finish before starting to generate. The moment you see the 'To see the GUI go to: http...' you are good to go.
A patch is currently in progress to remove that fetching process, but to add further clarification: the message is purely informational, and since the process runs in the background, there’s absolutely no need to wait for it to complete.
@ltdrdata basically you are right with your assumptions, that it is an optional call, but fact is, that the startup is extremly long (>5min). but yes, the webinterface and all functions are then available
@ltdrdata basically you are right with your assumptions, that it is an optional call, but fact is, that the startup is extremly long (>5min). but yes, the webinterface and all functions are then available
Does that mean the UI is unusable while the fetch is hanging?
correct. the step to reproduce this is the complete block of internet access. IPs are assigned.
+1 when trying to read the console errors, this fetching causes the scroll jump to end.
Is there an update on this? I also find it extremely annoying when trying to figure out why something failed to load (Re: scrolling up until it completes it's 2min of whatever is quickly scrolled back to the bottom due to the inevitable console printing)