約１か月連続キャプチャできていましたが、キャプチャできなくなる事象が発生したのでその原因調査と対策をしていきます。そして恒久対策に向けた対策案も検討して、以前に公開したツールの今後の強化項目にしていきます。
調査 その1
まず、状況整理ですが、キャプチャは、1回のcron起動で、３つのATOM CAM2を順にキャプチャしてファイル保存するように実装していました。一番最初にキャプチャするカメラ画像は10:00にキャプチャしたものが最後で、そのほかの２つは、14:40が最後でした。つまり、１つ目のキャプチャに失敗しても2つめ以降のキャプチャはできていましたが、その後３つともキャプチャできなくなっています。運用点検のため、hsBoxを再起動したタイミングあたりでキャプチャできなくなっていたようです。
まずは、切り分けしていくためウォークスルー方式で問題となりそうなところを順にチェックしていきます。まずは、NASのマウント状況を確認しました。マウントはできており問題ありませんでした。
次に、ATOM CAM2のIP探索の確認です。 スマホでATOM CAM2のIPを確認して、そのIPが取れているかを、arpコマンドで確認します。 すると、３台のカメラともにMACが取れていないことが判明した。
暫定対処 その1
それぞれの、IPにpingを打ってみます。 それぞれ、反応がありMACがとれました。これにより、14:40が最後だった2台のカメラのキャプチャが復旧しました。
残りの1台は、NAS上へのフォルダ作成には成功したものの、画像ファイルがまだ置かれていない状況になっています。
根本対策 その１
今後の強化策です。 既存実装でもブロードキャストでpingを打つ実装を入れていますが、ブロードキャストではarpに反映されないのが問題のようです。そこで、MACが取れなかったとき、DHCPで割り振られる範囲に対して明示的に個別にpingを打つ実装を追加することにします。
調査 その２
まだ復旧できていない1台分のカメラについて調査を行います。
実装を、最後にキャプチャできたタイミングで何かあったかを確認してみましたが、特に問題はないようです。手動で、FFMPEGコマンドを実行すると、次の結果が返ってきました。
> python3 .\cap_once.py
FFmpeg failed: Command '['ffmpeg', '-rtsp_transport', 'tcp', '-i', 'rtsp://＊＊:＊＊＊@192.168.＊.＊/live', '-ss', '00:00:01', '-vframes', '1', '-q:v', '2', '-y', '\\\\192.168.＊.＊\\＊＊＊\\2026-01-25\\20260125_124510.jpg']' timed out after 20 seconds
タイムアウトしていますが、pingは通っている。 前のセッションが残っていて接続待ちの状態になっている？のかという説はあるが、 スマホからの確認では動作している。 スマホでの画像表示と、rtspは別動作なので、rtsp側だけの問題(セッション残留？)の可能性がある。
暫定対処 その2
セッション残留の問題だと仮定して、rtspの再起動での復旧を試みる。スマホでの操作で一度「PCで再生」をオフにして再起動してみる。
この操作を行うとrtsp用のユーザとパスワードが更新された。新たなユーザとパスワードを反映すると、キャプチャに成功し、 自動キャプチャは復旧した。
問題の原因は、残留セッションとみてよいようだ。 これは、ATOM CAM2側で何とかしてほしいが、 録画の都合（解像度の高い録画をしたい）から古いバージョンのファームウェアを使用している。このため最新パッチを適用することができず、ATOM CAM２側での”残留セッション”の改善は望めない。そこで、hsBox側での別の改善策を取ることにする。
その２の問題の 改善策案
”残留セッション”問題の対処方針は、上の”暫定対処”の問題を早期検知し、できるだけ手間をかけずに復旧できるようにするというものである。
復旧手順を明記した内容での問題検知通知を出し、スマホ操作で「PCで再生」を再起動し、あらたなユーザ名・パスワードをGUI設定画面で更新するというものである。
とりあえず今時点での簡便な復旧策はこの辺でしょう。
他に良い案があれば、コメント投稿をお願いします。