SD-Cardのrecord以下のファイルが保存日数前に削除される

[ohzaki]

以下のような設定にしていますが，record以下のファイルが保存日数前に削除されます(5日間ぐらい)
ローカル録画スケジュール: 常時録画
SD-Card録画: On
ファイルの自動削除: On
保存日数: 50

time_lapseの方は問題なさそうです

[mnakada]

SD-Cardの残容量どのくらいですか？
多分アプリが容量足りなくなって消している気がします。

[ohzaki]

アプリには以下のように表示されています
SDカード管理: 426.37 GB/476.66 GB
使用済み: 50.28 GB 残り: 426.37 GB

[Hiii555]

ちょっと興味本位なのですが計画では何日録画で何日後削除にされてますか？
１日まるっとで大体5GB1500位のファイル数になると思いますが10日ちょっとで
512GBのSDカードがアプリとatomcam_toolsの認識がどうなっているのか気になります。

[ohzaki]

ちょっと興味本位なのですが計画では何日録画で何日後削除にされてますか？
意味がよくわからないのですが，設定は↓のとおりです
#91 (comment)

[Hiii555]

例えばrecord内の日時フォルダ毎無くなっていくのか、先入れ先出しの様にフォルダは残るがファイル１分刻みに
消えていくのか、毎日日替わりのタイミングでなどキッカケのヒントなどありませんか。

[ohzaki]

消えるタイミングは把握できていませんが，1分ごとのファイル単位で消えていくのではなく，1時間単位で時間フォルダが消えていきます
5台 ATOM Cam Swing がありますが，消えていく時間フォルダは全部同じではなく，残り方が違います
どうやら使用量に比例して早く消えています
使用済みが 45.93GB, 49.56GB, 49.37GB, 50.9GB, 45.95GB となっていたので，50GBを越えると次の何かのタイミングで越えないように一番古い時間フォルダが削除されているようです

[mnakada]

toolsでは容量で削除はしていないので、元々のiCamera_appの動作だと思われます。

[ohzaki]

もう少し検証しましたが，やはり50GB前後で制限があるらしく，そこを越えると record が削除されていくようです
29.0G record
21.1G time_lapse
それは元々のiCamera_appの動作だとして諦めるしかなさそうです

そこで，「ファイルの自動削除」機能ですが，record と time_lapse で別々に設定できるようにできないでしょうか？
以下のような設定ができればうれしいです
record: 自動削除しない(元々のiCamera_appが勝手に削除するに任せる)
time_lapse: 5日

[mnakada]

変な容量で制限されてるので、気になって何が起きてるのかを見てみました。

/media/mmc/record/以下の削除を行なっているところの条件です。

 uint32 *stat;

  :
  :

  if((409600 < stat[1]) && (stat[0] < stat[1] * 30)) return 0;
  :
  :
  // rm -rf /media/mmc/record/{date}/{hour}/

ここでstat[0]はSD-Cardの全体の容量（単位KiB)、stat[1]はSD-Cardの空き容量（単位KiB)で、ここで抜けないと rm -rf /media/mmc/record/{date}/{hour}/ を実行します。

条件式の前半は問題ないです。
後半は問題で、全体の容量の1/30を空き容量が下回ると削除に入るというコードになっていますが、stat[1]の方を30倍して比較しています。
stat[1]は32bitなので空き容量が136GiB以上だと30倍するとoverflowします。
（0x1_0000_0000 / 30 = 143,165,577KiB = 136GiB）
overflowしたタイミングで32bitを超えた部分は捨てられて、条件が成立して削除されていると思われます。

なので、結論としては256GB以上のメディアでは/media/mmc/record/以下のファイルは保証されません。
これはiCamera_appのコードの問題なので、対応策は無いです。
基本的には128GB以下のSD-Cardを使うか、SD-Cardに大量にファイルを貯めるのではなくNASに逃すようにしてください。

ちなみにtoolsが作ってるファイルの方は特に容量制限してないので容量が溢れないように保存日数を制限して運用が必要です。

[Hiii555]

NASで運用しています。今現在約１ヶ月分約150GBがrecord配下にあります。おおよそ計算上からもファイル数も
容量も妥当なところで削除されていくという現象は見られません。

[ohzaki]

解析ありがとうございます
128GB以下のSDカードならば問題ないということですね
ただ，その場合でもやはり，「ファイルの自動削除」機能で，record と time_lapse は別々に設定できるようにしてほしいです

それから，NAS保存についてですが，以前はNAS保存していましたが，5台の ATOM Cam Swing でNAS保存すると，どこかの処理がボトルネックになるらしく，毎分動画の先頭の1,2秒が録画されない(SDカード上の動画も)という現象があったため，NAS保存はやめました

[kurokouji]

@ohzaki さん、有線LAN接続を試してみてください。これにより、動画の録画が毎分の先頭から行われるようになります。AtomCam2やAtomCam Swingは2.4GHzのWiFiを使用しており、近隣の無線LAN環境との干渉が生じる可能性があります。また、5台のAtomCam Swingを同時に使用する場合、WiFiの混雑が懸念されます。UCTRONICS PoE USB Ether Adapter(U6113 RTL8152)を使用すれば、POEスイッチングハブとLANケーブルで接続でき、カメラ取付位置に100Vコンセント工事が不要になります。HD画質での録画では、1分ごとに約8GBの動画ファイルが生成されますが、5台のAtomCam Swingが同時にNAS保存を開始すると輻輳が生じ、CPUの処理にも影響します。WiFiでの接続がボトルネックとなっています。手間がかかるかもしれませんが、安心できる防犯対策として有線LAN接続をお勧めします。

