About --disable-queue startup parameter

[mart-hill]

Since I totally don't know, how to create a PR, and I don't want to mess up the github and the repo, I'd like to propose a small modification for the webui.py in line 305 (sorry about writing it here 🙂):

        if not cmd_opts.no_gradio_queue:
            shared.demo.queue(64)
        else:
            print('Server queues disabled')
            shared.demo.progress_tracking = False

This way the UI won't error out, when this parameter is used (now it displays an error that queuing is needed for progress tracking and then interrupts the startup of the server).
I have to admit for me it happens pretty quickly in this repo, after 1 - 10 images generated under normal circumstances (when websockets is used), so I had to modify the mentioned file to be actually able to use the UI, locally, on the same PC server is running.

Edit: SD.Next already has this fix applied. My bad. 🙂

[anapnoe]

no worries added to the current version
I am working on SD.Next locally when ready it will be available here

[mart-hill]

I'll test

        if not cmd_opts.no_gradio_queue:
            shared.demo.queue(concurrency_count=16)
        else:
            print('Server queues disabled')
            shared.demo.progress_tracking = False

...since I still get the freezes, when it's just shared.demo.queue(concurrency_count=64) in line 305. 🙂

[anapnoe]

I added again I had removed it since after a discussion I had it is not the reason that causes the problem
this is just a workaround
so I want to find a better solution as WebSockets are more efficient for real-time applications 🙂

[mart-hill]

Yeah, it's just a workaround, but I can't avoid using it, for now - WebSockets (or something in-between? not AdGuard for sure) cause me a royal PITA with Generate button freezing. Could that be, that my i9 7940X CPU is an issue for the algorithm, since the CPU has a bit curious architecture?