Updated Snapshot Builds

[Ale Martinez]

There are updated snapshot builds, they include all the fixes to the problems reported after v3.7 release plus some new features:

• Ability to override metrics in Overview charts using Metric tiles, similar to Metadata tiles in v3.7 (Thanks to Paul)
• New Manual Activity wizard replacing the old manual activity dialog for past activities (Thanks to Joachim)
• New Planned Activity wizard replacing the old manual activity dialog for future activities  (Thanks to Joachim)

Testing and feedback is welcome, see change log for more details and download from https://github.com/GoldenCheetah/GoldenCheetah/releases/tag/snapshot

Cheers, Ale.

[Ale Martinez]

PS: default PMC (Coggan) chart is based on BikeStress for the actual activities, there are a set of Planned and Expected Coggan PMC metrics which include planned activities:

 

- Planned are based on the BikeStress of planned activities only

- Expected are based on the BikeStress of actual activities until today and planned activities for the future

So, if you build a PMC chart using Expected metrics, you would see a PMC like the standard one until today and the expected time course of PMC metrics provided you follow the plan. 

[Poncho]

On 7/10/25 01:19, Ale Martinez wrote:
> PS: default PMC (Coggan) chart is based on BikeStress for the actual
> activities, there are a set of Planned and Expected Coggan PMC metrics
> which include planned activities

Hi Ale

After your recent changes (issue/4652), PMC based on my custom metric
doesn't work anymore for planned workouts. The only difference between
planned and expected is that when selecting planned it gets back filled
with 0. (see the attached screenshots)

A quick test using the builtin PMC and switching between "Coggan
Expected Acute Training Load" and "Coggan Planned Acute Training Load"
didn't work as before either. There seems to be no difference between
planned and expected.

This is on current git master.

[Ale Martinez]

El martes, 15 de julio de 2025 a la(s) 5:08:45 a.m. UTC-3, Poncho escribió:

On 7/10/25 01:19, Ale Martinez wrote:
> PS: default PMC (Coggan) chart is based on BikeStress for the actual
> activities, there are a set of Planned and Expected Coggan PMC metrics
> which include planned activities


Hi Ale

After your recent changes (issue/4652), PMC based on my custom metric
doesn't work anymore for planned workouts. The only difference between
planned and expected is that when selecting planned it gets back filled
with 0. (see the attached screenshots)

Not sure I understand this, before the commits related to #4652 there was no way to have planned/expected PMC using metrics other than BikeStress (you need to use the pseudo-metrics Coggan Expected xxx / Coggan Planned xxx for that).

 

A quick test using the builtin PMC and switching between "Coggan
Expected Acute Training Load" and "Coggan Planned Acute Training Load"
didn't work as before either. There seems to be no difference between
planned and expected.

Are you talking about the pseudo metrics available when you select Metric in chart config (these have not changed) or selecting Stress > Planned/Expected > BikeSress (these are new and should replace the former when base metric is BikeStress).

I plan to add "planned" to filter since currently is not that easy to spot normal activities happening in the future (which are an anomaly now, but in v3.7 they were the only option) from planned ones.

[Poncho]

Hi Ale

Sorry, I was confused and mixed things up. The issue is not actually
related to the recent commits.

Reading this:

> So, if you build a PMC chart using Expected metrics, you would see a PMC
> like the standard one until today and the expected time course of PMC
> metrics provided you follow the plan.

I was under the impression, that a pmc created with the expected metrics
would show the actual values till today and the expected values after
today. But that doesn't work.

Attached the normal coggan pmc with values till today and the expected
coggan pmc only showing values after today.

The way I understood it, the expected coggan pmc should be a combination
of the two. Actual values for the past, expected values for the future.

Now I'm not sure whether I misunderstood the feature or if it actually
is a bug.

[Ale Martinez]

That's exactly right

 

Now I'm not sure whether I misunderstood the feature or if it actually
is a bug.

Beware planned/expected applies only to planned activities, that is activities created using Activity > Plan activity...

If you have regular activities with future dates -which were the only way to forecast a plan in the past but not anymore- they are ignored by planned/expected.

