Frameo: WebView stops displaying pictures after dim hours

[fraggar]

Version

1.0.47.0

Deployment Method

Android v6.0.1 (Frameo)

Description

I have been noticing that the WebView stops displaying pictures at random or after dim hours.

After initially struggling with the setup of ImmichFrame, I followed the guides in here and updated the WebView apk to 106 and managed to get the app running well. However it seems that the app stops working at random, displaying the error "Looks like your immich-server is offline or you misconfigured immichFrame, check the container logs."

I don't seen any issues when logging in to my ImmichFrame URL on my PC or mobile and the container logs for both the server or frame do not show any particular error logs.

Reproduction

I have been following the error for a few days trying to chase the issue without success. I now have been trying to get the device logs directly with adb logcat com.immichframe.com to see if I can spot anything but I can't really understand what the logs may show. The only thing I can get is that it seems there is an SSL error which should not be the case, as the URL could load correctly before.

Here is an excerpt of the logs after dim hours and trying to reload WebView (via downward swipe), without power-cycling the frame:

02-03 02:10:22.970   706   706 I Binder_7: type=1400 audit(0.0:142): avc: denied { ioctl } for path="socket:[9096]" dev="sockfs" ino=9096 ioctlcmd=7704 scontext=u:r:system_server:s0 tcontext=u:r:system_server:s0 tclass=unix_stream_socket permissive=1
02-03 02:10:22.970   706   706 I Binder_7: type=1400 audit(0.0:143): avc: denied { ioctl } for path="socket:[9096]" dev="sockfs" ino=9096 ioctlcmd=7704 scontext=u:r:system_server:s0 tcontext=u:r:system_server:s0 tclass=unix_stream_socket permissive=1
02-03 02:10:23.996   678   857 E chromium: [ERROR:ssl_client_socket_impl.cc(983)] handshake failed; returned -1, SSL error code 1, net_error -201
02-03 02:10:26.410 20137 20137 I daemonsu: type=1400 audit(0.0:144): avc: denied { dyntransition } for scontext=u:r:daemonsu:s0 tcontext=u:r:init:s0 tclass=process permissive=1

What I have noticed in the morning, when the display should resume showing ImmichFrame, there is instead a tiny android peeking from the top left corner, which leads me to believe there was an internal error.

I just ran a quick test while directly plugged to the frame and simulated a dim range from 12:00 to 12:02 and the display resume without issues Which now leaves me with even more doubts whether this is a network issue on my end, or an issue with the APK.

Expectations

After dim hours, pictures should be displayed again and if there is an error loading, the service should re-attempt to load after some time.

Currently my only solution is to power-cycle the frame and usually it works, but as this is intended as a gift, I would rather have it to recover from connectivity issues in a more reliable way.

Configuration

Logs

Pre-Submission Checklist

• This is a bug report and not a feature request

• I have provided all of the required information to reproduce the bug (config, logs, etc.)

• I have checked for related issues and checked the documentation

[3rob3]

Are you using a reverse proxy?

[fraggar]

I am, in fact. I have traefik setup, I haven't had any major issue with other services though, do you think that could be the culprit?

[fraggar]

Looking at the traefik logs, I am just noticing now that certs are being renewed every evening between 21-23hrs, which leads me to believe that could be what's breaking things. So if I am understanding correctly, the issue is coming up when the SSL handshake fails due to outdated certs in Frameo.

[3rob3]

Correct, that's what i suspected. The cert it first got does not match the updated one. When the device goes dim we load about:blank. When it comes back we load your url. I suspect Android has the cert still "cached" and uses it, which now doesn't match. Coincidentally i recently setup a reverse proxy and my mom's frame at her house is behaving the same, so likely I have same issue. Surprised no-one else has reported this.

I'll see if I can handle this in Android App. I'm going to move this to that project.

[fraggar]

Alright, that does make sense, cool that the issue got spotted rather quickly, thanks for the feedback!