Official 7" Touchscreen Very Slow

[R101G]

Anyone else finding the swipe/scroll, and reaction to buttons, very slow on the touchscreen?

rAudio 20240913
6.6.47-3-rpi aarch64
Raspberry Pi 4B Rev 1.5
BCM2711 • 1.8 GiB
4 x Cortex-A72 @ 1.50 GHz

[ceejayemm]

@R101G
Yes, I can confirm something very strange is happening with my RPi3B+ attached to the (official) 7in touchscreen. On the touchscreen all main screens (Library / Playback and Playlist are available via the bottom bars but the Cog menu is not. Touching the image of the current station / album gives me the menu behind that and this seems to allow access to the Cog menus for setup etc. When I initially went to the Library screen all icons were shown but nothing worked. I then accessed the RPi via the web browser on my laptop and everything there worked as expected including the Library. Access vis the rAudio app on my Android phone also worked as expected. Going back to the Touchscreen, the Library page icons now worked. So it seems that access via the laptop and/or the Android app has 'enabled' the touchscreen to work somehow - strange.

Interestingly running 'journalctl -xe' via SSH on this RPi seem the show that when the touchscreen wasn't working there seem to be websocket.py errors (might be a red herring ?):

Sep 07 16:32:27 RAConservatory websocket.py[297]: connection handler failed
Sep 07 16:32:27 RAConservatory websocket.py[297]: Traceback (most recent call last):
Sep 07 16:32:27 RAConservatory websocket.py[297]:   File "/usr/lib/python3.11/site-packages/websockets/legacy/protocol.py", line 963, in tran>
Sep 07 16:32:27 RAConservatory websocket.py[297]:     message = await self.read_message()
Sep 07 16:32:27 RAConservatory websocket.py[297]:               ^^^^^^^^^^^^^^^^^^^^^^^^^
Sep 07 16:32:27 RAConservatory websocket.py[297]:   File "/usr/lib/python3.11/site-packages/websockets/legacy/protocol.py", line 1033, in rea>
Sep 07 16:32:27 RAConservatory websocket.py[297]:     frame = await self.read_data_frame(max_size=self.max_size)
Sep 07 16:32:27 RAConservatory websocket.py[297]:             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sep 07 16:32:27 RAConservatory websocket.py[297]:   File "/usr/lib/python3.11/site-packages/websockets/legacy/protocol.py", line 1108, in rea>
Sep 07 16:32:27 RAConservatory websocket.py[297]:     frame = await self.read_frame(max_size)
Sep 07 16:32:27 RAConservatory websocket.py[297]:             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sep 07 16:32:27 RAConservatory websocket.py[297]:   File "/usr/lib/python3.11/site-packages/websockets/legacy/protocol.py", line 1165, in rea>
Sep 07 16:32:27 RAConservatory websocket.py[297]:     frame = await Frame.read(
Sep 07 16:32:27 RAConservatory websocket.py[297]:             ^^^^^^^^^^^^^^^^^
Sep 07 16:32:27 RAConservatory websocket.py[297]:   File "/usr/lib/python3.11/site-packages/websockets/legacy/framing.py", line 68, in read
Sep 07 16:32:27 RAConservatory websocket.py[297]:     data = await reader(2)
Sep 07 16:32:27 RAConservatory websocket.py[297]:            ^^^^^^^^^^^^^^^
Sep 07 16:32:27 RAConservatory websocket.py[297]:   File "/usr/lib/python3.11/asyncio/streams.py", line 750, in readexactly
Sep 07 16:32:27 RAConservatory websocket.py[297]:     await self._wait_for_data('readexactly')
Sep 07 16:32:27 RAConservatory websocket.py[297]:   File "/usr/lib/python3.11/asyncio/streams.py", line 543, in _wait_for_data
Sep 07 16:32:27 RAConservatory websocket.py[297]:     await self._waiter
Sep 07 16:32:27 RAConservatory websocket.py[297]:   File "/usr/lib/python3.11/asyncio/selector_events.py", line 999, in _read_ready__data_rec>
Sep 07 16:32:27 RAConservatory websocket.py[297]:     data = self._sock.recv(self.max_size)
Sep 07 16:32:27 RAConservatory websocket.py[297]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sep 07 16:32:27 RAConservatory websocket.py[297]: ConnectionResetError: [Errno 104] Connection reset by peer
Sep 07 16:32:27 RAConservatory websocket.py[297]: The above exception was the direct cause of the following exception:
Sep 07 16:32:27 RAConservatory websocket.py[297]: Traceback (most recent call last):
Sep 07 16:32:27 RAConservatory websocket.py[297]:   File "/usr/lib/python3.11/site-packages/websockets/legacy/server.py", line 236, in handler
Sep 07 16:32:27 RAConservatory websocket.py[297]:     await self.ws_handler(self)
Sep 07 16:32:27 RAConservatory websocket.py[297]:   File "/srv/http/bash/websocket.py", line 12, in cmd
Sep 07 16:32:27 RAConservatory websocket.py[297]:     async for args in websocket:
Sep 07 16:32:27 RAConservatory websocket.py[297]:   File "/usr/lib/python3.11/site-packages/websockets/legacy/protocol.py", line 498, in __ai>
Sep 07 16:32:27 RAConservatory websocket.py[297]:     yield await self.recv()

Chris

[R101G]

I find the touchscreen UI only appears long after the remote UI is fully operational. It is as if it uses a different, and very slow, operating system. I do get a working cog symbol on the top bar, and my zoom setting is 90%.

[ceejayemm]

@R101G
I think the process is that the Pi boots into the rAudio software (which allows remote access) and then, if 'Browser on RPi' is enabled which it is be default on recent rAudio images, it starts up a local browser (Firefox currently on 64 bit images) on the RPi. This would explain why remote access becomes available much sooner than access via the touchscreen.

I recently set up a new RPi 3A for use with rAudio intending to use it with a touchscreen but found that with the 'Browser on RPi' enabled the 3A was basically unusable. Disabling 'Browser on RPi' returned the 3A to being a perfectly usable system when remotely accessed. I replaced the 3A with a 3B+ with the touchscreen installed and 'Browser on RPi' enabled and it performs well if a little slow to start up the local display on the touchscreen but once it settles down its OK.

I don't think this is related to rAudio as I then set up the latest RaspberryPI OS on the 3A with the touchscreen attached. It worked reasonably OK until I tried to start the local browser (in this case Chromium) and it ground to a halt. It looks like RPi before the 3B+ struggle with recent browsers.

I think I am getting to the point where I won't use the touchscreen on anything less than a RPi 3B+, relying on remote access via a remote web browser or phone app for the older versions of the RPi I still have. I haven't tried it (yet) but all of the above uses the 64 bit image, I wonder if reverting to the 32 bit image for these older models might be beneficial ?

Chris

[ceejayemm]

@R101G
After posting all of the above I noted that you are running RPi 4B so this may well not be relevant :-)

Chris

[R101G]

It certainly looks as if something is hogging resources. It would be interesting to know if it is just the official 7" which has a problem, or all local displays.

[rern]

Try connecting a monitor/TV and a mouse.
I've just done on my 4B and it's fine.

[R101G]

@rern
I am sorry, but I don't have any video leads for the Pi, and it seems to be the touch function which has a problem.
Could this be linked to the power shutdown problem I reported, and the failure of the WM8960 HAT volume to work?
They all use I2c, and dmesg has this:

[ 11.946329] OF: overlay: WARNING: memory leak will occur if overlay removed, property: /soc/i2c@7e804000/status
[ 11.963602] pinctrl-bcm2835 fe200000.gpio: pin gpio3 already requested by soc:shutdown_button@3; cannot claim for fe804000.i2c
[ 11.963639] pinctrl-bcm2835 fe200000.gpio: pin-3 (fe804000.i2c) status -22
[ 11.963652] pinctrl-bcm2835 fe200000.gpio: could not request pin 3 (gpio3) from group gpio3 on device pinctrl-bcm2711
[ 11.963662] i2c-bcm2835 fe804000.i2c: Error applying setting, reverse things back

(The WM8960 HAT and its driver were removed, as it would not work with the rAudio volume control.)

[ceejayemm]

@rern
I hooked up my test PI 3A to an HDMI monitor (no touch) and a keyboard/mouse. I installed i20240818 64 bit version and updated to the latest Update (Sept 10, 10:00 BST). I applied my normal settings and started with 'Browser on RPi' was disabled. This worked fine with no issues as far as I could see with around 215mb of free memory. I enabled 'Browser on RPi' and the system slowed appreciably with free memory going down to around 30mb. The system was very slow and not really usable.

I then flashed a new SD card, this time using the PI 2 / 32 bit version of i20240818, applied my settings as above and updated to the same Update branch version - again starting with 'Browser on RPi' disabled. The system was fine and quite usable as I had found with the 64 bit version, again with around 215mb of free memory. Enabling 'Browser on RPi' again showed the same slow down and the free memory was around 30mb BUT over time (may be 30 mins or so) the free memory gradually increased and at this point the system was still relatively slow but not,eventually, unusable.

It would seem that enabling 'Browser on RPi' on older systems has a detrimental effect on an otherwise performant system but the 32 bit OS 'appears' to recover over time - not sure why.

Chris

[R101G]

@ceejayemm
I think we are seeing two different problems here. The remote browser always works OK for me, but I do find the touch screen stops responding at all for a few seconds after a few operations, then recovers. I have seen some reports of problems with the latest version of the Raspberry Pi OS which are cured by reverting to the previous one, so perhaps a driver upgrade is causing this.

[ceejayemm]

Yes, the remote browser always works ok for me too - a bit slow if the 'Browser on RPi' is also enabled. The problems seem to start for me when the 'Browser on RPi' is enabled but I am using an older PI version than you are.

Chris