[ohzaki]

ご提案ありがとうございます
現在，長さ4.5mの ATOM Cam Swing専用ケーブルで接続しています
このケーブルの手元は Type-A ですが，Type-A(メス) - MicroUSB(メス)変換ケーブルを通して UCTRONICS PoE USB Ether Adapter と接続できるんですかね？
それができれば有線LAN接続も考えてみたいですが

[kurokouji]

ClosedになっているIssue
SwingにてUSB-Etherが認識しない #93
こちらで、詳しく報告があります。
「個体差、もしくは本体内部の故障」により接続できない場合もあるようです。
「Cable Matters製RTL8153と、AmazonイーサネットアダプタRTL8152はAtomcam2とSwingにて問題なく使用することが出来ました。」
との記述もあります。
参考まで。

[ohzaki]

情報ありがとうございます

[ohzaki]

ATOM Cam Swing専用ケーブルでは駄目そうですね
有線LAN化は諦めます
https://honeylab.hatenablog.jp/entry/2021/06/26/235714
「付属のケーブルは電源の２本しか接続されていないため、このケーブルのA側を加工してもダメです。」

[accept]

USB-EtherのIssueを建てたものです。
こちらで話題にしていいか分かりませんが、現在Uogw製のL字変換を使用して屋外設置のSwingを有線LAN接続で運用しています。
https://a.co/d/0IFzrwe

上記のL字変換は私が購入した時点ではデータ通信が可能なので、これにBuffalo製のUSB-MicroBケーブル3mと
https://amzn.asia/d/hE6K6JB

このような変則的な変換アダプタを使用して、UCTRONICS-U6113を接続し運用している状態です。
https://amzn.asia/d/fBH8waO

L字変換は日本のAmazonでもあるにはありますが高いのでUSAmazonから購入する方がいいかと思います。
https://amzn.asia/d/6JfZ2Iv

なお、元のIssueでは個体差での通信不良という結論になっていますが、その後新品のSwingでも延長するとブザーによって認識が変動する問題が出ているので、ブザーによってオンオフされるGPIOがUSBに何かしらの影響は与えているようです。
実際この方法でUSBを延長すると手元にあるNICではUCTRONICS-U6113しか認識しませんでしたので…

それと同じくUogw製のL字変換で長さが長いものがあるのですが、
https://a.co/d/55DayJK
購入してテストしてみましたが、こちらもデータ信号線は通ってはいるもののケーブル品質が悪く、ブザーに関係なくすべてのNICで通信できませんでしたので有線NIC使用には使えないと思います。
参考になりましたら幸いです。

[accept]

すみません、追記と補足です。
現状延長ケーブルやNIC、Swing本体、ブザーの状態の組み合わせによって認識したりしなかったり、手動でモジュールをロードすれば動いたりと安定しているとは言い難い状況なので、環境によっては同じ組み合わせでも動作しない可能性があります。
なので参考程度に留めてください。

また、うちの有線環境でもブラウザ上からSwingを首振りさせるとWiFi時よりもカクつくというか、通信が不安定な挙動が見られます。
延長している関係でモーター等のノイズにも弱くなっている、延長した結果の電圧降下でSwingの動作そのものが不安定になっている等が考えられますので、そちらもご留意ください。

[ohzaki]

いろいろ情報ありがとうございます
Uogw製のものがいろいろ出ているのですね
一番気になるUogw製のL字変換で長さが長いもの https://a.co/d/55DayJK が使えなかったというのは残念です
すごく参考になりました

[mnakada]

ただ，その場合でもやはり，「ファイルの自動削除」機能で，record と time_lapse は別々に設定できるようにしてほしいです

Ver.2.4.1で対応しました。（問題があったためVer.2.4.0は取り下げました）

[ohzaki]

ファイルの自動削除の対応ありがとうございます
正常に動作しています

128GBより大きいと残量検知がおかしくなるということで，現在512GBのSDカードの先頭128GBでパーティションを切ってFAT32でフォーマットして使っています
そこでふと思ったのですが，iCamera_app が 128GB までしか正常に扱えないので，残りの空き領域を別パーティションで作って，iCamera_app が自動削除する前に古い録画ファイルをもう一方のパーティションに移動できれば有効活用できるのではないかと思いました
atomcam_tools は FAT32＋exFAT構成に対応していますが，FAT32 の方は 128GBより大きいと同じ不具合が起きますよね

[mnakada]

この問題は、AtomCamの本体のiCamera_appが元々持っている問題で、toolsを入れてなくてもrecordのファイルはoverflowします。
iCamera_appのrecord_roll_delete_handler()の中で

        if ((409600 < statfs[1]) && (statfs[0] < statfs[1] * 30)) ....

のところを

        if ((409600 < statfs[1]) && (statfs[0] /30 < statfs[1])) ....

にすれば良いだけなのでメーカーが問題に気づけばいずれ対応されると思います。
申し訳ないですが、あまり変な対応をtoolsにいれると余計な問題がでるのでこれについては特に対応するつもりはありません。

[ohzaki]

はい，ファイルの自動削除で record と time_lapse を別々に設定できるようにしていただいたので，これで十分だったのですが，ふとちょっと欲を出した考えが浮かんだので提案してみました
これでこの issue はクローズさせていただきます
いろいろとご対応ありがとうございました