Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exported data isn't accurate. #1770

Open
Estebiu opened this issue Nov 27, 2023 · 9 comments
Open

Exported data isn't accurate. #1770

Estebiu opened this issue Nov 27, 2023 · 9 comments
Labels
potential bug A bug that could not (yet) be reproduced

Comments

@Estebiu
Copy link

Estebiu commented Nov 27, 2023

I recently switched phones, and found that exporting my workouts from the old one to the new one resulted in some slightly incorrect data.

To Reproduce

  1. Export Workouts (tried exporting as kml and gpx, as a single file or as multiple files,no difference)
  2. Open statistics;
  3. See difference between in the distance and time fields between data before and after exporting
    Old phone:
    image
    New Phone:
    image

How a track's info looks:
Old phone:
image
New phone:
image

Technical information

  • Device: Old phone: Redmi Note 5 Pro; New Phone: Redmi Note 12
  • OS: Old phone: Lineage 20; New phone: Miui14
  • OpenTracks version: Both 4.9.5
@Estebiu Estebiu added the potential bug A bug that could not (yet) be reproduced label Nov 27, 2023
@dennisguse
Copy link
Member

That is kind of expected.
Some time ago the computation of the track statistics was changed.

However, updating the existing statistics is relatively complicated and we skipped this.
And on the re-import, the new algorithm is used.

PS might even be more than one change.

@dennisguse dennisguse added the wontfix This will not be worked on label Nov 27, 2023
@dennisguse
Copy link
Member

IIRC

  • we didn't count some distance between certain points (no clue actually why)
  • speed is now derived from traveled distance rather from GPS
    ... and there may be some more.

It is really tricky to keep all these parts identical and this is often not worth the effort (or rather everything else is more important).

PS/ nicely written bug report 👍
PPS/ quite some traveling with OpenTracks 🌻

@Estebiu
Copy link
Author

Estebiu commented Nov 28, 2023

I don't mind the slight difference in the traveled kms, but can't something be done with the total/moving time? After importing the files the "paused" time converts to being "moving" time, which messes up also the "average speed" statistic.

EDIT: The max speed is also way bigger.. Sure, I'm fast, but I don't think that I did 216km/h on my bike..

@dennisguse
Copy link
Member

Mhh. There was another change: how idle is handled.
Now, idle events are stored as an extra point (using a timer) instead of being decided by if the speed is below a certain threshold.
IDLE: If no movement happened within a defined time frame.

I am not sure, but there should be some code for importing that also handles IF no idle points are present.

@dennisguse dennisguse reopened this Nov 28, 2023
@dennisguse dennisguse removed the wontfix This will not be worked on label Nov 28, 2023
@Estebiu
Copy link
Author

Estebiu commented Nov 28, 2023

That would be perfect :D
Thanks for reopening.

@dennisguse
Copy link
Member

Is guess the relevant code is in the TrackImporter.

@voklav
Copy link

voklav commented Feb 15, 2024

Well,
even in with latest version ... Recorded. -> Exported -> Deleted -> Imported in the same phone that was recorded ... and moving time and total time are the same.

@dennisguse
Copy link
Member

@voklav did this happen with a recording done with OpenTracks v4.11.X?
And if not can you try it again?

@voklav
Copy link

voklav commented Mar 17, 2024

@voklav did this happen with a recording done with OpenTracks v4.11.X? And if not can you try it again?

I am extremely sorry for replying so late.
But there are no problems with the new versions.
New to new - everything is fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
potential bug A bug that could not (yet) be reproduced
Projects
None yet
Development

No branches or pull requests

3 participants