Skip to content
ChronoFEED EVENT Help

Performances

The entries' past performances, which are used to form the groups. For each race, EVENT computes every entry's seeding time according to the race's rules; the Line-up module then forms the heats with them.

The time that ranks each entry before the race (seeding), according to the race's chain of sources set in the template: for example their recent performances over the distance, otherwise another race already raced, otherwise their entry time.

Event1500 mCompute seedingCancelWhole eventSSR performancesChronoFEED performancesModule settings1
Seeding calculation: 3 / 8 — Eline De Smedt2
Venues allowedQuebec City (CAN), Calgary (CAN)Venues excludedNone3
#BibAthleteClubSeed timeSourceGroupHeatDetail (venue, date, conversion, formula)
1110Kaja NowickaTRV2:24.970Entry1P1
2107Eline De SmedtBOB2:22.800Performance1P1Quebec City (CAN), 2026-02-14
3105Maud LefébureSLB2:24.100Performance2P2Calgary (CAN), 2026-01-17
4
The Women's 1500 m of the Hollywood long track cup during the calculation: Eline De Smedt's row, being calculated, is in bold.
  1. The race (the same as in Line-up), the calculation, its “Cancel” and the “Whole event” box, the SSR and ChronoFEED readings, the module settings.
  2. The progress of the calculation.
  3. The venues allowed and the venues excluded, as multiple choices.
  4. The grid: the row being calculated is in bold and moves to its new rank.

Event

Where: Performances, top bar

The race whose seeding is calculated. It is the same list and the same choice as in the Line-up module: changing the race here changes it there too, and vice versa.

Compute seeding Time

Where: Performances

Computes each entry's seeding time according to the race's fallback chain; times corrected by hand are kept. The summary: “Seeding computed: 16 entries, 2 without a time.”. The calculation is also done automatically at the first generation. After a change in performances (SSR import, correction removed), compute again.

The calculation does not freeze the screen: it runs in the background, then each entry is shown in turn — its row turns bold, takes its new time and moves to its new rank, then goes back to normal. The progress bar tells how far the calculation has got (“Seeding calculation: 3 / 8 — Eline De Smedt”). Cancel stops the calculation: nothing is written and the grid goes back to the saved times; otherwise the times are written at the end.

Whole event. With Whole event checked, the calculation covers all races at once: each one is read again and computed in turn, with its own rules (converted times, allowed and excluded venues, manually corrected times kept). The bar shows the overall progress (“Seeding calculation: race 2 / 5 — 1500 m Women”) and, below it, a small bar per race with its state (“reading…”, “calculating… (16 entries)”, “16 entries, 2 without a time”, “no entries”); the race in progress is in bold. Cancel stops everything: nothing is written. Otherwise all the times are written at the end: “Seeding computed for 5 race(s): 74 entries, 6 without a time.”. With the box unchecked, only the chosen race is computed.

SSR performances Time Long track

Where: Performances (speed skating, long track only)

Reads from SpeedSkatingResults the entries' performances over the seeding distances, and adds them to their record. The athlete is recognized first by the SpeedSkatingResults ID of their record (Identity tab, or the “SSR ID” column of the registration import), then by the ID kept from a previous retrieval, lastly by their name, gender and country — exactly one SpeedSkatingResults athlete must match: EVENT never guesses. Internet is needed. The button only exists when the event record says speed skating and long track; otherwise the message quotes the event's sport and specialty.

The detailed report goes to the event log (source “SSR”; action import_ssr): one line per entrant (their SSR ID and where it comes from, results read, usable, set aside), then the summary — entrants read, recognized by SSR ID or by name, not found, ambiguous, without results (unknown SSR ID?), results read, written, already in the database, usable by the seeding — and each reason for setting a result aside with an example: no date, distance not in the seeding chain, outside the date window, after the event, location not allowed (with the allowed locations), track not allowed. SpeedSkatingResults locations read “City (COUNTRY)”: “Québec (CAN)” and “Quebec City (CAN)” are accepted by the allowed location “Québec” (case, accents, the country in parentheses and the words City, Ville, Ville de, Cité are ignored). The summary cites the most frequent refused venues (“Calgary (CAN) × 12”) and, for a date-window rejection, the allowed dates; both are set in the Event seeding rules, which unfold by themselves.

When results are usable, the seeding is computed again at once (its log follows the report); otherwise the report says why nothing can be used.

