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

mytourbook Tour values don't match Training Centre or the unit #217

Closed
ghost opened this issue Aug 5, 2020 · 59 comments
Closed

mytourbook Tour values don't match Training Centre or the unit #217

ghost opened this issue Aug 5, 2020 · 59 comments

Comments

@ghost
Copy link

ghost commented Aug 5, 2020

Hello, you happy for me to report an issue here rather than sourceforge?

I recently began using mytourbook. It's really rich which is terrific, well done.

I'm having some issues with the data as represented on the unit or Training Centre not displaying identically in mytourbook. This happens regardless of whether I'm using version openjdk-11 or 8 or 14 for that matter. It happens in the latest version as well as the previous version of mytourbook.

Below is an example, each year was backed up to a .tcx file from Training Centre and then imported to mytourbook. The backups contains both .tcx and .fit rides.

mtb

When I look at the individual Tours the distance is usually about right but the time is off, often by a minute or more meaning the average speed is also off. As you can see it's not always the case it's near-enough correct because the total distance for the period is off by about 3 miles.

If I take a .fit file directly from an Edge 500, a .tcx file from an Edge 705 or a .tcx file from a Forerunner 205 the data doesn't display the correct values as displayed on the unit and Training Centre.

500 .fit with the Training Center values below the mytourbook values.

MTB17thfit
TC17thfit

705 .tcx

TC24th705tcx
MTB24th705tcx

205 .tcx

MTB22nd205tcx
TC22nd205tcx

What's to be done here!

Thank you

*edited for grammar

@ghost ghost changed the title mytourbook Tour values don't match Training Centre or the unit's mytourbook Tour values don't match Training Centre or the unit Aug 5, 2020
@FJBDev
Copy link
Collaborator

FJBDev commented Aug 5, 2020

First off, in my own experience, you will never find for any given activity, the same distance from a software to another. I bet you if you were to take your activities and import them into other softwares/platform, you will get different numbers.

Now, MT shows a total of 3272.19 while "Training Centre" (is it Garmin Training Centre?) shows 3275.51over roughly 4 years.
That's about 0.1% difference over 4 years.... is that really a big deal ?

As for the time, it seems that you are comparing moving time with total time. Moving Time = Total Time - Break Time
Considering that the Break time uses an algorithm that can be tweaked by the users, I would say you should compare total time with Total Time so that in the end you dont compare apples and oranges.

image

I hope that helps!
Frederic

@ghost
Copy link
Author

ghost commented Aug 5, 2020

Thanks for responding so quickly. I'm sorry this response is so long but I want to ensure I'm clear.

I haven't decided if it's a big deal yet for me - it might be - it's more that I wanted to know if I'd done something wrong. Or if there was a known issue concerning these file types.

So far as I can tell, I'm not confusing Moving time with Recording time (You said total time, I assume you are referring to Recording time in mytourbook). If I was confusing Recording time with Moving time as you say, the value in the Training Centre screenshot would be larger than the time in the mytourbook screenshot. The mytourbook time values are only ever larger, I've yet to see a Tour where the Training Centre time value is larger which might give credence to your assumption. Correct me if I'm wrong.
Training Centre doesn't have a field for "Recording time", nor does the Edge 500 allow me to view that. I haven't looked at the 705 or 205. In Garmin Connect they have multiple fields distinguishing between Moving time and Recording time though they call that Elapsed Time.

Here is the Edge 705 from the 24th July as screenshot above.

[1]
one

The figure is 31:48, which is exactly what mytourbook reports as Recording time.

These are the headline figures from the same page.

[2]
two

So it stands to reason that I'm not confusing the two as the units, Training Centre and Connect match and give the user the information they actually want to see, Moving time, rather than useless information, Recording/Elapsed time.

Concerning Break time and it's relevance to this issue, I believe that's a tool for users who don't have or don't use a feature on their device triggering a stop of moving time automatically. Is that correct? If true, I have no need for such a feature because my Garmin units are setup to stop recording automatically once my speed is below a certain value. It's enhanced by my using a speed & cadence sensor. Predicated on all that, the Break time feature could be a significant contributor to this issue couldn't it? Duplicating work already done. I don't understand why these files require any processing at all, for me especially everything required to correctly display a given journey is contained within the xml. On that basis it might be good to see what happens if the Break time feature was switched off. Is that possible?

