Well I do know there is a bug in the playlist I still have to fix, that might be related. But as for my JS, this is some of the worse JS to dig thru, so don't feel bad. This was once a little clean wallpaper, and then I kept adding stuff on stuff on stuff without a plan. So it's a huge mess now.

If you want to check, this is a huge lap of info that I think might help and if you have any questions of the code, just post them here. It's a mess, but it's my mess and I might be able to help point you to the rights points without going thru the mess of javascript that is trying to keep up with events and status.

Soo.. ( hope this all makes sense )

I would also suggest putting up the playlist on screen to check what happens in there. Despite it not giving a lot of data, it should somewhat color-codes images that are being loaded and shown as well as progress of time being shown in the controls themselves. So as long as you see the active image changing in the playlist, and the progress bar that is along side the controls is moving, the wallpaper should be running. And triggering new load events.

If you really want to dive into the code. You could use a console.error ( not console.log ) in the code notify you what is happening. An error should be catched and shown in the wallpaper. You can check console.js if you want to take control of this. While extremely basic, I found it very useful to check events within WE. I would suggest starting at that point in the index.html where the files get addeded/removed.

The wallpaper should just append newly found files to the active playlist based on 2 events triggered by wallpaper engine. These supply filenames in batches to add and remove. WE send this to the wallpaper, I wrapped that in my basic wallpaper.js wrapper code and then its sent to 2 functions at the bottom of index.html ( just above the drag/drop code for files ). The code is very simple, but it would be the "entry" point for filenames into the wallpaper.

Based on the description of your process, I would suggest to download outside the folder the wallpaper is using before copying it to the folder if you are not. If the playlist is empty, and WE would trigger a new file name without the image being complete, could cause the image to be loaded before its done. Also keep in mind that this is chome with its limitations, so if there might be any reason for chrome or WE not giving me access to file ( recently found one ) then that is another problem, but in that case the file might still be added to the playlist, but just not show an image and progress.

Also wonder if deleting all images before adding new ones could be the reason. But for now I would suggest to turn on the controls and playlist so those are visible in screen ( controls show when you move mouse to edge ) and making sure those are constantly updating. That should be a good starting point.



And then finally; The bug I know of but might not be related is that if you select a subfolder of the currently selected folder, the files in the subfolder only get removed and not added. Also keep in mind that if there might be some reason that the filename given is not the same filename as windows uses the wallpaper might not be able to access it. Ran into that one recently with some specific colored emojis in filenames.

Feel free to ask more questions here if you really want to try and figure it out yourself. But don't waste too much time on it as I do plan to do rewrite in time to fix a bug similar to yours as well as the subfolder bug that exist..

Thanks for the detailed response! I took your advice and looked at the playlist - it seems that it is truly getting stuck/crashing at some point; the controls are unresponsive until I reload the wallpaper. I'm guessing it's just getting overwhelmed by the number of events?

Good idea on just updating how my script works - I think I'll make some adjustments there, and then wait patiently for your bugfix :)

Thank you!

Side question as I have your attention - do you have any plans for webm support in the future? If not, I'd love to help and try to implement that.

Not sure what kinda of script it is, but if it makes the wallpaper hang, I would be more than curious to at least try to use it and reproduce the bug, as it indicates an unhandled error to me. I can't say if that will help you with your bug, but it would help me to avoid having the wallpaper hang like you describe. And maybe it fixes the bug, or shows me what the bug is so I can take it into consideration.

As for webm, while its been opted before, WE only returns images when it comes to selecting a directory. Also I am not entirely sure if SVG format can display video, and the slideshow is basically an SVG animation ( back then I couldn't write shader at all or I might have tried using threejs for better performance ).

Not sure if steam will handle code looking nice, but here's the part of my script that causes the crash/hang. In python, using os and shutil packages:

def clean_downloads(dir = DOWNLOAD_DIR):
if os.path.exists(dir):
shutil.rmtree(dir)
os.makedirs(dir, exist_ok=True)

Just a warning if you do use this, rmtree will delete whatever you point it out without confirmation - I'd recommend passing an absolute path just to be safe.

That helps. My guess is that you are have dir selected as folder for your images in the wallpaper? When you remove it WE will just think your selected folder is gone, and not recognise it being recreated.

If the above is the case you just need to put your current image folder into an empty folder. Then select that new folder, which would become the parent of your current, in WE. That way you are not removing the selected folder, but only its contents.