Mi Band: Transfering several days of data never completes #141

Closed
by 6arms1leg opened 6 years ago · 15 comments
6arms1leg commented 6 years ago (Migrated from github.com)
Owner

I didn't connect my Mi Band to the phone for about 10 days and now, when I try to syncronize, the process starts but never completes. With the new progress bar I can see that after approximately 3/4 into the process, the sync process starts from the beginning again.
I tried several times, but it always ends up in this sync loop.

Many thanks for your help!

Gadgetbridge: 0.6.2
FW: 1.0.10.14

I didn't connect my Mi Band to the phone for about 10 days and now, when I try to syncronize, the process starts but never completes. With the new progress bar I can see that after approximately 3/4 into the process, the sync process starts from the beginning again. I tried several times, but it always ends up in this sync loop. Many thanks for your help! Gadgetbridge: 0.6.2 FW: 1.0.10.14
Owner

Sorry to hear that. Quick question: do you see the progress bar stuck or does it keep looping?

Because today I noticed that the progress bar was stuck at some point for me as well (25 days to transfer) and I'll be able to debug this situation, whereas the continuous loop might be different.

Sorry to hear that. Quick question: do you see the progress bar stuck or does it keep looping? Because today I noticed that the progress bar was stuck at some point for me as well (25 days to transfer) and I'll be able to debug this situation, whereas the continuous loop might be different.
6arms1leg commented 6 years ago (Migrated from github.com)
Poster
Owner

Thanks for your fast reply.
Actually, I had both situations, but the sync progress bar loop happens far more often.
One or two times it was stuck and I had no way to gracefully cancel the process -- even after exiting Gadgedbridge the stuck sync progress bar was still there.

Thanks for your fast reply. Actually, I had both situations, but the sync progress bar loop happens far more often. One or two times it was stuck and I had no way to gracefully cancel the process -- even after exiting Gadgedbridge the stuck sync progress bar was still there.
Owner

See issue #142

See issue #142
Owner

I've added a change to #142 which hopefully improves this behavior.

I've added a change to #142 which hopefully improves this behavior.
6arms1leg commented 6 years ago (Migrated from github.com)
Poster
Owner

I've added a change to #142 which hopefully improves this behavior.

Many thanks for your effort! Your change did indeed improve the behavior. Unfortunately, it still does not fix it.
Now, on GB 0.6.4 the sync process doesn't freeze anymore, but after it completes the transferred data (~ 30 days) is incomplete. If I try to sync again afterwards, it starts to (try to) transfer all data (~30 days) again (well, at least the status messages are similar: something like "Transferring 30d [...] of data"). After that second run, the data is still incomplete and I can repeat the step over and over again, always with the same result.

BTW: I didn't even know that the Mi Band can store that amount of data.

> I've added a change to #142 which hopefully improves this behavior. Many thanks for your effort! Your change did indeed improve the behavior. Unfortunately, it still does not fix it. Now, on GB 0.6.4 the sync process doesn't freeze anymore, but after it completes the transferred data (~ 30 days) is incomplete. If I try to sync again afterwards, it starts to (try to) transfer all data (~30 days) again (well, at least the status messages are similar: something like "Transferring 30d [...] of data"). After that second run, the data is still incomplete and I can repeat the step over and over again, always with the same result. BTW: I didn't even know that the Mi Band can store that amount of data.
Owner

@6arms1leg sorry for the basic question: Is
settings -> miband settings -> Do not confirm... (at the end of the list)
checked? Because if it is, then what you experience is perfectly normal, as the data will never be deleted from the band by GB.

@6arms1leg sorry for the basic question: Is settings -> miband settings -> Do not confirm... (at the end of the list) checked? Because if it is, then what you experience is perfectly normal, as the data will never be deleted from the band by GB.
6arms1leg commented 6 years ago (Migrated from github.com)
Poster
Owner

Woops, my bad. 🙊 Sorry for the noise. The option is indeed checked.
I thought this option meant that the data (only) gets deleted after a successful transfer...

Hmm, still strange that the transferred data seemed incomplete. Especially the current day's activity graph only showed data starting from the first sync attempt. Data from earlier that day seemed missing.
Additionally, the current day's sleep graph showed ~23h of light sleep, while I was quite active that day. But I guess that's an issue with the Mi Band's activity algorithm... or does GB process the data in any way?
The week's activity overview was quite accurate, though.

Well, I will check on it later again, when my Mi Band generated some new data (with above option unchecked).

Woops, my bad. :speak_no_evil: Sorry for the noise. The option is indeed checked. I thought this option meant that the data (only) gets deleted after a successful transfer... Hmm, still strange that the transferred data seemed incomplete. Especially the current day's activity graph only showed data starting from the first sync attempt. Data from earlier that day seemed missing. Additionally, the current day's sleep graph showed ~23h of light sleep, while I was quite active that day. But I guess that's an issue with the Mi Band's activity algorithm... or does GB process the data in any way? The week's activity overview was quite accurate, though. Well, I will check on it later again, when my Mi Band generated some new data (with above option unchecked).
Owner