I know this is clear as mud so I will create new snapshot once https://github.com/GoldenCheetah/GoldenCheetah/issues/4670 is implemented for clarity sake.

[Ale Martinez]

I added 2 features to master which should help to clarify the difference between planned activities (those created by Activity > Plan Activity wizard) and actual activities (everithing else):

1) Planned activities are highlighted in Activities left sidebar with a darker background

2) Planned is available in filters, so you can list only planned activities using just Planned or only actual activities using !Planned, default named filters are created for new users too.

Planned can also be used in formulas for other purposes but not in Python or R, adding a metric for that seems the easier way, but I have not made a decision yet.

PS: I have not created new snapshots yet since the few interested people si building from source.

[Poncho]

On 7/19/25 01:13, Ale Martinez wrote:
>
> I added 2 features to master which should help to clarify the difference
> between planned activities (those created by Activity > Plan Activity
> wizard) and actual activities (everithing else):
> 1) Planned activities are highlighted in Activities left sidebar with a
> darker background
> 2) Planned is available in filters, so you can list only planned activities
> using just Planned or only actual activities using !Planned, default named
> filters are created for new users too.
> Planned can also be used in formulas for other purposes but not in Python
> or R, adding a metric for that seems the easier way, but I have not made a
> decision yet.
> PS: I have not created new snapshots yet since the few interested people si
> building from source.

Thank you, Ale. I'll have a look and give it a go.

[Ale Martinez]

PS: I decided not to for now, I am not sure it is necessary in general, and it can be trivially added as a User Metric { value { Planned; } } if required.

[ZajtiM]

I started latest snapshot build in debug mode and terminal was flooded with debug lines you can see at the bottom of this post.

GoldenCheetah_v3.7_x64_SNAP2.AppImage --version
GoldenCheetah V3.7 (5005)
qt.network.ssl: QSslSocket: cannot resolve EVP_PKEY_base_id
qt.network.ssl: QSslSocket: cannot resolve SSL_get_peer_certificate

Build date: Jul 21 2025 01:13:27
Build id: 5005
Version: (developer build)
DB Schema: 160
Metrics: 382
OS: Linux Mint 21.1
OpenGL:
UI: dpi scale (0) font size (-1)
QT: 5.15.2

I selected ERG file in train view and clicked on connect (ANT+), nothing else. Didn't start a workout, only connected. Terminal was flooded with 5000+ lines of this within one or maybe two minutes.
"
Debug: altitudeAt should not be called if ergfile has no gradient
Debug: locationAt should not be called if ergfile has no gradient
Debug: locationAt should not be called if ergfile has no gradient
Debug: altitudeAt should not be called if ergfile has no gradient

[Ale Martinez]

El jueves, 24 de julio de 2025 a la(s) 1:04:25 p.m. UTC-3, ZajtiM escribió:

I started latest snapshot build in debug mode and terminal was flooded with debug lines you can see at the bottom of this post.

Hi Mitja, is this new to latest snapshot or is also present in v3.7 release?

[ZajtiM]

Hi Ale. Good question. Didn't think to check out with actual release.

Tested with latest 3.7 release on git. It starts flooding terminal as soon as i connect. If i disconnect it stops.
GoldenCheetah V3.7 (5005)

Build date: Mar 29 2025 01:18:27
Build id: 5005
Version: V3.7

DB Schema: 160
Metrics: 382
OS: Linux Mint 21.1
OpenGL:
UI: dpi scale (0) font size (-1)

QT: 5.15.3

[Ale Martinez]

El viernes, 25 de julio de 2025 a la(s) 12:05:26 a.m. UTC-3, ZajtiM escribió:

Hi Ale. Good question. Didn't think to check out with actual release.

Tested with latest 3.7 release on git. It starts flooding terminal as soon as i connect. If i disconnect it stops.