Links
[1] https://user-images.githubusercontent.com/42522540/89449536-bf943600-d748-11ea-811d-33a410b172b8.png
[2] https://user-images.githubusercontent.com/42522540/89450708-7c3ac700-d74a-11ea-867e-27e00a999871.png

@FJBDev
Copy link
Collaborator

FJBDev commented Aug 5, 2020

Thanks for responding so quickly. I'm sorry this response is so long but I want to ensure I'm clear.

No worries, the clearer the better :-)

I haven't decided if it's a big deal yet for me - it might be - it's more that I wanted to know if I'd done something wrong. Or if there was a known issue concerning these file types.

I don't think you did anything wrong. Try on another software/online platform and I bet you the distance will be different. Not drastically different but you will see 1/10th to 1/100th of miles differences

So far as I can tell, I'm not confusing Moving time with Recording time (You said total time, I assume you are referring to Recording time in mytourbook). If I was confusing Recording time with Moving time as you say, the value in the Training Centre screenshot would be larger than the time in the mytourbook screenshot. The mytourbook time values are only ever larger, I've yet to see a Tour where the Training Centre time value is larger which might give credence to your assumption. Correct me if I'm wrong.
Training Centre doesn't have a field for "Recording time", nor does the Edge 500 allow me to view that. I haven't looked at the 705 or 205. In Garmin Connect they have multiple fields distinguishing between Moving time and Recording time though they call that Elapsed Time.

Training Centre (aka your screenshot) DOES have a field Recording Time and it's called Elapsed Time. But like I said, in your MT screenshot, you were looking at Moving Time which will typically always be different than the Moving Time in MT because the one in MT is using a specific algorithm.

Here is the Edge 705 from the 24th July as screenshot above.

[1]
one

The figure is 31:48, which is exactly what mytourbook reports as Recording time.

These are the headline figures from the same page.

[2]
two

So it stands to reason that I'm not confusing the two as the units, Training Centre and Connect match and give the user the information they actually want to see, Moving time, rather than useless information, Recording/Elapsed time.

Concerning Break time and it's relevance to this issue, I believe that's a tool for users who don't have or don't use a feature on their device triggering a stop of moving time automatically. Is that correct? If true, I have no need for such a feature because my Garmin units are setup to stop recording automatically once my speed is below a certain value. It's enhanced by my using a speed & cadence sensor. Predicated on all that, the Break time feature could be a significant contributor to this issue couldn't it? Duplicating work already done. I don't understand why these files require any processing at all, for me especially everything required to correctly display a given journey is contained within the xml. On that basis it might be good to see what happens if the Break time feature was switched off. Is that possible?

It is not possible at the moment to switch off the Break time feature.

Links
[1] https://user-images.githubusercontent.com/42522540/89449536-bf943600-d748-11ea-811d-33a410b172b8.png
[2] https://user-images.githubusercontent.com/42522540/89450708-7c3ac700-d74a-11ea-867e-27e00a999871.png

If I understand correctly, I think what you are looking for and not seeing in MT is the "Time" (term from Traning Centre) or what I call "Recorded Time" which is equal to Total Time - Paused times (with paused times being the user-triggered pauses)

If this is right, then this is the same discussion Gur launched here and that I am working on for the upcoming release. And that will look like this

image

Am I correct ?

@ghost
Copy link
Author

ghost commented Aug 5, 2020

Based on what you say here, Recorded Time is what the unit reports during an activity.

I see this displayed in Training Centre in the "Total Time" field and in Garmin Connect, in the "Time" field. This is what I would like replicated or made available in MT.

Does this mean then that it's not currently possible to use see recorded time, as defined at that link as a field instead of the current Moving Time as pictured?

three

@FJBDev
Copy link
Collaborator

FJBDev commented Aug 5, 2020

Does this mean then that it's not currently possible to use see recorded time, as defined at that link as a field instead of the current Moving Time as pictured?

Correct, as of MT 20.8, the only data available is
Recording Time : Total time of the activity
Moving Time : Calculated time "moving" based on the specified algorithm chosen by the user
Break Time: Recording Time - moving Time.

As I mentioned above, I am working on that for (hopefully) the upcoming release as I have wanted to have access to that data myself for a while now. It's a complicated feature because it requires to import such data from a multitude of file formats (FIT, TCX, Suunto XML, SML, JSON....etc) and also required to do a lot of UI/text/menus changes

@ghost
Copy link
Author

ghost commented Aug 5, 2020

I would have thought everyone would want what their unit displayed replicated in the database so it's surprising it apparently hasn't been requested as a feature more. It's the main thing I want, anything more is a bonus.