SSR cache. Searching for an athlete by name is slow (the site asks for spaced-out requests). So EVENT keeps every search on this computer, under the key last name, first name, date of birth and country (ignoring accents, capitals and extra spaces): the next reading only searches for unknown athletes. A found athlete is kept for a year; a search with no result (not found or ambiguous), for a week. The report says so (“found by name, this computer's cache”, “12 search(es) by name avoided”). The results themselves are always read again from the site, and the race rules (converted times, allowed and excluded venues) apply as before. To search everything again: Clear the SSR cache.

As answers arrive (2.0.30). The reading runs in the background, a few athletes at a time (three, to spare the site, which asks for spaced-out requests): the screen stays free and each athlete is shown as soon as it is received — in the progress bar (“SSR performances: 12 / 40 — ESSAI, Numéro 2: found (SSR ID 952): 12 result(s) read”), in the SSR column of its row, in the list of received athletes under the bar (most recent at the top; in the alert colour if not found, ambiguous or in error) and by an entry in the log, source “SSR”. The whole may take a little longer, but you see what is happening.

Whole event. With Whole event checked, the reading covers the entrants of all races: each athlete only once, on the distances of all their races; the report is made race by race, and the seeding of the whole event is recalculated.

Cancel, writing and errors. Cancel stops the reading: the athletes received stay displayed, but nothing is written (as for the seeding calculation). Otherwise, everything read is written at the end, in one go. An athlete for whom the site answers with an error is “in error” and the others go on; after five errors in a row, the following ones are no longer requested: run it again later.

ChronoFEED performances Time

Where: Performances (with the Whole event box next to Compute seeding)

Reads from the worldwide ChronoFEED results database (competition results shared by FINISH computers) the results of the race's entrants — or of all the event's entrants, box checked — and adds them to their performances, source chronofeed, like SSR performances, but for any sport and any discipline. Only results of the event's sport and discipline are kept (codes of the common data: “SPEEDSKATING”, “LONG-TRACK”…), of a ranked athlete, with a time and a distance. A time already among their performances (same distance, time and date, whatever its source) is not written a second time. Internet and an EVENT licence are needed (the trial does not give access).

An athlete is only found if their record has a complete identity: first name, last name, date of birth and country (three-letter ISO code, the one of the country table: “CAN”). None of it leaves the computer: EVENT computes a key for each athlete (a few tenths of a second per athlete, several at a time; the status bar counts “athlete keys 12 / 143”), sends the server only an identifier derived from that key, in batches of 500, and decrypts the results it receives itself. Cancel stops the reading; nothing is written then.

The report goes to the event log (source “Import”; action import_chronofeed): one line per entrant (incomplete identity and what is missing, no result, or results read, of the discipline, usable, from another discipline, not ranked), then the summary — entrants read, complete and incomplete identities, results read, written, already in the database, usable by the race's seeding — and the reasons for setting results aside (same rules as the calculation: date window, allowed locations…). A server error (licence refused, daily quota, server unreachable or not up to date yet) is stated plainly; what was read before is kept. The seeding is computed again when something new is usable.

The seeding chain needs no setting: a “Performances” source takes all the athlete's performances, from SpeedSkatingResults, from ChronoFEED or entered by hand. The server address is set in the settings.

Example: 1500 m Women, 24 entrants, box unchecked. Summary: “24 entrant(s) read, 21 with a complete identity, 3 incomplete (date of birth × 3); 57 result(s) read, 9 from another sport or discipline, 2 not ranked, 46 written, 0 already in the database, 18 usable by the race's seeding.” Complete the date of birth of the three records, then run it again: only the new performances are written.

Module settings Time

Where: Performances, button at the end of the top bar

This computer's SSR cache: the number of athlete searches on SpeedSkatingResults kept there (“42 SpeedSkatingResults athlete search(es) kept on this computer.”). Clear the SSR cache forgets them all, after confirmation: the next SSR performances will search the site by name again, which takes a long time. Performances already read and the SSR IDs of athlete records do not change.

The cache is a file on this computer (in the EVENT folder of the Windows profile), shared by all events. It is not in the database, which FINISH shares.

Event seeding rules Time

Where: Performances, collapsible bar under the buttons

The seeding chain of this event, source by source, as the calculation uses it: distance (or formula, or other event), calculation (the best or the average of the N best), date window (seasons, season start, days at most, not before, not after) with the effective allowed dates computed for the competition date (“Allowed dates: from 2025-07-01 to 2026-11-07”), venues allowed, venues excluded, factor. Only the fields a source has are shown. The bar unfolds by itself when the last seeding gave no time or when the SSR import set results aside; folded, its title says “Same as the template” or “2 value(s) changed for this event”.

Each value carries a dot:

  • green: the value of the competition template (the event type's own seeding, otherwise its model's); tooltip “Template value: Québec”;
  • yellow: changed for this event; tooltip “Changed for this event; template value: Québec”. The small ↺ button next to it takes the template value again. A source the template does not have is marked “not in the template”.

Hover over a field for its explanation. Venues are separated by a comma or a semicolon; accents, capitals, countries in parentheses and the words City, Ville, Ville de, Cité at the start or the end are ignored: “Québec” accepts “Quebec City (CAN)”, but neither “Mexico City” nor “Salt Lake City”. Empty venues allowed accept every venue. A refused value (badly written date…) gets a red border, with the reason when hovering over the ⚠.

Save and recompute writes the chain into the event's own copy — never into the template nor the other events —, records it in the event log (action regle_performance: before, after, and the list of changes) and then recomputes the entrants' seeding. Races already generated do not change: the message says so (“regenerate the races to apply”); if races have already been run, EVENT asks first. Discard edits goes back to the saved rules; Reset all to the template puts the whole template chain back (to be saved). After an SSR import that refused venues, Add the refused venues to the venues allowed adds them to the venues allowed shown: check, then save.

Example: after SSR performances, “143 entrants, 143 without time” and the log says “447 × venue not allowed (venues allowed: Québec) (e.g.: t1500 2:23.300 2026-02-07 Quebec City (CAN))”. Since version 2.0.20, “Quebec City (CAN)” is recognised as “Québec”: run SSR performances again. To also accept times skated elsewhere, add “Calgary” to the venues allowed (yellow dot), then Save and recompute. The competition template keeps “Québec” for the other events.

Venues allowed Time

Where: Performances, under the buttons

A multiple choice from the list of tracks known to SpeedSkatingResults (“Calgary (CAN)”, “Quebec City (CAN)”…), plus the venues already written in the race rules (marked “(race rules)”). Only performances achieved at the ticked venues count: the calculation takes the best time over the distance on these tracks. Nothing ticked: every venue (the button says “Every venue”). The field at the top finds a venue; Untick all clears the choice.

The choice is written into the event seeding rules (the venues allowed of every source that has them): it is saved with the race's rule; “not saved” reminds you until Save and recompute.

The list of tracks is kept on the computer: it works offline (the first time, the list shipped with EVENT). When a selector opens, EVENT reloads it from SpeedSkatingResults if it is more than 30 days old, only once per launch and at the pace the site asks for; otherwise nothing goes out on the network.

Venues excluded Time

Where: Performances, under the buttons

Performances achieved at the ticked venues are left out of the calculation, even if a venue allowed accepts them. Nothing ticked: “None”. The choice is saved like the venues allowed.

Example: Hollywood Cup, Women's 500 m: venues allowed “Quebec City (CAN)” and “Calgary (CAN)”, venue excluded “Calgary (CAN)”. Only times set in Québec count; a skater who only raced in Calgary gets her entry time.

Corrected time Time

Where: Performances, under the grid

Forces a seeding time on the selected entry (“41.23”, “1:15.12”) with a Reason, then Correct. The correction is the first source in the chain: it stays, calculation after calculation, until it is removed. The source shown becomes “Corrected manually” and the athlete's card shows it.

Remove correction Time

Where: Performances, under the grid

Removes the correction of the selected entry; compute the seeding again to get back the chain's time.

Joker Time

Where: Performances, under the grid

Gives or removes the joker for the selected entry: they are placed ahead of the fastest, in all their races (a top-level athlete with no recent time). The same box exists in the entries grid.

Seeding times of the entrants Time

Where: Performances, the grid

The entries in entry order: rank, bib, athlete, club, seed time, source (Performance, Other race, Entry, Joker, Corrected manually, No time), formation group, heat, and the engine's detail (venue, date, conversion, formula).

The SSR column says what the last SSR reading gave for the athlete (found and how many results, not found, ambiguous, in error); it fills in during the reading.