-
• #52
Do you plan to add flow control to the play store version as well?
Yes - I talked about this in another thread but Google changed the Play Store rules to we had to change the 'API version' when uploading updates, and that potentially causes other issues with Gadgetbridge so it all needs to be checked out thoroughly - otherwise I risk breaking everything :)
-
• #53
Running latest Gadgetbridge 0.80.0-banglejs from F-Droid and latest Firmware 2v21 on my Bangle2. Since some weeks(?) I see these two annoying messages "FIFO_FULL" and "MEMORY_BUSY". My collection of apps is unchanged since a long time - so could be related to some recent updates ... Any advice?
-
• #54
Well, the two errors are a bit different:
- FIFO_FULL means Gadgetbridge was trying to send a bunch of data to the watch and it was too busy to receive it - that shouldn't normally happen as Gadgetbridge should implement flow control, so I'm not sure what's up there. It'd be interesting if you get the error with the play store version?
- MEMORY_BUSY happens when something inside Bangle.js is trying to allocate variables while the Bangle is doing garbage collection. I have seen this when using the
Pebble++
clock but I'm afraid I haven't been able to track it down (it'll be a firmware issue). If you or anyone has found a way to reproduce this I'd be extremely interested!
- FIFO_FULL means Gadgetbridge was trying to send a bunch of data to the watch and it was too busy to receive it - that shouldn't normally happen as Gadgetbridge should implement flow control, so I'm not sure what's up there. It'd be interesting if you get the error with the play store version?
-
• #55
Just a note that I may have finally fixed the remaining MEMORY_BUSY error on cutting edge builds (the fix will be in 2v22). It was related to the Health event that occurs every 10 minutes - it had to check daylight saving time to see if it was midnight or not, and it seems that caused the issue
-
• #56
I actually got the fifo_full again every other night when I switched to my new S24 Ultra. Using the latest F-Droid GB. Large MTU is disabled.
-
• #57
The fifo_full isn't related to my memory_busy fix. If you can get any Gadgetbridge logs that would be handy - there should ideally be
RX: XOFF
andRX: XON
lines which are received as Gadgetbridge is told to start or stop transmission. -
• #59
Thanks! I've just got the log and taken a look at it
The FIFO_FULL has happened while trying to sync your calendar. It seems like it probably won't cause a big problem as things will resync after a bit and fix any issues, but still it's annoying.
It seems XOFF is sent by Bangle.js in one message, and then received by Gadgetbridge, but pretty much immediately we also get the FIFO_FULL message (despite it taking another 1500 bytes/75 transmit calls) to fill up the buffer (Gadgetbridge would appear to be sending around 4k in one chunk)
So what appears to be happening is Gadgetbridge is sending a bunch of data and isn't checking for any responses until it's done, by which time it's too late. I've filed an issue on Gadgetbridge for this: https://codeberg.org/Freeyourgadget/Gadgetbridge/issues/3794
-
• #60
Plausible. I have a tool that each morning loads an ics, deletes a calendar and loads the data fresh from the ics.
Though, I have the "Sync Calendar events" option disabled in the GB watch settings. Is that setting somehow not recognized? I would expect having it disabled, GB won't transfer calendar events to the watch at all... -
• #61
Plausible. I have a tool that each morning loads an ics, deletes a calendar and loads the data fresh from the ics.
Ok, that'll be it then. I can see it pushing ~30 calendar changes at least.
The log shows
CalendarReceiver - Syncing with calendar.
and as far as I can see CalendarReceiver can't be turned off!I've just made some changes to Gadgetbridge to make it more likely to honour that setting though (it now ignores CalendarReceiver if calendar sync is turned off) so the next nightly build should have the fix.
If you update the Bangle.js Android app from the latest cutting edge it also attempts to sync the calendar in a more efficient way which I'd hope would be a little faster - although it seems like it's not the Bangle requesting a sync - it's CalendarReceiver that's pushing the data to it in which case we don't have much control over it.
Answer here 🙂: https://forum.espruino.com/comments/16880098/