Read the statement by Michael Teeuw here.
MMM-NEWS problem
-
@costascontis
Usually MM doesn’t need to be REFRESHED by user.
Whenever it refreshed, your sources query to get news would be transferred to Reader newly, So Articles are accumulated.
Anyway, The refreshing of MM is really needed for your real usage? -
thnx for your answer ,yes i need to refresh mm hourly just to keep some modules keep working/updating.I thought it was a good idea so i schedule a refresh every hour using the mmm-modulescheduler.The only hiccap i have is with news module that multiplying the headlines with every refresh.I now using the default news feed that is working fine but MMM-NEWS is way better.I wish there was a fix for that.
-
Not sure about ctrl+r as think that is just refresh, if you do a ctrl+F5 it does a refresh that ignores cache so its pulled as if a new browser launch.
I have loaded and ctrl+F5 seems to work for me.
Dunno have a look at https://forum.magicmirror.builders/topic/9805/magicmirror-screen-goes-black/11As just finished a bit of a write up on a guide that might help
PS .
Add this into yourcss/custom.css
#NEWS .articleImage { filter: grayscale(100%); }
Top tip from eouia
-
@costascontis still want to understand why u need browser refresh page. MM is designed to NOT need to do that.
What modules don’t update properly?
Mine runs days and days without touching it. -
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 -
@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)
-
@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-3Really 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 -
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.
-
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.
-
@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?