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.
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.
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.
