Deforum extension not working

[williamforty]

Has this issue been opened before?

• It is not in the FAQ, I checked.
• It is not in the issues, I searched.

Describe the bug

Firstly, based on my debugging I think this is the right place for this issue, however I could be wrong. I apologise in advance if this turns out to be the wrong place for raising it.

I am trying to get the deforum extension to work properly, but having trouble. It seems to install just fine, it loads the required tab, etc. However, the "Generate" button does not work. This is a known issue, but I suspect there are various underlying causes, and I suspect one underlying cause might be related to docker.

Like the above linked issue, I get the same submit_deforum error:

VM139:3 Uncaught (in promise) ReferenceError: submit_deforum is not defined
    at eval (eval at <anonymous> (index.4395ab38.js:75:2081), <anonymous>:3:14)
    at index.4395ab38.js:34:32410
    at HTMLButtonElement.<anonymous> (index.4395ab38.js:76:2455)
    at index.4395ab38.js:4:1266
    at Array.forEach (<anonymous>)
    at HTMLButtonElement.le (index.4395ab38.js:4:1253)
    at HTMLButtonElement._ (Button.svelte:10:48)
    at index.4395ab38.js:4:1266
    at Array.forEach (<anonymous>)
    at HTMLButtonElement.le (index.4395ab38.js:4:1253)

Scrolling up to the top of the console reveals some earlier errors though, which I suspect may be the real root cause:

Failed to load resource: the server responded with a status of 500 (Internal Server Error)    deforum-hints.js:1
Failed to load resource: the server responded with a status of 500 (Internal Server Error)    deforum.js:1

The full paths of the requested files are:

http://localhost:7860/file=/stable-diffusion-webui/extensions/deforum/javascript/deforum-hints.js
http://localhost:7860/file=/stable-diffusion-webui/extensions/deforum/javascript/deforum.js

I'm afraid I'm no python expert, and I've never even heard of Gradio before today, so I'm not all that clear how these files end up being served to the browser. Therefore I'm not really able to debug the reason why these files can't be served up when they're requested (any help on this appreciated - happy to do some poking around, if I know where to poke!)

Inspecting the docker container, the files seem to exist at the /stable-diffusion-webui/extensions/deforum-for-automatic1111-webui/javascript/ location as expected. Owner and permissions seem to match other similar files, for example in the /stable-diffusion-webui/extensions-builtin/ directory.

One difference I noticed is that the extensions directory is exposed outside of the docker container, which might somehow cause python/Gradio to be unable to interact with the files in the usual way. To test this hypothesis I copied the extension to the extensions-builtin directory, which seemed to then allow the .js files to be served up successfully, but then I get other errors (presumably because I can't just move things around and expect it to work, but I don't know this for sure)

So, perhaps there are limitations around how extensions can work on docker, if they're contained within a folder that is shared with the host OS?

Which UI

auto

Hardware / Software

• OS: Windows 11
• OS version: Version 21H2 (OS Build 22000.1455)
• WSL version: 2
• Docker Version: v4.16.1
• Docker compose version: v2.15.1
• Repo version: 510f9fa
• RAM: 32GB
• GPU/VRAM: 6GB

Steps to Reproduce

1. Install Deforum extension
2. Reload the UI
3. Click on the Deforum tab
4. Click the Generate button
5. Inspect the console, and observe submit_deforum is not defined error

[AbdBarho]

@williamforty I guess we had a similar problem before #216

So, perhaps there are limitations around how extensions can work on docker, if they're contained within a folder that is shared with the host OS?

Pretty much so.

Because the extension folder is symlinked, the fully resolved path of the files in that folder does not fit the criteria that gradio uses to serve the file, so it ignores it.

I squeezed my head a lot for a good solution that does not involve just moving the extensions folder into the container, if you have any ideas I am all open ears.

[AbdBarho]

Ok so I managed to hack around it to get it up and running.

After merging #309, you can add the following to your startup.sh, install the defourm extension, and restart the container.

apt-get install ffmpeg -y
if [ -f ./extensions/deforum-for-automatic1111-webui/requirements.txt ]; then
  pip install -r ./extensions/deforum-for-automatic1111-webui/requirements.txt
  pip install -U opencv-python-headless 'transformers>=4.24'
fi

this will install all additional dependencies, and everything should work fine.

at least it worked for me.

[williamforty]

Thanks very much, it's now working! I tried it out before even adding the changes to startup.sh, and it seemed to work even without those changes - not sure why, maybe the dependencies are already in place from other things?

This was the result (slight graininess because I've had to compress to get under the github 10mb upload limit)

For my education, are the changes to startup.sh usually required to honour the install instructions for each individual extension? I suppose there's no telling what the requirements might be for installing each extension, so it's hard to handle in a generalised manner 🤔

[AbdBarho]

I had to revert this commit because it was causing other extensions to break. I will have to find a better solution....

I will comeback to your question later.

[AbdBarho]

Ok now, I managed to add another fix that did not break the world, although I am not very proud of it.

Regarding your question:

For my education, are the changes to startup.sh usually required to honour the install instructions for each individual extension?

startup.sh is basically a crutch for doing stuff in the container without having to modify or update the dockerfile.

The idea was, if any extensions need any additional dependencies or required any sort of configuration, you can do that in startup.sh.

I suppose there's no telling what the requirements might be for installing each extension, so it's hard to handle in a generalised manner 🤔

Correct. If am not mistaken, when you install an extension from the ui, if the extension has a requirements.txt, the dependencies will be installed (again, by the UI, not the container). This also means if you build a new version of the container and the extensions are already there, then you need to re-install their dependencies, that is why I prefer adding it directly to startup.sh.

This gets really tricky if you have conflicting versions of dependencies, deforum for example: source, target

I hope this answers your question.

If your problem is solved please close this issue.

[williamforty]

Many thanks @AbdBarho, I'm satisfied the problem is solved, I think. 👍