MMM-NEWS problem

stuartiannaylor

Guess it depends on what Pi you have, as can not say for 2/3 installs with electron.

I have refresh (ctrl+F5) auto from detecting the ‘Ready to go! Please point your browser to:’ of PM2 so on config change as soon as MagicMirror is ready Chromium does a refresh.
I also have a chromium log script to catch errors and provide the same but since the introduction to MagicMirror I seem to have an obsession with tinkering with it.
So if i manage to get a mirror up and running for several days I guess I could capture those errors and just do a refresh only on disconnection or error.
But noticed when I was putting together various modules that F5 refresh would sort of jam up after a while but ctrl+F5 doesn’t and is always like a clean start without having to reload the browser.

Haven’t tried P2/3 yet have one on my desk so will have to give electron a go.
All I know is that with chromium the server & browser become not connected and watchdog only restarts the server whilst the browser just sits as it was.
Its why I did the simple monitor scripts as now on a restart or config change Chromium & Server are always in sync.

So it might be the Pi version with no official support for Pi0/1 which I think is a shame as with the monitor scripts I have it seems to work great, so wondering why.
I am sort of having a short love affair with the form factor and price of the Zero and on a relatively low load project like this it works quite well.
In fact I am lying about the Pi2/3 as actually its a banana Pi zero same format practically no support but armv7.
Its on my desk because I2C has me completely scratching my head and the banana is twisting my melon.
Love the form factor though and why I think you should support as the Zero is cool and cheap.

I do agree that the modules should work and it should be that way round, but from short outages to plethora of problems I can not see why you shouldn’t refresh?
Guess its just not the supported way but not sure what the problem is with refresh as long as you do a hard refresh not a soft one.
https://www.getfilecloud.com/blog/2015/03/tech-tip-how-to-do-hard-refresh-in-browsers/#.XHcXXIj7SUk

sdetweil

@stuartiannaylor folks that have these unexpected problems, use tools to shutdown and restart MM altogether… pm2 is one of those tools, used usually with cron (scheduling tool on linux)

stuartiannaylor

@sdetweil Seems a bit of a over kill when node restart and browser hard refresh is a matter of seconds and does exactly the same. Who wants this constantly full restart thing on the wall, on the pie zero on server restart I get no white screen at all stays as back ground and maybe 10 secs to fill again with content so for Pi2/3 you could blink and miss it.

I will prob have some further system log monitor actions but the pi watchdog will force a restart if seizes.

Cron is a really bad way to do it as it quite simple to get a notification exactly when its ready and also not just do it on a time loop when its not so you end up with the horrid white chromium refresh screen.

Tail and log monitoring is where linux excels.

( tail -f -n0 ~/.pm2/logs/MagicMirror-out.log & ) | grep -q 'Ready to go! Please point your browser to:'
sh xdotool.sh

Thats it job done.

PM2 only tests that MagicMirror is loaded and running as ‘Ready to go! Please point your browser to:’ comes on my lowly zero quite a bit after PM2 says MagicMirror is running.

Also as I say with when the browser and server (Magic Mirror) become disconnected they stay that way with Pi0/1 Electron will launch again but actually its not necessary as all that is needed is a hard refresh.

You can test this on a Pi2/3 with the setup I did for zero but it will work for 2/3 and also uses Stretch lite which has always confused me why the relatively pointless desktop load is used for a mirror.
Just change three lines and use chromium instead if you follow https://github.com/StuartIanNaylor/MagicMirror-Install-Guide-Raspberry-0-to-3

Really electron / server should be 2 PM2 processes as this would work more seamlessly as its an assumption but electron is just Chromium in a java wrapper with the selenium webdrivers so expecting it takes time to reload after being killed and likely that it wasn’t really required.
When this Banana stops twisting my melon as if I can not get I2C running on it then its destined for the bin, but if I do I will have look if I am wrong about the speed of killing electron each timeinstead of just doing a hard refresh.
As of course you can do a refresh as long as its a hard refresh ctrl+F5 and not ctrl+r or F5.
https://www.getfilecloud.com/blog/2015/03/tech-tip-how-to-do-hard-refresh-in-browsers/#.XHcXXIj7SUk

