01-10-2021, 04:43 PM
(This post was last modified: 03-20-2021, 03:58 PM by TheOldPresbyope.
Edit Reason: do the work on .xinitrc as root
)
Update 20210311 - This guide was written specifically for moOde 7.0.1. With the advent of moOde 7.1.0 we find new versions of chromium-browser and vivaldi-stable have been issued. The eventual memory exhaustion problem has been demonstrated in moOde 7.1.0 with chromium-browser 84.0.4147.141, 84.0.4147.105-rpt3, 88.0.4324.187-rpt1. The problem has also been demonstrated with vivaldi-stable 3.6.2165.40-1. Therefore, at the present time, there is no reason to install Vivaldi. The solution must be found elsewhere.
Background
Some users of moOde 7.0.1 on an RPi3B+ with Local Display enabled and with an HDMI display (*not* the 7-in Touch Display or other non-HDMI display) have experienced a system "lock out" after a lengthy idling period.
At least one failure mode has been traced to the chromium browser package installed in 7.0.1. This browser is used as the local Web client in moOde and is responsible for rendering what is seen on the local display. When the local display is enabled, an initial chromium process is started and spawns 8 more processes to handle various browser tasks. After a lengthy period in pause/idle mode, the type=renderer chromium process unexpectedly starts consuming memory to the point where other processes, including the system scheduler, begin experiencing difficulty, leading ultimately to at least temporary catatonia.
The root cause of this behavior has not yet been determined. It was not experienced with moOde 6.7.1, which is based on an earlier version of Raspberry Pi OS which in turn includes an earlier version of the Chromium browser. Also, it has not been determined whether the behavior occurs on RPi4B models which have more memory than the RPi3B+ and, if it does, whether the system is able to heal itself when more headroom is available or simply takes longer to lock out.
In the meantime an experiment has suggested that using the Vivaldi browser instead of the Chromium browser as the local client may ameliorate the situation.
Vivaldi is a cross-platform browser based on the same Chromium engine used in the full Chromium browser. The two browsers use this engine in different ways, which gave rise to the experiment. Fortunately, the APIs and options are similar, so that the substitution is nearly a "drop in" replacement.
Installing Vivaldi in moOde
This procedure is benign in the sense that it does no irreversible harm to your moOde installation.
The steps are performed from the command line of the moOde player under test, which of course must be using an HDMI display for the Local Display. Best to stay in the home directory of user "pi" but that's not essential if you know what you're doing.
1. Install the sole missing dependency
2. Download the 68MB Vivaldi browser package
This is the current version at the time of writing, but it's always worth checking on the Vivaldi download page. It's the package named Linux DEB ARM in the pull-down menu.
Note: at the time of writing there is only one ARM package---"armhf" meaning 32-bit binary. That's the one you want even if in future they also offer a 64-bit version (unless of course you've rebuilt moOde as a 64-bit clean system, in which case you've got the chops to do all this yourself).
3. Install the package
4. Modify moOde to use the Vivaldi browser
- make a backup of /home/pi/.xinitrc so you can recover if needed. (The naked "cd" command ensures you are in the /home/pi directory)
- as root and using your favorite text editor (for example, "sudo nano .xinitrc"), change the invocation of "chromium-browser" to "vivaldi-stable" in .xinitrc, so that the line reads (note this is a single line no matter how it is displayed here)
5. Reboot for good luck, or at least disable and then re-enable the Local Display.
[If you decide to change back
6. Restoring the stock configuration
- save the modified .xinitrc for possible future use
- copy the stock configuration back
Like before, reboot or at least disable and then re-enable the Local Display.]
Exercise the new browser
Try all the usual functions and features. Try to reproduce the conditions in which you previously experienced "lock up." Report your experiences to the Forum.
If you're a bithead, you'll have compared the two browsers for number and types of processes spawned, for memory and CPU consumption, yada yada yada. They differ. In someways the Vivaldi processes seem to be "heavier". As well, the initial vivaldi process spawns not one but two type=renderer processes. Nevertheless, they don't seem ever to start binging on system resources at least in my first, 10-hour experiment.
Background
Some users of moOde 7.0.1 on an RPi3B+ with Local Display enabled and with an HDMI display (*not* the 7-in Touch Display or other non-HDMI display) have experienced a system "lock out" after a lengthy idling period.
At least one failure mode has been traced to the chromium browser package installed in 7.0.1. This browser is used as the local Web client in moOde and is responsible for rendering what is seen on the local display. When the local display is enabled, an initial chromium process is started and spawns 8 more processes to handle various browser tasks. After a lengthy period in pause/idle mode, the type=renderer chromium process unexpectedly starts consuming memory to the point where other processes, including the system scheduler, begin experiencing difficulty, leading ultimately to at least temporary catatonia.
The root cause of this behavior has not yet been determined. It was not experienced with moOde 6.7.1, which is based on an earlier version of Raspberry Pi OS which in turn includes an earlier version of the Chromium browser. Also, it has not been determined whether the behavior occurs on RPi4B models which have more memory than the RPi3B+ and, if it does, whether the system is able to heal itself when more headroom is available or simply takes longer to lock out.
In the meantime an experiment has suggested that using the Vivaldi browser instead of the Chromium browser as the local client may ameliorate the situation.
Vivaldi is a cross-platform browser based on the same Chromium engine used in the full Chromium browser. The two browsers use this engine in different ways, which gave rise to the experiment. Fortunately, the APIs and options are similar, so that the substitution is nearly a "drop in" replacement.
Installing Vivaldi in moOde
This procedure is benign in the sense that it does no irreversible harm to your moOde installation.
The steps are performed from the command line of the moOde player under test, which of course must be using an HDMI display for the Local Display. Best to stay in the home directory of user "pi" but that's not essential if you know what you're doing.
1. Install the sole missing dependency
Code:
sudo apt install font-liberation2. Download the 68MB Vivaldi browser package
Code:
wget https://downloads.vivaldi.com/stable/vivaldi-stable_3.5.2115.87-1_armhf.debThis is the current version at the time of writing, but it's always worth checking on the Vivaldi download page. It's the package named Linux DEB ARM in the pull-down menu.
Note: at the time of writing there is only one ARM package---"armhf" meaning 32-bit binary. That's the one you want even if in future they also offer a 64-bit version (unless of course you've rebuilt moOde as a 64-bit clean system, in which case you've got the chops to do all this yourself).
3. Install the package
Code:
sudo dpkg -i vivaldi-stable_3.5.2115.87-1_armhf.deb4. Modify moOde to use the Vivaldi browser
- make a backup of /home/pi/.xinitrc so you can recover if needed. (The naked "cd" command ensures you are in the /home/pi directory)
Code:
cd
sudo cp .xinitrc .xinitrc.chromium- as root and using your favorite text editor (for example, "sudo nano .xinitrc"), change the invocation of "chromium-browser" to "vivaldi-stable" in .xinitrc, so that the line reads (note this is a single line no matter how it is displayed here)
Code:
vivaldi-stable --app=http://localhost/ --window-size=$SCREENSIZE --window-position=0,0 --no-first-run -enable-features=OverlayScrollbar --disable-infobars --disable-session-crashed-bubble5. Reboot for good luck, or at least disable and then re-enable the Local Display.
[If you decide to change back
6. Restoring the stock configuration
- save the modified .xinitrc for possible future use
Code:
cd
sudo mv .xinitrc .xinitrc.vivaldi- copy the stock configuration back
Code:
cd
sudo cp .xinitrc.chromium .xinitrcLike before, reboot or at least disable and then re-enable the Local Display.]
Exercise the new browser
Try all the usual functions and features. Try to reproduce the conditions in which you previously experienced "lock up." Report your experiences to the Forum.
If you're a bithead, you'll have compared the two browsers for number and types of processes spawned, for memory and CPU consumption, yada yada yada. They differ. In someways the Vivaldi processes seem to be "heavier". As well, the initial vivaldi process spawns not one but two type=renderer processes. Nevertheless, they don't seem ever to start binging on system resources at least in my first, 10-hour experiment.
