logデータの突き合わせプログラムを書けという自分への指令(5)

ログの原簿であるLog200のデータにある交信レコードをup-to-dateにしているメインのデータベースであるMariaDB (MySQLコンパチブル)のデータと照合して,MariaDBに欠落しているレコードがないか,を確認するプロジェクトですが,照合スクリプトの最終形が吐き出したエラー分について手で確認をしました.

MariaDBとの照合は,日付,時刻(±5分のマージン)とコールサインで検索しました.参考の為に,モードの違いについても,検索してヒットしたレコードと原簿のレコードについて照合して,違う場合はwarningとしました.

原簿にある7万9千レコード全部について照合するのに,190分ほどかかりました.そのうちほとんどがMariaDBが占めていて,PerlのCPU占有は30秒余りです.

その結果,モードの違いまでも含めると,540ありました.検索条件が違うので(4)の293件より多くなっています.

このうちwarning扱いのモードの違いをのぞいたエラーは,128件で,手作業で照合しました.

ほとんどが,コールサインの間違いです.もらったQSLカードで修正したものがほとんどです.また,時刻の違いも何件かありました.時刻は,PCの時計データを取り込むようにしていますが,そのPCが仮想マシンのため,仮想マシンが再起動した直後に時刻データが不正確であった可能性があります(これは仮想マシンの特定のバージョンにより含まれているバグです).可能性は低いとはいえ,自分が間違っている可能性もあり,間違っているのは自分か相手か断定できません.しかし,もらったQSLカードに返信の形で発行するQSLカードは相手の時刻に合わせた方が無難なので,ほとんどのケースで相手に合わせて修正してます

完全な漏れは,先に判明したUR2FEO局の2交信分の他は,8N2SEA/2局との1交信のみでした.いずれも追加済です.思っていたよりうんと少ないレベルなので,安心しました.

これで,少なくとも原簿であるLog200に記録されている交信は全てメインの交信データベースにあるという状態にできました.

ただし,多くはない思いますが,原簿に漏れている交信もあるはずです.それらについてはどうしようもないです.QSLカードが届いて,該当する交信レコードがないときはこっそり追加するしかありません😓

ただし,あり得ない時間や明らかにJST/UTCの計算違いの場合は,こちらの時間にしています.

logデータの突き合わせプログラムを書けという自分への指令(4)

最初のバージョンでは,日付とコールサインとモードが一致するという条件にしました.レコードが完璧に抜け落ちていたのは,2QSOのみで,それがいずれもUR2FEO局です.全くの偶然か,そのコールサインだけひっかかるような原因があるか,当時のLog200からMySQLにexportするスクリプトは残っていないので,全く探りようがありません.

この段階で,レコードの不一致があったものは,293件です.全レコード数は,7万9千件ほどなので,0.37%です.先日発表された,東京の新コロナの抗体保有者とコンパラです😓

目だったレコードの不一致は,モードの不一致です.50MHz帯の交信のSSBとCWが入れ替わっていることが多いです.周波数からモードを自動的に決める機能が,50MHzではあだとなっています.交信相手からQSLカードをもらって,気づいて修正しているところが多いです.

MariaDB(かつてはMySQL)のデータは修正しますが,オリジナルのログデータは修正しないことにしているのでこの不整合が発生します.

考えてみれば,ログソフトからMariaDBに取り込むときの漏れを問題にしているので,モードの不一致はドントケアーとします(警告だけ出すようにします).

その代わりに,時刻を±5分のマージンで絞ることにしました.この制限を付けても,全体の処理時間はほとんど変わりません.

そんな感じで何度か試行錯誤して練ってきたほぼ最終版を今走らせています.一度走らせると3時間待たないと結果が出ないので,試行錯誤のサイクルは長いです

関連項目

MariaDBのデータをMacかCore i7のWSに移して,テストすればたぶん何倍か早くなると思いますが,慌てることはないので😓

RasPi Kernel 5.4.xに

Raspberry PiのKernelが,Kernel V4の最後のlongterm 4.19.xから,V5最初のlognterm 5.4.xになりました.弊serverも上げてみました.

Majorなバージョンが上がったといっても,longtermとして次の系列なだけなんですが^^;

Raspberry Pi用のKernelは,次の系列がリリースされると,前の系列をサポートしてくれなくなるので,やむを得ません.

いまのところ特段の問題や,気がついた点などはありません.

WSのKernelを5.6.7にしてみた

どういう経緯だったかすっかり忘れてしまったのですが,Core i7のWork Station(WS)のKernelは,最新安定版を追わずに,logtermの4.19.xにとどめていました.5.xのどれかにした時に,何か不都合があったはずなんです.

不都合があったにしても,それを忘れるくらい時間が経っているので,改善されたかもしれないと思い,最新版の5.6.7にしてみました.

起動して,FirefoxからBLOGに書き込むまでは問題ないようです.KVMも動いてます.

しばらく5.6.xを使って様子を見ることにします.

iTunesの音飛び事件

あいかわらず,iTunesで自分の音楽ライブラリーを古い曲から順に聞いています.昨日,Gloria Estephan & Miami Sound Machineの1-2-3を聞いていたら,途中で突然途切れて,次の曲に飛びました.電子音源の音飛びです😓

今日,思い出して,再現性を確認したら,2′ 34″のところで毎回飛びます.その少し後から再生すると最後まで演奏されるので,まさに,2′ 34″のところに傷があって飛ぶようです.

データ形式は,128kbpsのm4aです.手持ちのCDからiTunesでデジタイズしたはずです.

iTunes でなくて,Quick Time Playerで再生してみたところ,同じ場所で再生が止まってしまいます.何らかの原因で音源データが破損してしまったようです.タイムスタンプは同じ時にエンコードした前後の曲と同じですし,rsyncでも同じと判断されます.ですから,「内部的」に破損してしまったようです.

Time Machineで去年の11月のデータに戻してみましたが,同じです.

Time Machineの他にもいくつかバックアップがありますが,そのひとつのRaspberry Pi 4Bのサーバー上のバックアップからコピーし直したら,正常になりました.

内部的破損ということであれば,壊れたファイルの部分に別のファイルが書かれると,そのファイルも壊れる可能性があるので,壊れたファイルは改名してそのまま残しました.

追記(2020/03/21)

その後いろいろ調べてみましたが,セクター不良とかではないようで,1年くらい前のバックアップの同曲のファイルは既に皆壊れていました.

今回復元に使用したバックアップは,3年前まで使用していましたが,その後都合で使用を止めたものでした.

Catalinaは使用せず,引き続きMojaveを使っています.
差分バックアップではなく,rsyncで同期してました.