Reverse-geo ratelimit pauses location publishes about android

[ckrey]

Ignore, as described in owntracks/quicksetup#36 the location publishes stopped because the MQTT user password was changed

[GitHubQueenn]

Ignore, as described in owntracks/quicksetup#36 the location publishes stopped because the MQTT user password was changed

Not sure about that because even after changing the passwords and re-importing configs, it worked even after that for a bit, but the main point was having to wait hours for it to update all the missed locations from when it wasn't publishing them:

Well, during those 4hrs of being rate limited, it was still logging my movements locally, so once it connected again (via Google), it started posting all of the movements for those 4hrs in intervals of ~3s or so until it caught up to the current time. Meaning, I couldn't see any live locations until these hours of missed progress were updated to the map and the time caught up. Here is a video showing it updating/catching up from 12 in the afternoon, when it was 4PM at this point: https://i.imgur.com/gHrDIfk.mp4

Would it be possible to have this happen in the background while I can still see the actual live locations? Waiting for 4hrs of updates (would've been much longer if I didn't realize it was rate limited) was brutal and very inconvenient when I really needed to see a live location at that moment, but couldn't. I also just now noticed since my friend and I re-imported the config files to the app, they can no longer see me as a Friend but I can see them still. Not sure why. Sorry for the long text. Thanks!

[growse]

Are you using http or MQTT?

[jpmens]

They are using MQTT, but this is a non-issue: the log at owntracks/quicksetup#36 clearly indicates connection didn't succeed due to incorrect credentials.

[growse]

I only ask because my client dumps a few thousand queued locations to the broker in under a minute, so don't know where 4 hrs is coming from.