As you say it looks like a complicated feature to implement, it'll really enhance mytourbook when it's done though.

@FJBDev
Copy link
Collaborator

FJBDev commented Aug 5, 2020

Indeed, i was surprised myself when I discovered MT 2 years ago that this data was not available and while I had thought about adding it since that time, Gur's request convinced me I needed to do it 😄

But then at the same time, if you look at Strava (LOTS/MILLIONS of users..), this data doesn't seem available so maybe not everyone wants/needs it ?

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 11, 2020

@condemnedmeat

I have just implemented the support of recorded and paused time in MyTourbook, would you be interested in having access to a development build so you can test it and let me know if that looks good and if anything needs to be "polished"/modified before that actual release ?

You can see more info of my work here

Let me know
Frederic

@ghost
Copy link
Author

ghost commented Sep 12, 2020

Brilliant!

Yes I'm happy to test it out. Thanks very much!

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 12, 2020

Cool, I have created a development build that you can download here and install locally.

VERY IMPORTANT: You MUST NOT use your current 20.8 MyTourbook database because any changes in this test (development) version, e.g. tour database version, can cause lots of troubles when you install again the current official released version.
If you REALLY want to use your current 20.8 MyTourbook database, PLEASE BACKUP your database first as this build is NOT an official release. That way, once you uninstall it and install the official 20.8 release again, you can restore your data unaltered.

See the official documentation here on how to backup the database

Let me know
Frederic

@ghost
Copy link
Author

ghost commented Sep 15, 2020

Sorry for the delay in supplying some feedback Frederic.

So, I imported tours, then reimported tours - Only tour pauses. .Fit files worked which is brilliant, the small sample I have matched their time in Training Centre once re-imported. Unfortunately I couldn't get .tcx files to display in the "Total recorded time excluding pauses" column. They would always say "Previous data 0:00:00. Current Data: 0:00:00" in the Tour Log.
I tried exported .tcx from Training Centre, .tcx from an Edge 205 and Edge 705.

I made a couple of other observations, I deleted the derby database several times while testing, with the aim of resetting the program - in the sense that there were no tour files - but the reimports were persistent. I.e deleting the database cleared tour files, when I imported the .fit files again they automatically used the new recorded time column without me needing to reimport again. I assume this is expected behaviour but i thought I'd mention it just in case it isn't.
The "Reimported tours (or parts of them)" window took 5 minutes to re-import 136 tours. I mention in case that is slower than expected.

@wolfgang-ch
Copy link
Collaborator

I just reimported 103 .fit files in 40 seconds with a Thinkpad P50 and Win10

@ghost
Copy link
Author

ghost commented Sep 15, 2020

These were a .tcx backup. It may be to do with that because re-importing the five .tcx files I have to hand took 2.1 seconds. It's a small sample but that would be about a minute scaled up for 136 files.

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 15, 2020

Sorry for the delay in supplying some feedback Frederic.

Thanks for testing condemnedmeat!

So, I imported tours, then reimported tours - Only tour pauses. .Fit files worked which is brilliant, the small sample I have matched their time in Training Centre once re-imported. Unfortunately I couldn't get .tcx files to display in the "Total recorded time excluding pauses" column. They would always say "Previous data 0:00:00. Current Data: 0:00:00" in the Tour Log.
I tried exported .tcx from Training Centre, .tcx from an Edge 205 and Edge 705.

Weird... I have tried with TCX and it worked. Could you please attach 1-2 of your TCX files so I can look at them ?

I made a couple of other observations, I deleted the derby database several times while testing, with the aim of resetting the program - in the sense that there were no tour files - but the reimports were persistent. I.e deleting the database cleared tour files, when I imported the .fit files again they automatically used the new recorded time column without me needing to reimport again. I assume this is expected behaviour but i thought I'd mention it just in case it isn't.

Not sure I fully get what youre saying but with the new version of MT, you won't need to reimport new tours, the paused time will be imported when you import any tours going forward. The Reimport feature is only useful for tours imported in MT <= 20.8

@ghost
Copy link
Author

ghost commented Sep 15, 2020

Not sure I fully get what youre saying but with the new version of MT, you won't need to reimport new tours, the paused time will be imported when you import any tours going forward. The Reimport feature is only useful for tours imported in MT <= 20.8

My mistake, I was importing and re-importing. I didn't pay close enough attention to the opening comment.

