数日前から「セキュリティ・アップデイト」で MariaDB のアップデイトが来ていた。
前回のアップデイトの時、直後に CQRlog がデータベースを読み込めなくなってしまったことがあった。
何のことはない。
MySQL ベースが突如 MariaDB に切り替えられることになったのだから。
幸い CQRlog を再インストールすればきっとうまく行くだろうと思った。
今回は MariaDB への移行を「いいえ」とした。
トタンに ubuntu にエラーメッセージは出るわ、CQRlog は起動せんわ。
「だったら使いもしない MariaDB なんか完全削除してまえ。」
事は更に悪くなった。
もう一度 MariaDB をインストールし直し、CQRlog も新たにインストールした。
それにしても CQRlog も MariaDB に振り回されない作りにしてほしいものだ。
ログアプリは相変わらず CQRlog を使っているが、21 Aug. までは QSO リストから対象をフィルタで指定し、LOTW にデータ・アップロードができた。
しかし、eQSL にはうまくアップロードできなく、adif ファイルを作成してオンラインでアップロードしていた。
ところが 22 Aug. には LOTW へのアップロードがエラーでできなくなっていた。
Ubuntu のアップデートか、CQRlog のバージョンアップが関係しているのであろう。
CQRlog のバージョンが 1.8.2 になって eQSL アップロードに再挑戦してみた。
難なく成功できた。
それでも LOTW は相変わらずエラーが出る。
ファイラーを見ると 21 Aug. までは tq8 ファイルが生成されているのに、22 Aug. からは生成されていない。
SSB でもない訳でないが、JT65 を始めたトタン、多くなった気がする。
過日も JA 局に jarl.com を通じて eQSL を訂正してもらったが、実は私も JA 局にやってしまった。
私は Turbo Hamlog 使用者でないので、ロギングは LibreOffice Calc で行い、更に eQSL と LOTW のために CQRlog に転記というスタイルを採っている。
CQRlog はリグ・コントロールにも対応しているが、JT65 のインターフェイス・セッティングにも難儀した私には勇気がナイ。
それができれば、リアルタイム・ロギングして効率が上がるのはわかってはいるのだが・・・。
そうしたところ、 W からも eQSL で Wrong Band として reject されてしまった。
恐らく先方は 20m バンドのつもりなのかもしれないが、こちらにはライセンスがないし、もし 17m であればまだ W との JT65 QSO がないことで異議を申し立てた。
