Update including pull request #89 causes slideshow to hang

[pyrosteve]

My mirror is cycling through about 25,000 images stored in a folder structure on a Windows share, which is mounted on the Pi.
The WiFi connection to the Pi is slightly marginal, but the display has worked for many months without any issues.

When I updated to the latest revision (including pull request #89) the show stuck on a single image after a few hours. I restarted several times and always the same behaviour (but not sticking on the same image). The Pi was always still running and accessible via ssh, and the time and Weather displays on the mirror kept updating.

Eventually I wound back to the previous revision and everything has run reliably since (about a week).

I'm happy to provide more info to help track down the problem if someone can tell me what you need.

[petitemuse]

Hello pyrosteve,

I have the same problem: the mirror is black with the mouse showing. I tried to reduce my amount of pictures from 1000 to 50, and the result was the same. Now I am trying to randomizeImageOrder: false, and see what will happen. But even if works I rather be surprised by random pictures.
I am totally new in the mater, could you please explain how you wound back to the previous revision?
Thank you for your help

[pyrosteve]

In my case the slideshow simply froze on the current image - no black screen; clock and weather forecast continued working.

Since I undid the change it has run through nearly 23,000 images without missing a beat, so although I don't know what caused the problem I'm pretty certain it's something in pull request #89. I'd really welcome some input from someone familiar with the code...

@petitemuse , assuming you installed the add-in with git clone and updated it with git pull, you can wind things back using git reset (which unwinds the commit history) or git revert (which adds a new commit to undo the previous changes). Use git log --oneline to find the revision you want to move back to, then use whichever you prefer (I used reset).

[petitemuse]

I found a way to this problem, and it works really well! Just install MMM-WatchDog.
This module keeps an eye on your UI and quits app in case the UI crashes. If you combine this with the PM2 process manager, MM2 will automatically restart after a UI failure.

[MystaraTheGreat]

I'm having almost exactly the same issue with a display where backgrounds are stored on an internet share and internet connectivity is patchy. At some point, the image rotation simply stops - presumably when connectivity goes down. At that point, it never seems to try again, even hours after connectivity is restored.

[MystaraTheGreat]

The problem certainly still arises with 31cf1f5 (Merge pull request #89 from DanielHabenicht/master)

Curiosuly, with 663ba52 (Merge pull request #88 from shmulyeng/master) I just get a black screen.

[MystaraTheGreat]

Well, I can't seem to confirm the cause precisely. I've rolled back all the way (one at a time) to 47b86aa. Each version either replicates the 'stuck image' or I just get a black screen with no image.

So I'm not entirely sure where the problem lies. I will likely try to add some debug lines into the module to see if I can work out where the problem is arising. I suspect that if it fails to load an image, the timer that causes it to rotate the image is not refreshed and so it simply stops.

[MystaraTheGreat]

Okay, well here's where I got to, but I'm stuck....

The problem arises in updateImageList.
It sends a notification (BACKGROUNDSLIDESHOW_REGISTER_CONFIG) to node_helper.
Node_helper correctly determines the list of images and then generates a return notification (BACKGROUNDSLIDESHOW_FILELIST).

However, for some reason, that notification is never received.

Looking around, I see that in order for a node_helper to be able to send a notification to the main script, it's necessary for the main script to firstly send a notification to the helper in order to open a socket. Is it possible that, due to the time taken to gather all of the files (12 seconds in my case), the socket gets closed?

[MystaraTheGreat]

Right.

The answer, as best as I can determine, is that the sockets in socket.io underlying MM are unreliable. This module is not particularly robust to the unreliable nature of the sockets. In particular, if the generated file list goes missing then the timer is never restarted and so the image hangs. This is likely to happen on an unreliable internet connection.

A fix would be to either implement some kind of acknowledgement system between the module and the helper.

[DanielHabenicht]

Is it just BackgroundSlideshow issue or maybe a MagicMirror issue? (e.g. have you tried different versions of MagicMirror with the Background Slideshow module?)
I have it running at my parents house without problems, but I also copy only one folder from the network drive at once and then display this folder (changing the folder each day).

[mcnahum]

I have more and more black screen who is fixed by a restart of magicmirror ...
If there is logs or information to grab to share the investigation, I'm happy to help.
all my photos are shared on a NAS who is mounted if I reboot.

[MystaraTheGreat]

I think the problem is that the sockets in magic mirror are unreliable and MMM-BackgroundSlideshow doesn't implement any kind of reliable transport mechanism on top of them. As a consequence, if one packet goes missing (e.g. if your internet connection drops or times out on an NAS query), the whole thing falls over.

In the end, I gave up and moved to MMM-RandomPhoto, which seems to be actively maintained and has built in nextcloud capability, which works better for me. It hasn't failed once.

[DanielHabenicht]

Which MMM-RandomPhoto are you refering to? I found this, but it's not maintained either: https://github.com/diego-vieira/MMM-RandomPhoto

Are you hosting your magicmirror somewhere else than the display?

@mcnahum are there any errors on the Console of the Webbrowser?

[MystaraTheGreat]

Good point :)

skuethe/MMM-RandomPhoto is the one I'm using, which seems to be relatively up-to-date. I just sent a PR to it.

I'm hosting the MM on the display itself.

[mcnahum]

@DanielHabenicht "are there any errors on the Console of the Webbrowser?" can you teach me how to check? If the screeen is freezed I can easily ssh to it ( this is how I reboot it anyway)

[darickc]

I've changed how the files are loaded. Instead of getting a list from the server and sending it to the browser and then the browser loading by making a http get; I am loading the list of images on the server and storing it there, then when a new image is to be loaded, it reads it on the server, base64 encodes the image, then passes that up to the browser using web sockets. This should fix any path or filename issues because it doesn't need to be url safe. This also means that you should be able to pass any valid path to the images, instead of it having to be under the magic mirror path. There is also now an option to resize the image on the server before it is passed to the browser. This is better for performance if using animations.

I did break one piece where you can pass a list of images from another module, but everything else should work.

If anyone would like to test and let me know if there are issues, that would be great.

[mcnahum]

ok with the last update I had a strange behaviour:

black screen arrived but the rest of my MM was still working
I was able to use the "move to next photo" option and it worked but ... no more slideshow it stay blocked to that photo for hours ....

restarting MM make it work again ... for now

[darickc]

Can you see what errors there are in the logs?

[darickc]

Be sure you are running 'npm install' in the MagicMirror/modules/MMM-BackgroundSlideshow directory and the MagicMirror/vendor directory.

[mcnahum]

until now no black screen ( but it's normal it's 1 or 2 times per week)
What log do you suggest to check?

[darickc]

If you are using pm2, I think you can use 'pm2 logs mm'.
This is a good article for troubleshooting https://forum.magicmirror.builders/topic/86/how-to-troubleshoot.

[scottdrichards]

I was having trouble with moderately sized folders of images (>100). I think it has to do with the synchronous file system calls were somehow causing the whole thing to hang? Not sure. As I was debugging etc. I ended up making a fork that just has basic image capabilities. You can check it out here https://github.com/scottdrichards/MMM-SimpleBGSlideshow. If people think the async file system approach would solve problems, I can try to make a PR for it.