I can send you a couple of .tcx files by email or another private means. I have a users.noreply.github.com address of yours and can email there if that would work.

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 15, 2020

My mistake, I was importing and re-importing. I didn't pay close enough attention to the opening comment.

Oh ok, that makes sense now. Indeed, you don't need to reimport new tours. The new tours will automatically have the pauses imported :-)

I can send you a couple of .tcx files by email or another private means. I have a users.noreply.github.com address of yours and can email there if that would work.

No, that's not a valid email. Can you put the files on a dropbox folder ?

@ghost
Copy link
Author

ghost commented Sep 15, 2020

I sent you a private message

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 15, 2020

I sent you a private message

Hmmm, I haven't received anything

@ghost
Copy link
Author

ghost commented Sep 15, 2020

I received a copy of it in my inbox almost immediately after sending, 30mins ago. It goes via a users.sourceforge.net address.

Have a look about, otherwise you can allow anyone to send mail to your users.sourceforge.net address from here and I can just send you an email from a private account. I've just tested that works. I wouldn't post a link publicly.

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 15, 2020

Ok, I have checked the option to "Allow anyone to send mail to "

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 15, 2020

@condemnedmeat Let me know when you have sent the email again, I still have not received anything.
Otherwise, you can also attach them to this discussion thread like Gur did (if you are ok with having your tcx file publicly available)

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 15, 2020

I have just received your email with the files, I will look at them and let you know, thanks!

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 15, 2020

I take that back :-(
The link you gave me doesn't seem to work
image

@ghost
Copy link
Author

ghost commented Sep 15, 2020

I did some more testing and took advantage of you not receiving the original email to change what I sent you. I emailed another link a few moments ago.

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 15, 2020

Ok, that makes sense. I look forward to receiving the files.

@ghost
Copy link
Author

ghost commented Sep 16, 2020

I have just received your email with the files, I will look at them and let you know, thanks!

I think actually you must have received the email I sent privately. It looks like dropbox is getting confused. Clicking the link from within the email here redirects to the old link. Copy and paste it and it'll work.

Edit - To save everyone's patience I created another link and emailed you again! 😆

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 16, 2020

Ok, i received it and it worked this time, thanks !

Now, I've looked at the files but I don't see any pauses in your 4 activities, is that right ?

What I've seen in other TCX files is a pause that was represented as a Lap with a distance of 0 meters as below :


StartTime="2020-05-23T15:37:18Z">
        <TotalTimeSeconds>8.8929999999999989</TotalTimeSeconds>
        <DistanceMeters>0</DistanceMeters>
        <MaximumSpeed>0</MaximumSpeed>

And in your files there is none of that.

Now, it's possible that the TCX format has several ways of representing pauses.
Maybe you could tell me for each file where are the times of the pauses so I can look for them in the files ?

Thanks

@ghost
Copy link
Author

ghost commented Sep 17, 2020

That was quick! 👍

So, some feedback after testing.
Might it be the case that something has changed with the importing of .fit files in the new development build. I only have two files to hand, they matched Training Centre in the old development build at 42:57 & 54:33 but in the new version they import as 42:51 & 54:28 respectively. I double checked this by uninstalling the new version and re-installing the old.

The .tcx imports are pretty good, I think your work has been a success so far. The 7 mile ride mentioned in the opening comment now comes in at 29:05 when it should be 29:22.81. The run matches Training Centre now, to the second. Having done a lot of comparisons, It is almost always the case mtb is interpreting a .tcx's time lower than Training Centre. This leads to a small but important difference in the sum total time when comparing mtb and Training Centre. I initially thought the reason for this was that a .tcx file that includes laps & stoppages was not importing as faithfully as one without laps. That can't of course be the case because the files I sent you are off and they don't include laps. I wonder if it's for the same reason the .fit files are off in this build. I really wish the difference in time was smaller.

The sum total distance is more or less the same between Training Centre and mtb. I think previously, mtb was setup to ignore invalid files and that meant there was a larger difference between the two.

I found some more .tcx files that don't import data in the new column. These feature </track> followed by <Extensions>. I've yet to understand what that means but I note the schema includes a variety of terms, including <Extensions>, under xsd:sequence. I assume all these terms can feature in a .tcx file, does mtb know how to interpret them all? This is not quite right, need to spend more time looking at them to understand how they differ to the files I sent you.

@ghost
Copy link
Author

ghost commented Sep 17, 2020

At the moment I'm manually calculating the stoppages and elapsed time for sample .tcx and comparing it with mtb & Training Centre as it's a more objective way to test implementation.

@ghost
Copy link
Author

ghost commented Sep 17, 2020

I'm content that the files exported from Training Centre are importing into the "Total recorded time excluding pauses" column accurately. The Elapsed time in mtb is accurate as well. While TC displays data in the same way as the units, the timing data comes out differently if you open up the file and manually subtract stoppages from elapsed time, mtb imports more faithfully to that which I'm happy with.

I have found that .tcx that have come from the unit import with an accurate elapsed time but the recorded time excluding pauses is out, usually by about 6-10 seconds per activity, compared with manually subtracting stoppages from elapsed time. This was the case with 4/5 .tcx I had to hand. This might be because I only provided .tcx exported from Training Centre, I can provide .tcx and .fit from a Garmin unit if you wish. Certainly .tcx from a Garmin unit mark stoppages in the same way as the exported files shared with you but perhaps there are other factors.

I have some files, exported from Training Centre, that don't import in new column. I have an idea why but they aren't important now and something can be done about them another time.

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 17, 2020

I'm content that the files exported from Training Centre are importing into the "Total recorded time excluding pauses" column accurately. The Elapsed time in mtb is accurate as well. While TC displays data in the same way as the units, the timing data comes out differently if you open up the file and manually subtract stoppages from elapsed time, mtb imports more faithfully to that which I'm happy with.

Superb, I am really happy to read that, thanks for testing thoroughly.

I have found that .tcx that have come from the unit import with an accurate elapsed time but the recorded time excluding pauses is out, usually by about 6-10 seconds per activity, compared with manually subtracting stoppages from elapsed time. This was the case with 4/5 .tcx I had to hand. This might be because I only provided .tcx exported from Training Centre, I can provide .tcx and .fit from a Garmin unit if you wish. Certainly .tcx from a Garmin unit mark stoppages in the same way as the exported files shared with you but perhaps there are other factors.

If you think that it would be valuable for me to look at a TCX from the unit vs a TCX from Garmin Training Centre, I would be happy to do that.

I have some files, exported from Training Centre, that don't import in new column. I have an idea why but they aren't important now and something can be done about them another time.

Let me know about "your idea"

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 17, 2020

That was quick! 👍

As quick as possible ;-)

