2015年11月1日日曜日

motion再び…

ハマりました。原因が判ってしまえば簡単でしたが、一日潰した気がします(笑)
Raspberry Pi2でとりあえず動かしで動作チェックを行っていますが、どうもUSBバスの信号が安定しないのか複数のカメラで画像内のデータが相互に干渉しているのでOSのバグかもということでRaspbianをRaspbian WheezyからRaspbian Jessieへ入れ替えるべく作業を終え、本丸のmotionの動作チェックです。ですが…motion動かねぇ(笑)
最初からデーモンとして動かしたのが一番の原因かも。
いろいろなエラーが出まくりました。

最初に気づいたのは画像フォーマットがおかしいというようなエラー。
[1] [ERR] [VID] v4l2_do_set_pix_format: Error setting pixel format.
VIDIOC_S_FMT: :
[1] [ERR] [VID] VIDIOC_TRY_FMT failed for format v4l2_set_pix_format:
[1] [ERR] [VID] v4l2_set_pix_format: Unable to find a compatible palette format.
最初にこれが気になってしまったのがそもそもの原因です。

他にも
[1] [NTC] [STR] http_bindsock: motion-stream testing : IPV4 addr: 127.0.0.1 port: 8081
[1] [CRT] [STR] http_bindsock: motion-stream bind() failed, retrying:
[1] [ERR] [STR] http_bindsock: motion-stream socket failed, retrying:
[1] [NTC] [STR] http_bindsock: motion-stream testing : IPV4 addr: 127.0.0.1 port: 8081
[1] [CRT] [STR] http_bindsock: motion-stream bind() failed, retrying:
[1] [ERR] [STR] http_bindsock: motion-stream socket failed, retrying:
[1] [CRT] [STR] http_bindsock: motion-stream creating socket/bind ERROR:
といった画像出力ができていなさそうなエラーがありましたが、その原因は画像フォーマットがあかんのだと思ってとりあえず忘れることに。

motion.confやthread.confのパラメータがバージョンが違っていて微妙に変わっていたり、値が変わっていたりしました。そのためにパラメータを必死にチェックしていましたがあまり好転しませんでした。

ここで一日orz

ほとんど変化しないので、とりあえず一つのカメラだけで動作確認をしてみようとthread2.confの値をmotion.conf内に設定しなおしてmotion.confだけで動かすようにしました。
これでも変化が無く、最終手段のデーモンモードをオフにして起動してみました。

syslogに残っているログとあまり変化が無いものの、リアルタイムにログが出てくるので一目瞭然でした。(最初からやっていれば…)

コマンドラインで叩くのは非常に簡単。

$sudo motion ./motion -n

これで、motion.confでデーモンモードになっていても強制的にそのプロセス上で実行できます。

その出力でまず、ポート関連のエラーが出ているのに気付きました。

[0] [NTC] [STR] httpd_run: motion-httpd testing : IPV4 addr: 0.0.0.0 port: 8080
[1] [NTC] [VID] vid_v4lx_start: Using videodevice /dev/video0 and input -1
[0] [ERR] [STR] httpd_run: motion-httpd failed bind() interface 0.0.0.0 / port 8080, retrying:

addrが0.0.0.0になっているのは引っかかりますが、とにかく8080ポートがエラーに。
しかし、8080ポートがwebから開けちゃってたりします。ブラウザのキャッシュかもしれないので更新もかけても表示され、確かに動いていないはずなのに動いている。

そうです。プロセスが起動しているんです。(笑)

rebootなどで散々再起動させていたわけです、/var/run/motion/motion.pidが作られていなかったのでプロセスが上がってなかったと思ったんですが、どうも思いっきり動いています。

$sudo ps -A

これで全プロセスの表示ができます。sudoはいらないかも。
そこでしっかりmotionのプロセスがいました。

$sudo kill 1281
とかそのプロセス番号で終了。終了までちょっと時間がかかりました。

プロセスが終了できたことを確認したうえで、
$sudo motion ./motion -n
でじっこうしてみます。
エラーもなく無事に起動している様子。まじかい(笑)
ブラウザからもしっかり画像が確認できました。
[CTRL]+[C]でいったん終了。

thread1.conf thread2.confもmotion.conf内から有効にして再度起動したところ。動きました。

そりゃmotionが動いているところに別のプロセスから動かせば動かないよね…。

さて、プロセス起動がたぶんmotionユーザーを使っていないとかそんなレベルだと思うのでinit.d関連の修正ですかねぇ。

/etc/init.d/motionをみるとdefaultの値をとってくるようになっていました。

motionをinit.dで起動させるために/etc/default/motion内で
start_motion_daemon=no
となっている no を yes に変更すると起動するようになっていました。
start_motion_daemon=yes
一か月前ぐらいにやったことをもうすっかり忘れてる(笑)

結論から言えばJessieにアップさせてもUSBカメラの相互干渉は発生してしまいました。
原因はUSBバスパワー不足なのか、motionなのかぐらいしかなさそうです。

ただ、動作クロックの設定項目などがGUI上から設定できるようになっていたり、かつ、設定項目がPi2らしい設定になっていました。正直標準の動作クロックがいくつなのかも知らなかったので(笑)

0 件のコメント:

コメントを投稿