Is there a option to select what previous rides you want to compete against ? Or I have to go to user data ride folder and remove those rides that I don't want to see as "competitors" ? BTW, will this method work at all, sorry I didn't try
Also , just to double check , if I am riding against , let's say 3 previous rides, there is no way to uniquely identify each one , i.e to link it to specific date for example ?
Performances are recoded not against the ride but against predefined segments. All explanations are in user's guide: http://www.veloreality.com/exs_v_ride/v ... l_v1.0.pdf sections 7.7, 8.8, you can not delete previous performances and select which one to display. You can however turn visibility on/off section 9. All management is automatic. Up to 5 performances are recorded for each segment. After that number:
1) The bucket is full and your performance worse than any in bucket.
Remove your best performance shift all previous and add new one
2) The bucket is full but your performance better then worst
Remove your worst performance and add new one
admin wrote: ↑Thu Jan 26, 2017 7:30 am
1) The bucket is full and your performance worse than any in bucket.
Remove your best performance shift all previous and add new one
I appreciate that algorithm works if I am genuinely getting slower and don't want to keep a no-longer-realistic best performance.
But the problem with the algorithm is when I have set a great best performance that I really want to keep racing against.
Then I have an easy day on that course (recovery ride after race or just tired). Result is a ride worse than any in the bucket.
And now I have lost that great best performance! Gone for ever. Gnashing of teeth. And the realisation that I can't afford to have an easy day.
Please can we find some simple way for the user to intervene and prevent this happening when they want an easy day.
How about if visibility of previous performances is turned off then rule 1 is not applied?
In practice the algotitm works not just when you are getting slower but rather as a sliding window fluctuating around you average performance which I believe is good enough. But I understand your concern. So rejoice. You can now select what the system will do. Below is the extract from updated user's guide:
When you ride your performance against each segment will be recorded. The software keeps up to 5 performances per user per segment. When the new performance is being submitted and there are already 5 performances available one performance must be purged. If the new performance is better than the slowest one it will be inserted into appropriate slot and the slowest performance will be purged. If however new performance is slower than any other in the bucket then what will be purged depends on the value of “Segment performance strategy” setting. If it is set to “Purge best” then the fastest performance is purged. If it is set to “Purge worst” then the slowest performance is purged. If you select a ride where there are some performances already available you would be able to race against it
For your info - user performances on segments are kept in files with special names:
Click on "my data" button. hat will open folder containing your TCX ride files. If you go one level above you will see following set of folders: ride_state, rides, rides_export, segperf
inside segperf folder are your segment performance records ( duh ), up to five for each segment. They have rather long names that look like:
2016_08_22_15_36_45 - YYYY_MM_DD_hh_mm_ss - date and time of performance
0025 - SKU of the video (first 4 symbols of video file name)
07561 - segment start position in meters
07759 - segment end position in meters
00033 - time in seconds to complete segment
0000000002 - your user ID
Performances are extracted each time you clicked "Reset ride" button, or that huge "START PEDALING ,blah, blah, blah" button in the main riding screen once you clicked "Start ride"/"Continue ride" buttons.
That's great - I nearly asked for 'user configurable' along the lines of your suggestion, but thought a 'user configurable' solution would be rejected.
One very satisfied user here - many thanks for a quick response and very workable solution.
And the detailed explanation of how segment performances are named and stored is very useful if I back them up.