Thank you, I can reproduce this, the culprit is the new elevation chart (https://github.com/GoldenCheetah/GoldenCheetah/pull/4620), if you remove it from your layouts it should stop.

I will fix that.

[Ale Martinez]

El viernes, 25 de julio de 2025 a la(s) 10:11:59 a.m. UTC-3, Ale Martinez escribió:

El viernes, 25 de julio de 2025 a la(s) 12:05:26 a.m. UTC-3, ZajtiM escribió:

Hi Ale. Good question. Didn't think to check out with actual release.

Tested with latest 3.7 release on git. It starts flooding terminal as soon as i connect. If i disconnect it stops.

Thank you, I can reproduce this, the culprit is the new elevation chart (https://github.com/GoldenCheetah/GoldenCheetah/pull/4620), if you remove it from your layouts it should stop.

I will fix that.

Fixed by https://github.com/GoldenCheetah/GoldenCheetah/commit/4d95f439b77cad85eb3674bc31a393d1d903099e

BTW, I forgot to add Mitja to contributors for v3.7, sorry, fixed by https://github.com/GoldenCheetah/GoldenCheetah/commit/9713b09e84f9f24c30ef611055ac11c8fae3c258

[Ale Martinez]

There are new snapshot builds including fixes for reported issues, some new features and more fixes related to planned activities, and improved support for CORE sensor in Train view. See change log for more details and ask questions / give feedback here, thank you.

[ZajtiM]

On Sunday, 27 July 2025 at 01:50:27 UTC+2 Ale Martinez wrote:

There are new snapshot builds including fixes for reported issues, some new features and more fixes related to planned activities, and improved support for CORE sensor in Train view. See change log for more details and ask questions / give feedback here, thank you.

Tested debug mode. Flooding is fixed. I also checked Filter doubles. It is fixed as well. Great work!

On Friday, 25 July 2025 at 18:03:23 UTC+2 Ale Martinez wrote:

BTW, I forgot to add Mitja to contributors for v3.7, sorry, fixed by https://github.com/GoldenCheetah/GoldenCheetah/commit/9713b09e84f9f24c30ef611055ac11c8fae3c258

 

Thank you Ale. Compared to the others, I haven't contributed much. So I'm honored to be added to the list of contributors.

Cheers,
Mitja

[marcen]

Hi,

Note on the snapshot build from 26 July 2025 on Arch Linux.
If a list is created from GC.xdata using Python, once without comparison mode and once with comparison mode, the two lists are different.
Only the one unit is shown in the Compare Pane. I have attached the unit and the Python chart that I used for testing.

Here is a picture of the two different lists:

[Ale Martinez]

Hi Marcen, I will take a look but to focus the search: is this specific to latest snapshot or it happens on v3.7 release too?

[marcen]

I have found time to check it. The behavior is already noticeable in v3.6 release.
Thank you for checking.

[Ale Martinez]

El domingo, 17 de agosto de 2025 a la(s) 3:43:17 p.m. UTC-3, marcen escribió:

I have found time to check it. The behavior is already noticeable in v3.6 release.
Thank you for checking.

Ok, so it is not related to latest snapshots.

Anyway, I am not sure I understand the issue: when compare mode is off you get xdata from the currently selected activity, when compare mode is on you get xdata from the corresponding compare item in compare pane, which can be different. 

[marcen]

The first list from the image is when the attached file is imported and selected in the side bar.
The second list is when the file is inserted into the Compare Pane and the comparison mode is on. There is only this unit in the Compare Pane.
However, the values differ when they come from the side bar and from the Compare Pane.

[marcen]

I thought it might be just Python-related, so I tried it with an Activity Chart. I inserted the formula XDATA("GEARS","FRONT", repeat) into User Data. Again, I get two different graphs. When I select the unit once from the side bar and once from the Compare Pane.

[Ale Martinez]

El lunes, 18 de agosto de 2025 a la(s) 5:53:07 p.m. UTC-3, marcen escribió:

I thought it might be just Python-related, so I tried it with an Activity Chart. I inserted the formula XDATA("GEARS","FRONT", repeat) into User Data. Again, I get two different graphs. When I select the unit once from the side bar and once from the Compare Pane.

That makes more sense since Python API just retrieve a CompareInterval item without processing, reality is even when you drag a whole activity to the Compare Pane a fake activity is created using the samples for the selected interval which may include all the samples off course, it could be a bug in that process when generating the XData samples, if you want to investigate further the relevant block of code is: https://github.com/GoldenCheetah/GoldenCheetah/blob/b7429db207a4a2b0a1190926f77e0338898bb47e/src/Gui/ComparePane.cpp#L728-L772  

[marcen]

Thank you for the link. I don't have the programming knowledge to understand what's going on there. Sorry

[Ale Martinez]

I tried this with my swim data using standard XData charts for Strokes and Swim Golf and I cannot reproduce the issue, using your file the initial anomaly is due to the first XDATA sample starts at 00:01:00, changing that to 00:00:00 seems to fix that. To be honest, I have too much GC related things going on at this point to dedicate more time to this, sorry.

[Ale Martinez]

El miércoles, 20 de agosto de 2025 a la(s) 8:26:59 p.m. UTC-3, Ale Martinez escribió:

I tried this with my swim data using standard XData charts for Strokes and Swim Golf and I cannot reproduce the issue, using your file the initial anomaly is due to the first XDATA sample starts at 00:01:00, changing that to 00:00:00 seems to fix that. To be honest, I have too much GC related things going on at this point to dedicate more time to this, sorry.

I took another look at the code and the problem seems to be having a separate offset for each XData series, this works when XData starts from 0 (or at interval start in general) like in my tests with lap swim data, but it doesn't in your case where an XData series starts 1 minute later.

The fix is easy and since it involves just deleting code, it is little pleasure to do ;)

See https://github.com/GoldenCheetah/GoldenCheetah/commit/49056554132182bc15df3624e9bda30ff4bf7d49 

[marcen]

Thank you for taking the time to look into the issue in detail. It's good to hear that the fix was not too complex. As soon as a new snapshot build is available, I will test it and get back here.

[Ale Martinez]

The new snapshots include the new Calendar chart and the ability to go directly from a planned activity to Train view for doing it, thanks Joachim! 

Testing and feedback is welcome, see change log for more details and download from https://github.com/GoldenCheetah/GoldenCheetah/releases/tag/snapshot

Cheers, Ale.

[Peret]

New Calendar Chart is great! Thanks, Joachim! I have never used planned activities nor any related to future events, so this can be a motivation for that.

So, not functional opinion, it seems nice to me.

My only comment is related to deletion of activities through contextual right click menu: it does not ask for confirmation, as activities view do. I think it can lead to some problem. I seenthat deleted activities are stored in bak/ directory, but easy to recover for most users, I think. Could you consider to show a confirmation window? I can prepare a PR, if necessary, so you can continue with other tasks

[Joachim Kohlhammer]

Hi Peret, just created a PR on the confirmation dialog: https://github.com/GoldenCheetah/GoldenCheetah/pull/4691

Cheers, Joachim

[marcen]

With the fix for XDATA, the unit is correctly displayed in the Activity Chart, regardless of whether it comes from the Side Bar or the Compare Pane.
The pie chart from the user chart now displays the percentage value and the percentage in the correct position.
Thank you.

[Ale Martinez]

Latest snapshot is v3.7 plus fixes for the bugs reported after release and some new features, notably a new Calendar chart available as a Trends chart and configurable as other charts, plus the ability to plan futures activities based on Train workouts and switch to Train view to execute them, Expected PMCs based on planned activities, metrics override in Overview charts and several other features. See the Change Log for all the changes.

Icons are configurable based on Sport/SubSport but they are not included in binaries due to license incompatibility, an optional package with icons as illustrated above is attached to this release as icons.zip and it can be imported in Options > Data Fields > Icons, you can use others icons of your preference there too.

Installers available from https://github.com/GoldenCheetah/GoldenCheetah/releases/tag/snapshot

Feedback and ideas are welcome here, thank you.

Ale.

[ZajtiM]

Hi Ale.

One question regarding snapshot builds and ERG workouts. Is there anything different compared to regular builds?

Example: I use one ERG 30min 6sec recovery workout. When i do full workout in Qt6 version (May 30 build) it saves full 30min and 6sec. But when i use snapshot builds, is always under 30min. And always some "random" duration. 29min XXsec.

Few saved times with snapshot builds: 29:43, 29:59, 29:45, 29:56, etc.

Cheers, Mitja

[Ale Martinez]

El viernes, 19 de septiembre de 2025 a la(s) 1:01:20 p.m. UTC-3, ZajtiM escribió:

Hi Ale.

One question regarding snapshot builds and ERG workouts. Is there anything different compared to regular builds?

Main difference is Videos support (Qt6 vs VLC), it should not impact on ERC workouts unless you use videosync, but honestly is not something a use, so I don't know.

[Ale Martinez]

El viernes, 19 de septiembre de 2025 a la(s) 2:12:56 p.m. UTC-3, Ale Martinez escribió:

El viernes, 19 de septiembre de 2025 a la(s) 1:01:20 p.m. UTC-3, ZajtiM escribió:

Hi Ale.

One question regarding snapshot builds and ERG workouts. Is there anything different compared to regular builds?

Main difference is Videos support (Qt6 vs VLC), it should not impact on ERC workouts unless you use videosync, but honestly is not something a use, so I don't know.

Hi Mitja, in the latest snapshot release there are 2 AppImage files: the classic one generated by Travis-ci based on Qt 5.15.2 with VLC video similar to v3.7 release, and a new experimental/untested one generated by AppVeyor based on Qt 6.8.3 with Qt 6 video if you want to give it a try.

Cheers, Ale.

[ZajtiM]

Hi Ale,

it crashes without even opening GC. It did show athlete selection, because i had one GC running already. But then crashes.

Thread 1 "AppRun" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff014b334 in ?? () from /tmp/.mount_GoldenFkCagN/lib/libQt6WebEngineCore.so.6
(gdb) backtrace
#0  0x00007ffff014b334 in ?? () from /tmp/.mount_GoldenFkCagN/lib/libQt6WebEngineCore.so.6
#1  0x00007fffe9a49a18 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#2  0x2b88a71c104b1300 in ?? ()
#3  0x0000000000000000 in ?? ()
(gdb) 

I thought it might be problem on my side, because of " /lib/x86_64-linux-gnu/libstdc++.so.6"

So i extracted AppImage
- "readelf -d libQt6WebEngineCore.so.6" links against system libstdc++.so.6

- "ldd" confirms it resolves correctly, no missing libraries

Cheers, Mitja

[Ale Martinez]

El domingo, 21 de septiembre de 2025 a la(s) 12:49:43 a.m. UTC-3, ZajtiM escribió:

Hi Ale,

it crashes without even opening GC. It did show athlete selection, because i had one GC running already. But then crashes.

Thread 1 "AppRun" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff014b334 in ?? () from /tmp/.mount_GoldenFkCagN/lib/libQt6WebEngineCore.so.6
(gdb) backtrace
#0  0x00007ffff014b334 in ?? () from /tmp/.mount_GoldenFkCagN/lib/libQt6WebEngineCore.so.6
#1  0x00007fffe9a49a18 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#2  0x2b88a71c104b1300 in ?? ()
#3  0x0000000000000000 in ?? ()
(gdb) 

Thanks for testing, the likely cause is I forgot to copy Qt6 resources files to the AppImage not managed by linuxdeployqt, in particular v8_context_snapshot.bin may be related to this.

I pushed the fix I used for my offline Qt6 builds before: https://github.com/GoldenCheetah/GoldenCheetah/commit/98593fce2d9b8d64daafa5f836ac0c1ce411a277, I will update when the build finishes.

[Ale Martinez]

Uploaded the updated AppImage based on Qt6.8.3 to https://github.com/GoldenCheetah/GoldenCheetah/releases/tag/snapshot, it works in my tests provided your system has relatively new  libstdc++6.so, otherwise you will receive a "`GLIBCXX_3.4.32' not found" error.

[Steve Edmonds]

Thanks Ale, loads fine now on openSUSE. Interestingly loads faster than the Qt5 version.
Steve

--
_______________________________________________
Golden-Cheetah-Users mailing list
golden-che...@googlegroups.com
http://groups.google.com/group/golden-cheetah-users?hl=en
---
You received this message because you are subscribed to the Google Groups "golden-cheetah-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golden-cheetah-u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golden-cheetah-users/fb4331d4-aa18-444a-8d44-dcc4afc6c6c4n%40googlegroups.com.