JA9MAT 小町さん
状況の紹介ありがとう御座います．
BktTimeSyncは使ったことが無いので，想像ですが．．．．．
> 今朝ほど「ソフト」が残したログを見ますと、下記のとおりタスク・スケジューラーで起動を指定した時刻（15:59:57)に対して２秒遅れています。但し、二回目から明朝までは遅れません。この影響なのかどうかわかりませんが、確かに昨日は、１６：００スタートの３０分モードの局をスポットすることができませんでした。
> ----------------- Log --------------------
> Last Sync :Thursday, February 23, 2023 15:59:59 -> 15:59:57秒にスケジューラーの起動を設定したにもかかわらず2秒遅れています。
> -------------------------------------------
>
> 初回の起動時だけ遅れる原因が、PCのせいなのかWindowsなのかわかりませんが、しばらくログをみながらやってみます。
最初の起動ではプログラムを起動するのに時間がかかっているのでしょうが，それ以外には以下が考えられます．
インターネットでの往復時間（RTT）がある値以下になるまで何度も時刻取得を試みているのではないでしょうか？
こちらでは往復時間は，0.05秒前後ですが，最初は0.1～0.4秒かかる場合が有ります．
最初は，サーバー名からＩＰアドレスを得る時間とARP（Address Resolution Protocol）でMACアドレスを得るため時間がかかるのではと思います．
１．タスク・スケジューラーでの起動を 15:59:55 にしても良いかも知れません．
２．更新時刻は，５７秒ではなく，５６秒でも良さそうに思います．（たしかデコード開始が一番遅いのは，FST4W-1800で５５秒弱だったと思います）
３．Timeout の設定が有りますが，更新開始から時刻修正終了までの時間だと思われます． この値を１秒（もしくは２秒）に設定すると良さそうにも思えます．
上記の「１」だけで解決するかも．．．
> あともう一つの疑問は、一度に同じ局をマルチでデコードした際にWSPR Netにアップロードされるレコードです。これを、指定する術はないものかと思います。だいたいは最低のSNRのレコードがアップロードされます。これは、仕様でしょうか？
WSPRnetでは，昨年重複チェックの仕様が変更されたようです．（以前はＳＮＲが異なる場合は重複とはしていませんでした）
送信局・受信局・時刻が同じ場合，重複とみなされ削除されます．最後（最初？）のデータのみ有効となるみたいです．
（手動でアップロードした場合，逆順で最後のデータから取り込まれるみたいです）
確か，FST4Wの場合はマルチでデコードしても，画面・ログでは一番強いデータのみ有効だったと思います．
ＪＨ３ＸＣＵ／１・上林．