A Former User

REFRESHING MM, not RESTARTING could make problems on many modules(including mines.). Regardless some modules would be not affected, but some would.

It depends on design of module structure. I do some tricks on DOM_OBJECTS_CREATED as a signal for ready of working. When MM is started and be ready for all DOM being prepared, that notification is emitted. Only one time emittance of that notification is expected during execution, not twice or more. But REFRESHING will break that agreement.

When MM Front is refreshed, MM modules would be restarted but some background-procedures (like node_helper.js or related background external scripts) are not killed or restarted properly. Because, many of them are not designed to be REFRESHED.
REFRESHING is some kind of interrupt from User. It couldn’t be predicted or postponed by condition. so, cannot be done killing or restarting process gracefully and safely.

So, It’s better not to REFRESH. RESTART MM instead.

costascontis

ok i get it now thank you @Sean .I resolved all the problems i had with my modules except MMM-NEST-STATUS,so i dont need to refresh any more.Thanx again for the explanation.

stuartiannaylor

@sean Your Module is being restarted as the server is reset.
If your module causes problems with hard refreshes then its non compatible with any browser as when a browser cache is cleared its cleared.
If refreshing after that causes problems then its bad programming with your module.
Its doesn’t cause problems with a hard refresh though as the cache is cleared, there is no dom as it starts a fresh and the page its pulled in as if the browser had just been started.

Do you understand the difference between a hard refresh and soft refresh?
Name your module and I will tell you if its causes problems when hard refreshed?

A Former User

@stuartiannaylor
No cache related problem. I’m saying background process.
Let’s assume node_helper.js hosts some external python script for its job. The script might be started on start(). In that case, REFRESHING doesn’t affect any harm side-effect to the script because it is already running on.
But if the script needs to be executed with some data of runtime after module starts, you cannot put that script execution in start(). That script should be executed by socketNotification somewhere.
REFRESHING makes that socketNotification transferring several times without any preparation. You cannot kill the background python script to restart it gracefully before User’s REFRESHING by force.

Of course, Developer can make codes to avoid this by checking current running script. but why? MM is not designed to be refreshed by user. (nonetheless whether it is possible or not)

stuartiannaylor

@sean Look I am using many modules and hard refreshing with zero problems.
Tell me what your module is and what it is supposed to do under a hard refresh and what error it will cause.
I already know the answer none, but hey will test it and see.

Every module I install on config change auto restarts the server which takes seconds. The connection between browser and server is broken.
Browser waits for server to say hey port 8080 is ready then browser hard refreshes.
It takes 10 - 20 seconds 10 for server and the browser still holds the last screen then on ready hard refresh, browser dumps its cache and its the same as first time connection to the site.
Yes you can hard refresh and its vastly quicker than killing a browser for absolutely no apparent reason apart some misunderstanding of actual use.
Its vastly faster than killing and reloading the browser and its seemless without any horrid white screens oh awe snap or whatever it says.
Install my guide on a Pi and watch it do as I am trying to say.

https://github.com/StuartIanNaylor/MagicMirror-Install-Guide-Raspberry-0-to-3

A Former User

@stuartiannaylor
First I can’t understand why are you teaching me about usage. :D I’m not the who is trying any HARD or SOFT refreshing.

I believe you are using many modules without problem. But I’m also developing above 30+ MM modules for this community for some years. :D

I already know WHAT ERROR some of my modules might have when MM is refreshed. And know also it is just caused by its design. I’m saying just some modules could not be working due to its design when a user refreshes MM by force.

stuartiannaylor

@sean Just say what it is and which module and I will test it and prove either you or I are right.

Its that simple as every module I install when I click save on config.js I never need to kill my browser and have gone through 5 to 10 modules at least without trouble and without restart.
Just say which modules and lets test to see who is mistaken?

Browsers are stateless and if the server has been reset and the browser drops its cache its the same as running new.