You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For quite some time (years) I have had random instances of my various Volumio systems failing to boot.
These instances are unpredictable and can not be caused on demand.
In all instances, it involves a Raspberry PI 3B with official 7Inch display (I have two such setups, both have same problem randomly).
It has occured for multiple versions of Volumio and the TouchScreen plugin.
Generally what I have been able to find over the years, is that the Chromium Browser (displayed on the 7Inch display) is writing Cache data to the SD card, which ultimately results in the card being corrupted at some point, which only shows up folllowing a shutdown or reboot request (manually invoked from either Web link or touch screen).
I also have a PI ZeroW with no display, only remote web control, this never has a problem.
When a PI 3B board starts up, the corruption can cause various failures, again unpredictable, but could be any of the following:
1: Total failure to boot and board is unreachable, LCD screen displays a boot failure, or nothing.
2: Board boots, and can be accessed via web link, but touch screen is blank, though touch screen and backlight still react, just no browser display, appears to be caused by corruption of the SD card browser cache data preventing Chromium from completing startup. But media can still be played via the web link.
3: Board boots and can control from the touch screen, but can not access via web link, as target does not respond to a ping, unclear if this is the board failing to respond, or something blocking ping request and response via network router.
I am certain that there has been no power failure at any time, as I use the target by placing media tracks in the play queue, then play.
I do not empty the queue until I want to play something else, at which time I delete the queue and add the new items.
I have the queue to be NON persistent, this causes the queue to be empty following power up, so if there were a power fail between the last time I used the device, and trying to use it again after a period of days, the queue will still contain what was last played, it would be empty if a reboot had occured at any time, I have never seen the queue empty other than when I have requested a shutdown or reboot.
As a result of my observations on multiple devices, I must assume that there is a problem with Chromium corrupting the SD card while running in Kiosk mode for an extended period of time.
Not sure what fixes may be possible, as Chromium probably does not have any configurable options to prevent page cache being written to SD card, or be placed in the limited RAM, so that it can be purged on startup.
The text was updated successfully, but these errors were encountered:
For quite some time (years) I have had random instances of my various Volumio systems failing to boot.
These instances are unpredictable and can not be caused on demand.
In all instances, it involves a Raspberry PI 3B with official 7Inch display (I have two such setups, both have same problem randomly).
It has occured for multiple versions of Volumio and the TouchScreen plugin.
Generally what I have been able to find over the years, is that the Chromium Browser (displayed on the 7Inch display) is writing Cache data to the SD card, which ultimately results in the card being corrupted at some point, which only shows up folllowing a shutdown or reboot request (manually invoked from either Web link or touch screen).
I also have a PI ZeroW with no display, only remote web control, this never has a problem.
When a PI 3B board starts up, the corruption can cause various failures, again unpredictable, but could be any of the following:
1: Total failure to boot and board is unreachable, LCD screen displays a boot failure, or nothing.
2: Board boots, and can be accessed via web link, but touch screen is blank, though touch screen and backlight still react, just no browser display, appears to be caused by corruption of the SD card browser cache data preventing Chromium from completing startup. But media can still be played via the web link.
3: Board boots and can control from the touch screen, but can not access via web link, as target does not respond to a ping, unclear if this is the board failing to respond, or something blocking ping request and response via network router.
I am certain that there has been no power failure at any time, as I use the target by placing media tracks in the play queue, then play.
I do not empty the queue until I want to play something else, at which time I delete the queue and add the new items.
I have the queue to be NON persistent, this causes the queue to be empty following power up, so if there were a power fail between the last time I used the device, and trying to use it again after a period of days, the queue will still contain what was last played, it would be empty if a reboot had occured at any time, I have never seen the queue empty other than when I have requested a shutdown or reboot.
As a result of my observations on multiple devices, I must assume that there is a problem with Chromium corrupting the SD card while running in Kiosk mode for an extended period of time.
Not sure what fixes may be possible, as Chromium probably does not have any configurable options to prevent page cache being written to SD card, or be placed in the limited RAM, so that it can be purged on startup.
The text was updated successfully, but these errors were encountered: