Screen freezes

[mattncsu]

Running v3.1, I've noticed sometimes the display will pause for a few seconds or I'll find it hasn't updated in a few hours. If I Alt-F4 it drops back to the desktop and I can open a new terminal and restart the console. I also VNC'ed so I could see the console output and I didn't notice anything that would indicate an error.

Another odd thing I noticed, and this may be because I also had VNC session active, but when I touch the buttons on the screen, the console registered the click but I was also seeing clicks on the desktop in the VNC window. For example, clicking the upper left corner of the current forecast tile caused the start menu to open on the vnc session.

[peted-davis]

Another odd thing I noticed, and this may be because I also had VNC session active, but when I touch the buttons on the screen, the console registered the click but I was also seeing clicks on the desktop in the VNC window.

This unfortunately is to do with how Kivy (the Python GUI module) draws the console on a Raspberry Pi 3. It ensures the console runs efficiently, at the cost of not interacting with the desktop in a normal fashion. I have tried correcting this, but it makes the Pi3 run very sluggishly. There are some more details here: https://stackoverflow.com/questions/37443845/kivy-touch-and-keyboard-events-passing-through-to-desktop

Running v3.1, I've noticed sometimes the display will pause for a few seconds or I'll find it hasn't updated in a few hours

This sounds odd. When the console is frozen, is the clock still running as normal? The next time it freezes can you check out your SmartWeather homepage (https://smartweather.weatherflow.com/) and see if your data is reaching the WF servers correctly? The only time I have seen this behaviour assuming the clock isn't freezing and no error message is being presented, is when the WF servers have stopped sending data.

[mattncsu]

The clock is freezing which is how I identify the console is freezing. I have GPU mem at 256, do I need to bump it up?

[peted-davis]

256 should be plenty. Are you running anything else on your Pi besides the console? Are you familiar with the top command? It tells you how much CPU and memory each process running on your Pi is using. Can you open a new terminal while the console is running and enter the top command. There should be a line associated with the console where the COMMAND is listed as python3. Assuming you only have one python3 process running on your Pi (the PiConsole), can you let me know what CPU and memory usage it is taking up? When it next freezes can you let me know the CPU and memory usage at that point? Is there another process on your Pi that is using a lot of CPU and memory?

Edit: if you could take a screen shot like mine below, that would also be very useful

[mattncsu]

The same pi is also running frfeed in the background but that uses minimum resources. I didn't manage to capture it before stopping, but python3 was using 50% of CPU last time it was frozen. Here's after stopping wfpiconsole so you can see the background load:

after restarting wfpiconsole:

[mattncsu]

And here we are with the console frozen:

Current clock readout is 16:19:06 vs 17:01 current time. Here's the console activity for it:

[peted-davis]

Thanks for all the screenshots - I'm not sure I understand this. There is nothing abnormal looking in the CPU/memory usage, and there is no error message from the console. Are all the panels displaying properly otherwise including the forecast, sunrise/sunset and moon phase? Is there any pattern to when it freezes? i.e. does it happen when it is raining, or some other reproducible behavior?

I have to admit I have not seen/heard of this issue ever before. Do you have a spare SD card that you can use to setup a fresh image of Raspbian and try a clean install of the console? That might help identify if it is a weird installation error or something along those lines.

I'll also test run your station on my Pi tomorrow to see if I can recreate the freeze ups.

[mattncsu]

I dug out a different Pi 3 also running stretch. I got it all caught up on upgrades and installed wfpiconsole. On this one, it has a larger screen and I noticed wfpiconsole opened in a window instead of full screen.

This one seems to be running more reliably and its possible the difference is that the "new" pi had the OpenGL driver enabled (I don't get any display output without it) and the "old" pi had the legacy driver.

With the OpenGL driver on the old Pi, I can see the console on VNC but it's partially offscreen and I have no output from the "official touchscreen" connected which is a separate issue i'll need to work through:

[peted-davis]

You are right that the OpenGL driver has to be enabled to see the console over VNC on the Pi3. The downside of this though, is that you'll find the CPU usage is even higher (you can see using the 'top' command that the console is using nearly 100% of one of the CPU cores), as the GPU on the Pi3 is not really powerful enough to handle full OpenGL. That's why out of the box the Pi3 does not have the OpenGL driver enabled, and instead it renders the console in the screenbuffer. This works for the 7 inch touchscreen, but does not work over VNC.

If you want to keep using OpenGL on the Pi3, it is probably best to edit the wfpiconsole.ini file and set the Hardware key to Pi4. That will make sure the window scaling is done correctly. The console is only every going to be 800x480 pixels though, as it is coded specifically for the 7 inch touch screen.

My advice though would be to flash the Pi running your touch screen with Rasbian Buster and use this to display the console without the OpenGL driver. Then use your second Pi3 to run frfeed. The fact that your second Pi is running the console fine suggests to me that the console and frfeed are too much for a single Pi3, and this is what is causing your Pi3 to lock up. I also ran your station for 24 hours myself on my Pi3/touchscreen setup and didn't see a single lock up.

[mattncsu]

It seems after a while, the second Pi (the one with the larger screen that requires openGL enabled to display) freezes also. Just can't win here!

[peted-davis]

Just released an update (v3.2) that fixes a bug that was causing the screen to "freeze" as data was no longer being streamed to the console. You can update with wfpiconsole update

[mattncsu]

Still freezing :( I tried setting a cron tab to stop and start the server every hour but I couldn't get it to work. Maybe something drastic like that could be implemented in the script. aka wfpiconsole start restart 60 to restart the gui every 60 min...

This is what I tried in crontab: 0 * * * * XAUTHORITY=/home/pi/.Xauthority DISPLAY=:0 /home/pi/wfpiconsole/wfpiconsole.sh start

[peted-davis]

Sorry you are still having issues. Have you managed to do a clean install with Rasbian Buster on the Raspberry Pi that is attached to your touchscreen screen? The fact that no one else has seen this issue suggests that there might be something very specific to your setup that is causing the issues.

I will have a look into a start/restart option and see what I can do.

[mattncsu]

Figured since I was upgrading to Buster and had to take my pi out of the touchscreen case anyway, I'd swap in my Pi4 which of course doesn't fit the existing case...quick amazon search turned up this..screen looks familiar ;-)

[mattncsu]

Still freezes up after a few hours on a fresh copy of Buster on a Pi 4.

[peted-davis]

Thanks for sharing the Amazon link! I'm afraid I am at a loss regarding the freezing. I assume there is nothing else running on the Pi except the console? Is the clock also still freezing? Have you made any other changes to the configuration of the Pi except those required to install the console?