So, some feedback after testing.
Might it be the case that something has changed with the importing of .fit files in the new development build. I only have two files to hand, they matched Training Centre in the old development build at 42:57 & 54:33 but in the new version they import as 42:51 & 54:28 respectively. I double checked this by uninstalling the new version and re-installing the old.

Hmm... that's weird. Do you think you could provide me with those FIT files so I can look into that ?

The .tcx imports are pretty good, I think your work has been a success so far. The 7 mile ride mentioned in the opening comment now comes in at 29:05 when it should be 29:22.81. The run matches Training Centre now, to the second. Having done a lot of comparisons, It is almost always the case mtb is interpreting a .tcx's time lower than Training Centre. This leads to a small but important difference in the sum total time when comparing mtb and Training Centre. I initially thought the reason for this was that a .tcx file that includes laps & stoppages was not importing as faithfully as one without laps. That can't of course be the case because the files I sent you are off and they don't include laps. I wonder if it's for the same reason the .fit files are off in this build. I really wish the difference in time was smaller.

The sum total distance is more or less the same between Training Centre and mtb. I think previously, mtb was setup to ignore invalid files and that meant there was a larger difference between the two.

I found some more .tcx files that don't import data in the new column. These feature </track> followed by <Extensions>. I've yet to understand what that means but I note the schema includes a variety of terms, including <Extensions>, under xsd:sequence. I assume all these terms can feature in a .tcx file, does mtb know how to interpret them all? This is not quite right, need to spend more time looking at them to understand how they differ to the files I sent you.

Let me know what your findings are.

@ghost
Copy link
Author

ghost commented Sep 17, 2020

Just to tidy up.

Everything in this comment was supplanted by instead calculating the stoppages directly from the files and comparing them with TC & mtb without bias. I just hadn't realised that could be done before.

I have an idea why

This is just a phrase, as in I think I know why...

I have some files, exported from Training Centre, that don't import in new column

These .tcx are an older style, it's not worth messing about with them for now. I can open an issue to get them working some other time.

42:57 & 54:33 but in the new version they import as 42:51 & 54:28

This is actually to do with this:

I have found that .tcx that have come from the unit import with an accurate elapsed time but the recorded time excluding pauses is out, usually by about 6-10 seconds per activity,

Yes I'll send you a few files if that's ok to sort this out, day after tomorrow. Files - .fit or .tcx - taken from a Garmin unit aren't represented in the new column correctly.

@ghost
Copy link
Author

ghost commented Sep 20, 2020

Just sent you a couple more .tcx that aren't recognised by mtb. Let me know if there are any issues.

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 20, 2020

Just sent you a couple more .tcx that aren't recognised by mtb. Let me know if there are any issues.

Thanks, I will look at them and answer you

@ghost
Copy link
Author

ghost commented Sep 21, 2020

The Elapsed time in mtb is accurate as well

I've tested the elapsed time on a larger number of samples and unfortunately mtb doesn't import my Garmin .tcx files correctly. It seems that mtb expects the activity start time to begin <Time> when actually it is <Id>. The difference between the two is responsible for 100% of the difference between the elapsed time calculated by mtb compared with the xml.

The difference is most pronounced when the unit is setup to Smart Record but there is very often a difference in time of one second when the unit is setup to record every second.

tcx1

On 170-odd activities the difference added up to 4:14

tcx

Most of these .tcx were .fit imported to Training Centre, then exported to mtb so I assume Garmin .fit files are equally affected.

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 21, 2020

The Elapsed time in mtb is accurate as well

I've tested the elapsed time on a larger number of samples and unfortunately mtb doesn't import my Garmin .tcx files correctly. It seems that mtb expects the activity start time to begin <Time> when actually it is <Id>. The difference between the two is responsible for 100% of the difference between the elapsed time calculated by mtb compared with the xml.

The difference is most pronounced when the unit is setup to Smart Record but there is very often a difference in time of one second when the unit is setup to record every second.

tcx1

On 170-odd activities the difference added up to 4:14

Most of these .tcx were .fit imported to Training Centre, then exported to mtb so I assume Garmin .fit files are equally affected.

Well, I was about to give you the latest build after having fixed the missing pauses from the latest files you gave me but it seems that I need to continue doing some fixes before giving you anything :-)

Ok, I will look into that. i.e.: Using "Id" instead of "Time". This is likely an issue that has been in MT that whole time (even before I modified the TCX import to take into account the pauses) so I am curious why nobody noticed that...
Either way, I will fix that and give you another build hopefully tomorrow.

Thanks!

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 21, 2020

Or now that I look closer, maybe the activity start time is the lap start time ?

image

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 21, 2020

Looking at it more, it might not be a bug but maybe how MT is designed. @wolfgang-ch will have to weigh in as I believe he originally coded the TCX import.

My understanding is that the computation of the elapsed time is based on the GPS data entries. See the code here
So basically, the value of the elapsed time is based on the time between the last GPS entry's time minus the first GPS entry's time.
Hence, because the ID or Lap StartTime are just times without GPS entries, they are not taken into account into the computation of the elapsed time.
One "hack" we could do would be to have the first GPS entry be the actual ID's time with the coordinates of the actual first TrackPoint.
@wolfgang-ch , any thoughts ?

@condemnedmeat , what I struggle to understand is why are there 24 seconds of delay between the activity start time and the first trackpoint's time in your example ?

On 170-odd activities the difference added up to 4:14

At the end of the day, 4minutes for 170 activities, is it a big deal ?

@wolfgang-ch
Copy link
Collaborator

Currently the StartTime in the <Lap> tag is ignored because there is no GPS Data.

The time difference between <Lap> StartTime and the first <Track> <Time> could be counted as paused time.

When this code is "hack"ed then a reimport for already saved tours MUST contain the same time values, otherwise this is not a reimport.

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 21, 2020

Currently the StartTime in the <Lap> tag is ignored because there is no GPS Data.

The time difference between <Lap> StartTime and the first <Track> <Time> could be counted as paused time.

That's something I forgot to mention, i think it would confuse users to see pauses at the start.
Maybe it's better not to hack it and keep the current behavior.

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 21, 2020

Just sent you a couple more .tcx that aren't recognised by mtb. Let me know if there are any issues.

@condemnedmeat
I have fixed the pause import after looking at your latest TCX files. Please download my updated development build of MT (use the same dropbox link I originally put here), test it and let me know.

@ghost
Copy link
Author

ghost commented Sep 21, 2020

it seems that I need to continue doing some fixes before giving you anything

