Hello,
Currently running a WU stuck at 31,967 % whose remaining calculation time increases as the calculation progresses. Is this a bug, or should I let it keep running? Thanks.

Application
Eternity II CPU solver (pilot) 2.33
Nom
eternity_cf_xp_fin10k-s4-c3_s267_r105754880_105756928
État
Calculs en cours
Reçu
04-10-26 07:18:22
Date limite d'envoi
11-10-26 07:18:22
Taille de tâche estimée
3.600 GFLOPs
Temps de calcul
01:29:46
Temps processeur depuis le point de sauvegarde
01:19:46
Temps écoulé
01:29:59
Temps restant estimé
03:11:31
Portion effectuée
31,967%
Taille de la mémoire virtuelle
4,14 MB
Espace mémoire alloué
7,80 MB
Répertoire
slots/3
ID du process
34688
Taux de progression
19,080% par heure
Exécutable
wrapper_windows_live_227.exe
Nom de l'application
eternity_cpu
Plan Class

Check the stderr.txt in slotfolder for progress status.

In reply to rebirther's message of 4 Oct 2026:

Check the stderr.txt in slotfolder for progress status.

Hello rebirther,
I honnestly don't know what you're talking about :)
Found these 2 items:

(10h23)
Erreur assignation taille wu
Erreur assignation taille application

2026-10-04 08:54:35 (34688): wrapper: running ../../projects/boinc.eternityathome.org_eternity/bw_runner_233.exe (--force-interleave --shard-index 267 --shard-count 4096 --force-jitter-start 105754880 --force-jitters 105756928 --threads 1 --node-cap 2000000000 --seconds 0 --exact-endgame 244:50000000 --endgame-probe 4 --endgame-ladder 4:236:1000000000,3:230:6000000000,2:224:64000000000,1:216:80000000000 --ring-breaks 236 --sigma-tail --no-sigma-main --ncon2-direct 1 --mrv-dem-inc 1 --main-fast 1 --min-save 463 --breaks 192,197,201,206,211,216,221,225,229,233,237,241,246,250 --root-allow exploration_allow.txt --seed 6152026 --epoch cloudflare-boinc-explore --tourney tour)
2026-10-04 08:54:35 (34688): wrapper: created child process 27132
bw_runner: progress 0/122 (0%), restored runtime 0 s
bw_runner: progress 5/122 (4%), restored runtime 0 s
bw_runner: progress 10/122 (8%), restored runtime 120 s
bw_runner: progress 15/122 (12%), restored runtime 179 s
bw_runner: progress 19/122 (15%), restored runtime 239 s
bw_runner: progress 24/122 (19%), restored runtime 299 s
bw_runner: progress 29/122 (23%), restored runtime 358 s
bw_runner: progress 34/122 (27%), restored runtime 418 s
bw_runner: progress 39/122 (31%), restored runtime 537 s

check the last line 31% progress status

In reply to rebirther's message of 4 Oct 2026:

check the last line 31% progress status

Yes, it's blocked at 31,965 % since 90 mins, and the remaining time increases 1 sec every 1 sec ...
Currently 5 hours remaining.
Average runtime on this machine +/- 30 mins
Should I cancel it ? or leave it as it might be "special" ?
Thank you and have a nice week-end.

Try to restart BOINC and see if the progress status is writing further.

In reply to rebirther's message of 4 Oct 2026:

Try to restart BOINC and see if the progress status is writing further.

I paused it and now it runs.
Thank you rebirther :)
(I was hoping to have "found" a special one ;))

Thanks rebirther for helping out. Phil, I checked: that task finished and was validated, after 2 h 52 min instead of your usual ~30 min. Some tasks simply go much deeper than average, and during that time the progress bar can stay still for a long while. It wasn't stuck. The safest thing is to let such tasks run: they finish on their own and count normally.

A follow-up on the progress bar: app version 2.35 is now live for Windows and Linux. You don't need to do anything, BOINC switches automatically as your machine downloads new tasks. Tasks you already have finish on the version they started with.

What changes:

progress now counts the real number of tickets in each task, so it no longer reaches 100% early;
during an unusually long ticket the bar keeps moving slowly instead of freezing;
on Linux systems set to a language that uses a decimal comma (French, German…), progress is now reported correctly.
If a task still looks stuck, the best thing is to let it run: long tasks finish on their own and count normally.