4 ms·

That sounds like defensive programming; what makes you think meta refresh will not trigger always? If you can demonstrate it, it'd be worth filing a bug report

That sounds like defensive programming; what makes you think meta refresh will not trigger always? If you can demonstrate it, it'd be worth filing a bug report with the respective browser(s). Same with the reboot, although the user does not control every software in the e-reader. That said, e-readers and tablets are designed to be always-on, so memory leaks should be rare nowadays.

GTP 2y ago
There's nothing wrong with defensive programming, especially if it is supposed to run on a device where you don't have easy and/or immidiate access in case something stops working.
trashcan 2y ago
I have setup a raspberry PI dashboard before and run into these exact issues. They are not defensive or pre-emptive. An e-reader will probably not have the same issues, just sharing my experience. * Browser runs out of memory or has other issue and stops refreshing. * Wifi connection drops and browser displays an error page and stops executing your refreshes. The power-saving options on the RPIs wifi caused me quite a bit of grief before I disabled them. * Raspberry Pi crashes with kernel errors due to cheap SD card, underpowered USB power supply, or something else. I ran into these issues one by one over a few months and fixed each one as I ran into it. What I ended up with was: * Browser set to run at OS startup displaying my page. * That page having a meta refresh tag, and javascript code to reload the page periodically. * A browser extension to automatically reload the page as well if both of those failed. * A watchdog daemon that detects when the RPI has frozen and reboots it. * A cron job that reboots periodically. With all of those my dashboard would run for months without any issues or interruptions. Just sharing so others can be aware of potential issues.

4 ms·

That sounds like defensive programming; what makes you think meta refresh will not trigger always? If you can demonstrate it, it'd be worth filing a bug report

by Cthulhu_ 2y ago

GTP 2y ago
There's nothing wrong with defensive programming, especially if it is supposed to run on a device where you don't have easy and/or immidiate access in case something stops working.
trashcan 2y ago
I have setup a raspberry PI dashboard before and run into these exact issues. They are not defensive or pre-emptive. An e-reader will probably not have the same issues, just sharing my experience. * Browser runs out of memory or has other issue and stops refreshing. * Wifi connection drops and browser displays an error page and stops executing your refreshes. The power-saving options on the RPIs wifi caused me quite a bit of grief before I disabled them. * Raspberry Pi crashes with kernel errors due to cheap SD card, underpowered USB power supply, or something else. I ran into these issues one by one over a few months and fixed each one as I ran into it. What I ended up with was: * Browser set to run at OS startup displaying my page. * That page having a meta refresh tag, and javascript code to reload the page periodically. * A browser extension to automatically reload the page as well if both of those failed. * A watchdog daemon that detects when the RPI has frozen and reboots it. * A cron job that reboots periodically. With all of those my dashboard would run for months without any issues or interruptions. Just sharing so others can be aware of potential issues.