UPDATE: V3.18 addresses many of these issues
Read on for the old way of recovering from a corrupt web app
It’s possible it ran out or low on space.
Currently the updates write a new web app copy first (leaving the original intact in case the update fails), so does need more space than usual. Also, the update’s themselves are signed and verified at the end of the process so won’t apply if the wrong file (pico vs standard) is uploaded but will take a long time.
There’s a few things we can try to recover it. Assuming it’s still on the network and not in setup mode, you can try nuking the web app and re-running the update via /update. If you are stuck in WiFi setup mode (Shows up as Pixelblaze_XXXXXX and you get the sign in popup) but the page doesn’t load, then you can try manually posting to it. See this post for info on how to do that (a similar issue).
To nuke the web app, you can use curl (or a browser) to this magic URL:
Swap out the IP address for your local address if in client mode.
After that, try applying the update again via the /update URL.
When the filesystem is low on space, writes can take a long time, and writes can also impact patterns as it uses the same flash storage that code is stored on. I wonder if some of the slowness and choppy animation can also be solved by freeing up some space (once you get the app loading again of course).
If you can’t get it working, or do get it working but it’s still stalling out / laggy, let me know!