Sorry about that! 😄

why are there 24 seconds of delay between the activity start time and the first trackpoint's time in your example ?

This was the largest example in the sample. Many activities from my Edge 500 - which produces .fit files - are still 6, 7, 10 seconds though. Smart record was in use at the time. It only logs when "the fitness device detects changes in direction, speed, heart rate or elevation" so that is the reason why there is a 24-second gap. Auto pause-when-stopped is also switched on on the unit but it's clear from the xml it is not in use. So I must have been moving about but in that 24-second space I didn't do anything that would cause a new log point to be created in the xml.

At the end of the day, 4minutes for 170 activities, is it a big deal ?

I think if mtb is to be used as a training tool it needs to report what's in the xml accurately.

Concerning Lap-StartTime, the reason I pointed to <Id> was because in a single xml there is only one but there is one per lap of the former, and it's always followed by an additional, lap specific summary. If you wish to use Lap-StartTime, then why not use the summary too? I'd need to do further testing to confirm it but this appears to be what Training Centre & Connect does. I assume it uses the rest of the data for mapping and things like charting the elevation, speed etc. This would explain why the unit's data always matches them, but why there is a difference in the activity characteristics if you calculate directly from the xml and compare. The rationale behind this is irrelevant but I could speculate. Going down that route might be a good idea as it would mean imports to mtb would match the unit. I think most Garmin users would expect this, after all, that was the reason I originally opened the issue.

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 21, 2020

At the end of the day, 4minutes for 170 activities, is it a big deal ?

I think if mtb is to be used as a training tool it needs to report what's in the xml accurately.

But like Wolfgang said above, those 4 minutes for 170 activities would be considered a pause if imported as it would be ignored because there is no GPS Data. Hence, the elapsed time, in the end, would still remain unchanged.

The time difference between StartTime and the first could be counted as paused time.

let me know how your testing goes with my latest dev build :-)

@ghost
Copy link
Author

ghost commented Sep 21, 2020

And so does that mean the way elapsed time is handled by mtb isn't going to be improved so it represents the xml faithfully?

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 21, 2020

And so does that mean the way elapsed time is handled by mtb isn't going to be improved so it represents the xml faithfully?

Not necessarily but MTb already represents the XML faithfully as described above. If the XML supplies GPS data, MT will use it. If not, then MTb can't do much about that.
Unless somebody sees a better solution ?

Btw, you mentioned that a couple of days ago :

Might it be the case that something has changed with the importing of .fit files in the new development build. I only have two >files to hand, they matched Training Centre in the old development build at 42:57 & 54:33 but in the new version they import >as 42:51 & 54:28 respectively. I double checked this by uninstalling the new version and re-installing the old.

I have just created another build of MT that is available for you to download and that fixes some FIT import issues that Wolfgang found, can you please download this one and let me know if that fixes also your FIT issues ?

Thanks

@ghost
Copy link
Author

ghost commented Sep 22, 2020

In this version I tested the pauses on the same sample I tested the elapsed time and they are exactly correct. 👍 So no issues there.

In the next version, created after this comment there is an issue. The pauses are not importing correctly across all imports.

<Time>2020-09-19T10:22:15Z</Time>
</Trackpoint>
<Trackpoint>
<Time>2020-09-19T10:22:39Z</Time>
</Trackpoint>
<Trackpoint>

Perhaps it's because of the common use of </Trackpoint> in the xml compared with the more unique </Track> in the previous examples.

Concerning the elapsed time discussion, I imported that example into Connect and it doesn't recognise the 24-seconds at the beginning as part of the total elapsed time either so 🤷‍♂️.

I'm just looking at the issues with files coming off the unit now and haven't tested the latest update as I assume it will have issues with the pauses. Could just revert the changes in that respect for the moment, see what you think.

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 22, 2020

In this version I tested the pauses on the same sample I tested the elapsed time and they are exactly correct. 👍 So no issues there.

In the next version, created after this comment there is an issue. The pauses are not importing correctly across all imports.

<Time>2020-09-19T10:22:15Z</Time>
</Trackpoint>
<Trackpoint>
<Time>2020-09-19T10:22:39Z</Time>
</Trackpoint>
<Trackpoint>

Perhaps it's because of the common use of </Trackpoint> in the xml compared with the more unique </Track> in the previous examples.

Weird.... When I import the file from which this excerpt is from, I see the pause of 24 seconds.
image

