holes in recording

[Jean-Joël Bataille]

Sometimes when I want to correct holes in recordings, the appropriate tool does not do the job, even though the two parameters to be filled in are suitable for the holes to be corrected. I have not found any discussion addressing this issue. 

[Ale Martinez]

El domingo, 21 de septiembre de 2025 a la(s) 6:46:52 p.m. UTC-3, jj.ba...@gmail.com escribió:

Sometimes when I want to correct holes in recordings, the appropriate tool does not do the job, even though the two parameters to be filled in are suitable for the holes to be corrected. I have not found any discussion addressing this issue. 

Perhaps if you give more details and provide a sample file we could discuss your specific issue, otherwise a common user error is not understanding is you has one shot for Fill Gaps, further runs will do nothing because the gaps has been removed, you need to undo the previous changes or re-import if you changed your mind about parameters. 

[Jean-Joël Bataille]

In my activity, there are two gaps. The first is between 0:28:24 and 0:28:26, and the second, larger one is between 1:30:09 and 1:30:29.

My first attempt:

I use the tool with the settings “Tolerance 1s” and “stop 90s,” but only the first gap is corrected.

Second attempt:

I cancel the previous correction and change the settings to “Tolerance 1s” and “stop 15s.” Everything is corrected, with behavior consistent with what is stated in the help section for gaps larger than the stop.

I do not understand why the second gap was not corrected in the first attempt.

Thank you for your help.

Translated with DeepL.com (free version)

[Ale Martinez]

El lunes, 22 de septiembre de 2025 a la(s) 10:59:20 a.m. UTC-3, jj.ba...@gmail.com escribió:

In my activity, there are two gaps. The first is between 0:28:24 and 0:28:26, and the second, larger one is between 1:30:09 and 1:30:29.

My first attempt:

I use the tool with the settings “Tolerance 1s” and “stop 90s,” but only the first gap is corrected.

Second attempt:

I cancel the previous correction and change the settings to “Tolerance 1s” and “stop 15s.” Everything is corrected, with behavior consistent with what is stated in the help section for gaps larger than the stop.

I do not understand why the second gap was not corrected in the first attempt.

Me neither without looking at the data, It doesn't make any sense to me, if you attach the original file we can take a look to understand what's happening. 

[Jean-Joël Bataille]

Voici le .fit

[Ale Martinez]

El lunes, 22 de septiembre de 2025 a la(s) 10:59:20 a.m. UTC-3, jj.ba...@gmail.com escribió:

In my activity, there are two gaps. The first is between 0:28:24 and 0:28:26, and the second, larger one is between 1:30:09 and 1:30:29.

My first attempt:

I use the tool with the settings “Tolerance 1s” and “stop 90s,” but only the first gap is corrected.

Second attempt:

I cancel the previous correction and change the settings to “Tolerance 1s” and “stop 15s.” Everything is corrected, with behavior consistent with what is stated in the help section for gaps larger than the stop.

I do not understand why the second gap was not corrected in the first attempt.

The reason is the second gap happens during a pause which is shorter than stop, when there is no movement Fix Gaps doesn't interpolate the data, when the gap is greater than stop it is filled with zeroes: https://github.com/GoldenCheetah/GoldenCheetah/blob/98593fce2d9b8d64daafa5f836ac0c1ce411a277/src/FileIO/FixGaps.cpp#L176-L298 

Perhaps it would be better to fill with zeroes in the first case to avoid the need of a second run, but I didn't write that code and I am not sure about the original intention, at least we would need to amend the documentation.

[Ale Martinez]

After a second look the comment indicates my preferred behavior but the code does owerwise:

in https://github.com/GoldenCheetah/GoldenCheetah/blob/98593fce2d9b8d64daafa5f836ac0c1ce411a277/src/FileIO/FixGaps.cpp#L264-L265

// stationary or greater than 30 seconds... fill with zeroes

} else if (gap > stop) { 

should be:

// stationary or greater than stop seconds... fill with zeroes

} else if (stationary || gap > stop) { 

[Ale Martinez]

https://github.com/GoldenCheetah/GoldenCheetah/commit/e75ab1077204eaae4407955df46cb61927005af1

[Ale Martinez]

El lunes, 22 de septiembre de 2025 a la(s) 3:31:20 p.m. UTC-3, Ale Martinez escribió:

https://github.com/GoldenCheetah/GoldenCheetah/commit/e75ab1077204eaae4407955df46cb61927005af1

https://github.com/GoldenCheetah/GoldenCheetah/commit/36c98119d4b6e735cd35f6a25fdfb76c12b8ea8b

Now it should be consistent with https://github.com/GoldenCheetah/GoldenCheetah/wiki/UG_Special-Topics_Activity-Processing#edit-tool-fix-gaps-in-recording

[Ale Martinez]

There are installers with the fix applied available from https://ci.appveyor.com/project/Joern-R/goldencheetah-knhd8/builds/52789355, select the OS then Artifacts. 

[Jean-Joël Bataille]

I don't think these installers will help me. I work with Manjaro, so I use GC appimages. Is there a thread discussing the integration of patches into appimages? In any case, thank you for your continued helpful assistance.

[Ale Martinez]

The AppImage was created on Ubuntu22.04, follow that link, I used “installers” in a loose way, likely binaries would be a better term.

[Jean-Joël Bataille]

It's done, thanks again.