No problem @6arms1leg , @cpfeiffer reworded the option to make it clearer (I'm not that good in naming things, apparently ;-) ).

There are some issues when the option is checked, without going too technical let's say that sometimes the miband shifts its time for a few seconds, and GB gets duplicate samples for each minutes. The graphs however expects a single sample per minute, and things can get weird. The good news is that the data can be reconciled.

No problem @6arms1leg , @cpfeiffer reworded the option to make it clearer (I'm not that good in naming things, apparently ;-) ). There are some issues when the option is checked, without going too technical let's say that sometimes the miband shifts its time for a few seconds, and GB gets duplicate samples for each minutes. The graphs however expects a single sample per minute, and things can get weird. The good news is that the data can be reconciled.
6arms1leg commented 6 years ago (Migrated from github.com)
Poster
Owner

OK, now with the option unchecked, it works nicely. Many, many thanks!
As far as I'm concerned, this issue can be closed.

Is the implementation of the sync process' progress bar dropped now? I quite liked the progress bar – it gives a useful estimate for the remaining time on long sync processes...

OK, now with the option unchecked, it works nicely. Many, many thanks! As far as I'm concerned, this issue can be closed. Is the implementation of the sync process' progress bar dropped now? I quite liked the progress bar – it gives a useful estimate for the remaining time on long sync processes...
Owner

The progress bar should still be there (in the notification area -- not inside Gadgetbridge, unfortunately.

The progress bar should still be there (in the notification area -- not inside Gadgetbridge, unfortunately.
6arms1leg commented 6 years ago (Migrated from github.com)
Poster
Owner

Hmmm, when I checked the progress bar seemed to be missing.

Hmmm, when I checked the progress bar seemed to be missing.
Owner

Weird, it's still there for me. Did you update your OS or change some configuration wrt the notification area? Some code has changed regarding the transfer and progress (cee03debbb), but that was mainly a refactoring and still contains the progress handling. I suggest you try the next release and open a new issue regarding the missing progress bar, in case it's still missing. That's unrelated to the data sending anyway.

Weird, it's still there for me. Did you update your OS or change some configuration wrt the notification area? Some code has changed regarding the transfer and progress (cee03debbb2b8226713f11813a1d765a089dd829), but that was mainly a refactoring and still contains the progress handling. I suggest you try the next release and open a new issue regarding the missing progress bar, in case it's still missing. That's unrelated to the data sending anyway.
6arms1leg commented 6 years ago (Migrated from github.com)
Poster
Owner

Thanks for your help!
No, I didn't change anything on my device within that time. I tried the next release of GB, but it's still missing. I opened a new issue (#155).

Thanks for your help! No, I didn't change anything on my device within that time. I tried the next release of GB, but it's still missing. I opened a new issue (#155).
6arms1leg commented 6 years ago (Migrated from github.com)
Poster
Owner

Sorry to dig this issue up again, but after further tests, I found this is still an issue (sometimes).

  • On long syncs, the process takes longer than the screen lock timeout. The screen lock interferes with the sync process for me. Even more severe: The Mi Band gets disconnected and I can't reconnect afterwards. Only when I try to connect several hours later it works again.
  • Sometimes the sync process still doesn't complete, although I disabled the screen lock (or keep touching the screen to prevent the screen lock). After another sync attempt (after disconnecting manually), GB finishes the sync process, but no new data or only fractions of it were transferred with GB showing weird stats like 20 min total sleep time on the sleep screen, 5 steps or 170.000 steps a day on the weeks overview graph.
Sorry to dig this issue up again, but after further tests, I found this is still an issue (sometimes). - On long syncs, the process takes longer than the screen lock timeout. The screen lock interferes with the sync process for me. Even more severe: The Mi Band gets disconnected and I can't reconnect afterwards. Only when I try to connect several hours later it works again. - Sometimes the sync process still doesn't complete, although I disabled the screen lock (or keep touching the screen to prevent the screen lock). After another sync attempt (after disconnecting manually), GB finishes the sync process, but no new data or only fractions of it were transferred with GB showing weird stats like 20 min total sleep time on the sleep screen, 5 steps or 170.000 steps a day on the weeks overview graph.
Owner

Thanks for sharing your observations n

  1. sync is much faster with current git (not yet released to f-droid)
  2. do you mean the black screen saver or really the lock screen where you have to enter pin, password or pattern?
    I never had interference with the screen saver, but didn't check with the lock screen yet.
    Maybe we need to as a wake lock so that the system doesn't disturb us. I'll read up on this. A log could help to find out whether the disconnection was caused by android rather than the mi.
  3. I'm sorry for the long reconnection process. Don't know whether it's Android's Bluetooth stack of the mi that's confused.
  4. and I'm really sorry for the bogus data afterwards. Is really like to find or have that can happen. The samples have a timestamp which is used as a unique ID, so even if you get the and sample multiple times, the data shouldn't accumulate. Either there's a big in there, maybe in relation to sqlite, or the timestamp changes for some unknown reason.
Thanks for sharing your observations n 1) sync is much faster with current git (not yet released to f-droid) 2) do you mean the black screen saver or really the lock screen where you have to enter pin, password or pattern? I never had interference with the screen saver, but didn't check with the lock screen yet. Maybe we need to as a wake lock so that the system doesn't disturb us. I'll read up on this. A log could help to find out whether the disconnection was caused by android rather than the mi. 3) I'm sorry for the long reconnection process. Don't know whether it's Android's Bluetooth stack of the mi that's confused. 4) and I'm really sorry for the bogus data afterwards. Is really like to find or have that can happen. The samples have a timestamp which is used as a unique ID, so even if you get the and sample multiple times, the data shouldn't accumulate. Either there's a big in there, maybe in relation to sqlite, or the timestamp changes for some unknown reason.
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.