Can you please test with the latest version I did yesterday and tell me if the FIT and TCX pause import issues are fixed ?

Concerning the elapsed time discussion, I imported that example into Connect and it doesn't recognise the 24-seconds at the beginning as part of the total elapsed time either so 🤷‍♂️.
That makes sense since as mentioned above, there is no GPS data between those two times.

I'm just looking at the issues with files coming off the unit now and haven't tested the latest update as I assume it will have issues with the pauses. Could just revert the changes in that respect for the moment, see what you think.

No, please test with the very latest (the version I did yesterday) as I should have fixed all those issues.

@ghost
Copy link
Author

ghost commented Sep 22, 2020

Sorry I should have said, it imports that activity correctly but activities using </Track> have a paused time that is wrong.

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 22, 2020

Sorry I should have said, it imports that activity correctly but activities using </Track> have a paused time that is wrong.

With the last build ?

@ghost
Copy link
Author

ghost commented Sep 22, 2020

This is what I mean.
These figures are a correct representation of the xml.
version0

After the fix here

That single xml I sent you imports correctly while these are the figures for the same sample above.

version1

They are wrong.

This will be the same in the latest version won't it? If not I can test it.

May be worthwhile giving these iterations different names. Also, I noticed the way the icons chopped and changed about btw! Are you trying to confuse me! 🤦

@FJBDev
Copy link
Collaborator

FJBDev commented Sep 22, 2020

They are wrong.

Ok, I guess I am the one confused 😊 What is wrong ? Can you tell me which file has wrong figures so I can try to reproduce ? All the files you sent me are importing with correct numbers for me (at least in my latest build)

May be worthwhile giving these iterations different names.

Ok, I have done so in the very latest build I have created that you can download here
From now, on, I have added the date and time of the build so we are on the same page when we talk about build versions.
This one is called 20200922-1017

Also, I noticed the way the icons chopped and changed about btw! Are you trying to confuse me!

Indeed, Wolfgang and I changed the icons. We are not trying to confuse anyone but as this code is not finished, it is subject to change, sorry about that !

@wolfgang-ch
Copy link
Collaborator

This was the icon discussion #227 (comment)

@ghost
Copy link
Author

ghost commented Sep 23, 2020

Concerning Garmin .fit imports. I only have two files handy. The elapsed time is represented correctly in mtb. The paused time is unreliable. It has changed on every iteration of mtb I've tested.

To read the files, for the purpose of calculating the times myself I imported the .fit files then exported from TC. I don't know how to read a .fit otherwise. Based on this, they should have paused times of 06:58.00 & 12:58.00 respectively. TC has a recorded time for these files which is almost identical to Connect, the difference being Connect rounds up to the nearest second.

In the first iteration of mtb I tested they were 06:57 & 12:58. In the second iteration they were 07:03 & 13:03. Third, 06:58 & 12:58, however the "Total recorded time excluding pauses" column didn't sum correctly if I took paused time away from elapsed! In order to sum correctly paused time would have to amount to 07:03 & 13:03. In the latest version they were 06:53 & 12:57.

For comparison, after importing the .fit into Connect the pauses can be calculated as 07:03 & 13:03, the recorded time is the same as the TC export and so the elapsed time is longer.

Concerning Garmin .tcx imports, after they were made to be recognised in mtb's second iteration .tcx imported from a device were wrong (2nd Par.) while .tcx Training Centre backups' elapsed and recorded time were exactly correct. In the third & fourth iteration, .tcx backups were broken while .tcx coming directly from the unit import correctly, both elapsed and recorded time. It's also true all the .tcx I have sent FJBDev import correctly.


Edit - I did some cursory checking to see if there was anything obviously wrong that would explain why that .tcx backup sample wasn't importing correctly now and it looks like the activities affected are those that were originally .fit when they were imported to Training Centre. I don't understand this as they use </Track><Track> like other .tcx when you export them. It's also the case that the files that originally came off the device as .tcx now have a total elapsed time that is out by 6-seconds and paused time off by 5-seconds when they were exactly dead on. The total elapsed time for those is over 17 hours.

In this version I tested the pauses on the same sample I tested the elapsed time and they are exactly correct.

@ghost
Copy link
Author

ghost commented Oct 2, 2020

After chatting some more FJBDev has improved the importing of .tcx & .fit pauses and they are interpreted faithfully. 👍

@ghost ghost closed this as completed Oct 2, 2020
@FJBDev FJBDev mentioned this issue Oct 3, 2020
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants