SonotaCo.JP

[さぎたりうす]

5月の中旬頃から、*A.xmlのフレームごと分析値に変な値（異常に大きな値）が出力されたり、0のままで何も入っていなかったりするようになりました。
m.csvはちゃんと書き出されているように見えますが、ちょっと不安です。
原因がわかりますでしょうか？

[SonotaCo]

[SonotaCo]

すみません、当該のクリップですが、今再分析するとどうなるでしょうか。
私の所で最新版で再分析したら、再現せず、直ってしまいました。

キツネにつままれています。

とりあえず、壊れているのは パスデータで現在参考用に出力しているだけで、利用していない筈のデータです。

特にその前後に改版したわけではない筈ですが、その日の分は調べた範囲では全滅でしたが、その前後の日は正常でした。 バージョンもさぎたりうすさんは 2.13 でウチは 2.15 でした。壊れ方がまたとても変で、メモリが連続して破壊されたような感じです。複数のマシンで同じ日に発生しているので、ソフト的な原因がある筈ですが、見当がつきません。
いったいどうしたらこんなことが起こるのか、どうすれば再現するのか、夜も眠れなくなるような難問です。

[さぎたりうす]

[ts007]

私も気になって調べました。５月２日にも１個。５月４日にも２個ありました。５月２７日に５個ほどありました。それらは、Ｖ２．１５かＶ２．１６の解析です。何回も解析しなおしたように記憶していますが。他の日でもよくあることなのに、出現位置はあっているような。ふしぎです。確かに長い値と０ばかりのがあります。なんとなく、０は、解析ができなかったもので流星と判定されたもので、長いのは、パラメータを色々と変えてやっと流星と判定されたもののように感じられますが。取り会えず３日分見た所での感想です。

[SonotaCo]

情報ありがとうございました > ご両人

私の所ではlogを同時に出しているカメラがあり、A.XMLが異常でも分析時に出しているログの方は問題なかったので、分析に問題はないと思います。
分析が終了してから、A.XML を出力する間の処理で、フレームデータを記憶しているメモリがこわされる感じのようです。

明日調べてみますが、手ごわいとワナをしかけて再現を待つことになるかもしれません。

[さぎたりうす]

12mmの5月分以降を調べました。きちっと数字が入っていたのは、5月1/2、7/8、8/9と昨夜6月5/6のみでした。ほかは全部0のパターン、どれかに異常に大きな値が入っているパターン、小さな値（0.000007等）が入っているパターンでした。
6mmでおかしくなっていた数字とは整合しません。
こちらは同じ夜の分は、まったく同じパターン（入っている数字も同じ）でおかしくなっています。また、magが0になっているものと、7.9とかがずっと入っているものとがあります。

[SonotaCo]

原因が判明し、これを修正した UFOAnalyzerV2 V2.18 をリリースしました。
A.XML中の ua2_fdataレコードはこれまで利用されておらず、将来の経路詳細分析用に備えられていたものでした。
V2.18 からは ua2_fdata2 レコードに レコード名を変更し、従来の ua2_fdata は無視することにしました。
V2.18以降で分析しなおすことにより、ua2_fdata2 レコードを付与できますが、従来のものを再分析する必要は今の段階ではありません。

原因は、クリップの分析後、リストをクリックしてクリップを切り替えた時に、ua2_fdataレコードを読み直すのですが、この読み込みにバグがあり、そこで壊れていました。
閲覧だけなら破壊されないのですが、その状態で A.XML をセーブするような 変更などを行うと 壊れた A.XML がセーブされていました。

この情報は将来のUFOOrbitなどによって輻射点が求まった後に速度誤差を算出するために 設けていたものですが、壊れたものが含まれている可能性があると役に立たないので、これまでの ua2_fdata部分は再処理すると捨てるようにしました。もちろん V2.18 以降で再分析すれば正しいものが付きますが、使う側のプログラムが登場したときに考えればよいと思っています。

久々、バクらしいバグでした。使っていない部分のバクで、操作状況によって発生するものなので、完全に見逃されていました。ご指摘、ご協力ありがとうございました。
-------
すみません間違ったパッケージが数分間公開されました。
正しいのはUA218B.lzh か UA218B.zip です。