2020年10月20日火曜日

Rock64にEPGStation

 CPUパワー的にはいけんじゃないの?とNanoPi NEOにEPGStation載せてみたまでは良かったんですが、結局、録画はできそうなもののエンコードに難があって、rateは高く設定しなきゃなんないわリップシンクできないわということで、これじゃアカンね… 結局、Allwinner系SoCではアクセラレーションかけられず、で、ダメなんだね(泣)。はぁ…、NanoPi NEOでできそうなアプリが減っていく…。

まぁ、ラズパイ3Bで本線は確保してるんで所詮はバックアップなんですが、そうは思いつつも、ちゃんと録画性能ないものに電気食わせてても仕方ないので、やはりrock64を持ち出すことにしました。これならラズパイ3Bよりも安くて速いし…

Rock64 + Raspi3用ケース

ボードサイズは同じだし、USBポートの数が違うけどHDMIなどの位置も同じだから、電源コネクタの違いさえ加工すればラズパイ3B用のケースに収まるよね、ということで、ラズパイ用のケースを流用してるんです。

今回もそれでいこうと思ってピックアップしたケース、3段重ねタイプでした。

入れてみると、この、真ん中にある「中層」の薄い部分、ラズパイとrock64の部品配置の違いで完全に邪魔であることが判り、あえなく総撤去。あとはそれに加えて、電源口の違いを修正すれば収まってくれます。

ということで準備完了。なお、RK3328は、経験上それなりに熱くなるので、効果のほどは微妙ですが、放熱器を乗せてあります(下の銀色の箱はHDD)。これでも、もしかすると夏場、h.264エンコードの際に熱くなりすぎるかも知れません。

これでrock64は3台目になるんですが、今までとは異なり、armbianをインストールしてみました。Armbian rock64には、現時点でLinux5系のイメージと、Linux4系のLegacyと銘打ったイメージがあります。私、HDMIモニタを使ってなくてHDMI - VGAアダプタを使っているんですが、Linux5だと、それを使った表示ができません。HDMI直結なら問題ないことは判ってるんですが(HDMI付きのTVでは問題なく表示できるがTVは家族共用ですから…)、基本ヘッドレスとはいえ場合によってはHDMI - VGAを使用するので、Legacyを使います。ここまでは問題なし。

で、チューナーは、PX-S1UDです。


ん?チューナーが動いてない…

mirakurunまでインストールしてチャンネルスキャンしてみると、何も検出してくれません。おやや…とlsusbしてみると、ちゃんとチューナーは見つけてますが、dmesgしてみるとreturn code -12で正常に立ち上がれていません。

 smsusb:smsusb_init_device: smscore_register_device(...) failed, rc -12

 smsusb:smsusb_probe: Device initialized with return code -12

 smsusb: probe of 2-1.4:1.0 failed with error -12

しかしちゃんと先人は居られるもので…ありがとうございます。


久しぶりのカーネルビルド???

まだLinux2.xの初期以前の頃は、PCにLinuxインストールするにしても、PCIカードのデバイスドライバの存在非存在や、ある機能のサポート有無がドライバのバージョンに依存していたことがあったり、ドライバのサポート状況を見てPCIカードを選んだりドライバソースを更新するなどで、比較的頻繁に、カーネルのreconfigやbuildをやっていました。もうだいぶ昔のことで、2.x後期頃からそのような機会も大幅になくなり、ほぼ一回インストールしたらカーネル再構築することもなく…と、長らくエンドユーザーに徹しておりました(汗)

しかしまぁ、カーネルソースにパッチを当てる以上buildは必須なので、armbian-configを通じて使用しているカーネルソースをダウンロードしパッチを当てます。smsusbおよび関連するモジュールのみの問題のはずなので、カーネル自体を入れ替える必要なく、そのため今走っているカーネルと同じバージョン情報でモジュールをbuildする必要があります。.config保存しておいてmake mrproper、.config戻してmake oldconfigするのは今も変わらず。さて、走行しているカーネルのEXTRAVERSIONは、というと…uname -rした結果は4.4.213-rockchip64、と言うことなので、はいはい、じゃEXTRAVERSIONは-rockchip64、それを渡しつつmake modules_prepareしてmake modules。で、できたモジュールをmodprobeしてみると…

smsmdtv: version magic '4.4.213-rockchip64+ SMP mod_unload aarch64' should be '4.4.213-rockchip64 SMP mod_unload aarch64'

え”?俺"+"なんてつけてないんだけど…。

.scmversion

実はこれ、まったく知らなかったんです…なぜ?機構的には古くからあるようなのに。

いつもカーネルイメージ全体作り直すか、基本debian使いなので、debianのソースを使用し更新するモジュールだけdebianの仕組みの中で作り直していたから、意識する必要なかったんですかね…。


ということで、.scmversionをtouchして、make mrproperからやり直し。
クロス環境ではなくローカルbuild、かつ、後で気づいたんですがw、シングルプロセスでbuildしてたので、moduleだけとはいえ数時間かかるプロセス。
最終的に、同じversion magicのモジュールを手に入れることができました。これでチャンネルスキャンを行わせてみると、今度は正常にスキャンできました。

これで、ラズパイ3Bコケても、比較的容易に中継ぎ登板できるかなと思います。
さて、この次は、Pi Zeroではprime video再生できなかったkodiか。それもまたrock64かな…。
 

2021/5/25追記

 諸般の事情でこの記事の後、PX-S1UDを使用した録画機は、PineA64に移っていました。それはもうすんなり動いたんで書くこともなかったんです。しかし、そいつに使っていたHDDが寿命を向かえていることが判ったため、急遽新たなレコーダーを起こす必要にかられ、rock64を再登板させて引き継ぐことを考えました。
当然、当時のセットアップ状況が残っているわけもなく、新たなインストールです。

・USB3の問題 

今から調達するとなるとUSB3を前提にしたくなるわけで当然そういう選択になります。rock64自体、USB3.0対応しているから大丈夫だよね…。…。…。…。ところが、動作が怪しい。ちゃんとUSB3で認識するんだけどformatかけると停止、というか、エラーを発しだす。
これがまたx64なPCでは確実に動くんで、HDD自体の不良ではありません(ORICOの2.5"のケースに6G SATAのHDD)。
(時系列が実際に起こったこととは入れ替わって書いてるんですが、順序としてはPineA64にこのHDDをつないだとき、動作しなかったんですよ。そのあとx86に持っていってみて問題ない、ということは、USB3 HDDのサポートに問題あるかも?ということで、rock64が再浮上したのでした。)
 
となると…また電源問題かよ。
 
残念ながら手元にはセルフパワーなUSB3 hubはなく、USB2しかない。しかし、PineA64ではUSB2で性能的な問題はなかったので、USB3 hubを調達するまでのつなぎでUSB2で行くことにする。

・OS的問題

Rock64の場合、ちょっとケチった環境でモニタにHDMIがないからと、HDMI - VGAあるいはHDMI - DVIアダプタを使おうとすると、ayufan氏のインストールイメージ以外ではHDMIがそれらアダプタに適した出力をしてくれない。そのため、armbianなどの場合ヘッドレスで使うしか今のところない。
この問題を知る以前から、microSDブートではなくHDDブートのためにayufan氏のイメージを使用してきたけど、安定版としては4.4.190と、だいぶ古いカーネルを使うことになり、かつ、一部のUSB機器を接続するとクラッシュを起こす。そのため、ちょっと冒険して5.12.0のイメージを使うことに。
ただ、xubuntuのイメージを使ったはずなのに、32GのmicroSDはフルフルに。仕方ないので、minimalにxubuntu-desktopを追加インストールする形でセットアップを行う。これなら32GのmicroSDはスカスカです。

・EPGStation v2

もう数回セットアップしたことになるmirakurun+EPGStation、手順だけ、当時から参照させてもらっているサイトのお世話になれば大丈夫かな…と思いきや、EPGStationがv2と新しくなっている。
セットアップマニュアルにあるとおりにやっているはずなのに、vue-cli-service not foundでbuildが完了しない。node_modules消して〜とか試してみるがダメ。どうも"Javascript heap out of memory"で落ちている、ということで、最終的に、
export NODE_OPTIONS="--max-old-space-size=1024"
が必要、と知るまで、一日掛かってしまいました。これでなんとか動きだしました。 rock64に都合3G swap割り当ててもダメだったので、オンメモリで1G以上必要だったのでしょう。

・USBの性能的問題

ところがお試し録画してみると、録画したものは全然ダメダメ、画面の真ん中くらいしかちゃんと動画再生できてない(後はブロックノイズ)。USB2って一応480Mbpsあるんで、HDDとチューナー同じhubにぶら下げても大丈夫でしょってやってたんですが、それって実はPineA64時に踏んだ轍で、パフォーマンス的にダメなんです。なので、結局USB3ポートにセルフパワーhubをつけてHDD、USB2ポートの一つにPX-S1UD、もうひとつのUSBポートにHID系のものをつなぐ、という構成で、ようやく運用できるようになりました。
最終的には、セルフパワーのUSB3 hubを持ってきてUSB3につながないと、HDD性能が生きないので、近いうちに調達する事にします。さすがに桁が違うのでね…。

・余談

セットアップ時にあんまり考えず、mirakurun+EPGStationをセットアップして最初立ち上げ番組表みたとき、時間が「?、UTCになってる…」ということでtimezoneを直したところ、すでにEPGを取得済みの部分は16時間ずれて解釈されたまま残ってしまうことが判りました。当然、録画失敗します。
EPGをフラッシュする方法が判らず、しかしまぁそのうちちゃんと同期するでしょ、と放っておいたら、翌朝まで16時間ずれ番組表が残ることになってしまいました…気をつけましょう。
 

 

2020年10月10日土曜日

NanoPi NEOでサーバー、再び

 以前、NanoPi NEOでNFSサーバーをやらせようとした顛末を書いたことがありますが、その時、「約一日稼働すると、どうもhddが止って、再度スピンアップできない模様で止ってしまう。しかしこれ、hdd側の自動停止なのか、Linux側によるUSBの自動停止なのか釈然としない。」ということで諦めた経緯がありました。


BDレコーダーが壊れた時、TS抜きのプラットホームとして、無論NanoPi NEOも検討してみていました。その時の事。

インストールもできたし、ではパフォーマンスの問題を見よう、と思い走行させておくと、早くて数時間、長くても一日程度で止まってしまいます。ログ見ても原因究明につながりそうなエラーはなし。うーん、困った、とは思いつつ、試験的に録画実施してみて、h.264エンコードさせてみると「おそっ」。デフォルトのrate = 4.0では到底終わらずその倍必要(おそらくffmpegで、H3ではアクセラレータがサポートされてない)。まぁそれも仕方ないかとは思いつつ、それでも少しは時間改善図れるか?と思い、クロック速度を調整してみたりしていたところで、システム停止する直前にあったと思われるログのタイムスタンプが異常であることに気づきました。Syslogを前回起動以後今回の起動まで通しで見ると、ある一定のところまでは、概ね正しいと推定される時間つまり起動した時間より後なのですが、停止してしまう際には、かなり過去の時間が記録されています。はてこれは…。

ntpの関係かも?などと確認してみるもちゃんとupdateの記録はあるのですが、その後狂うことが確認できました。

armbianmonitorでCPUクロックを継続的にモニタしてみると、暇な時にはクロックを落とし、録画始まったりすると、ちゃんとフルパワーになります。しかし、クロックを落としたあとで、時間もおかしくなるケースがあるようです。なんともはや。

ということで、クロック制御を止めて固定で走らせると、一週間でも問題なく走ります。

これは、ハードウエアとしてのNanoPi NEOの問題なのか、そのサポートにおけるLinux上の問題なのか、追求はしてはおりませんが、おそらく、NFSサーバーをやらせたときに停止する問題も、これなんじゃないかな…。


2020年8月27日木曜日

auひかり テレビサービス顛末

 前回の、BDレコーダ壊れるでちょっと触れた、不具合の雰囲気があるauひかり テレビサービスのSTB、何が起こっていたかというと、数分程度で受信できなくなる、ほぼ自動復帰しない、というものでした。最近あんまり視聴・録画してなかったので、具体的にいつからか?については明示難しいんですが、今年の正月頃までは問題なく一時間ドラマを録画できていたので、その頃までは問題がなかったものと思います。

最近になって録画済みの整理の上で新たな録画予約をしたらこの調子。

宅内ネットワークの不備であれば、他にも影響出ておかしくないのですが何も無く、ビットレートは異なるとは言え長尺のyoutubeなりAmazon Primeなり見ても切れることは無く、こりゃau内(というかテレビサービスのストリーミングサーバー側の)問題でしょ、とは思いつつ、auに問い合わせ。

で、異常対策の通常ルートであろう、STB、ホームゲートウエイ、ONUと、全とっかえして機器が一新されても状況が変わりませんでした。STB交換・ホームゲートウエイ交換の際は、代替機を送ってもらって機器交換ですが、それで状況改善しないのでサービス担当の方がこられて状況確認、そのときONU交換して光信号レベルにも問題ないことは確認されたのですが解決策無く、auネットワーク内の問題を確認してもらうことでその時は引き上げていただきました。

au側確認頂いてそちら問題なく…ということで再度確認に来訪頂いて、ちょうどその際問題発生で現象確認、一通り、宅内ネット、光側レベルなど再度確認頂いてやはり異常はなく、ONU、ゲートウエイ再起動すると… 何と今度は30分ほど確認しても切れないではないか! え〜っ?一体何が起こったの?? サービス担当さんと相談の上、様子をみることで同意し、引き上げていただきました。


そしてその後…

宅内の機器がすべてネットワーク不達となるので確認したところ、なんと、ゲートウエイ内側つまり宅内側のネットワークアドレスが変わっています。ははぁ…、サービス担当さんゲートウエイを初期化したな、と思い、改めて、元々使用していた設定に戻すと、もちろん問題なく宅内機器は復帰します。じゃSTBは?と見ると、改めて、切れるように…。

え”????

ゲートウエイ設定初期状態に戻すと、STB切れなくなります。おぃおぃ、それってやっぱりどこかのau内ゲートウエイなりNATなりがとち狂ってるってことじゃねーの?とは思いつつ、だいぶ面倒でしたが、宅内機器のネットワークアドレスを変更して、元の鞘に収まりました。


さて、どうやってauに報告すっかな…。

2020年7月26日日曜日

BDレコーダ壊れる

以前、BSアンテナ用供給電源が…という話をしたことがあるBDレコーダーですが、とうとうHDDが壊れたようです。まだネット配信が一般化する前の、ethernet端子がない、HDD容量も500Gのもの。HDD交換の手立てをいくつかネット上で見つけることはできるものの、なんにしても録画済み番組は救済することはできません(あぁ…、Casiopea 3rdのライブ、落としておくんだった…)。

仕方ない…ということで、BDレコーダーを物色してたんですが、世間様は4K流行り、でもなぁ〜、ピンとこんのや、高いばっかで… じゃぁメディアサーバー系HDDレコーダーは?と思うと、TV側に機能集約されて外付けHDD対応が進んだためか玉数少なく、BDレコーダーと価格帯イメージもあまり変わらないという状況。

EPGstation

 一通り逡巡したところで思い出したのが、TS抜き。

チューナーは、手元には古いPCI品しかなく、探してみると、地デジオンリーのUSB 1ch.タイプは結構容易に入手できる、ということで、アマゾンからカードリーダーともに調達。お休み中のRaspberry Pi3Bを引っ張り出して、通常のraspbianをmicroSD使ってインストール。録画データ用に、ホームディレクトリサーバー用にプールしていた1T外付けHDDを用意。B-CASは、もうドライバサポートが終了し、ほぼ使い道ないPCIチューナーカードのものを持ってきて、先人の記事を元にEPGstationをセットアップ。この領域は、ほとんど経験がなく、先人の皆様が頼り、ありがとうございますm(_ _)m

…、ということで、稼働させてみると、プラットホームがPi3ということもあるのだろうけど、ライブと、録画データのTS再生には難があるものの、H.264にエンコードしてしまってあれば、問題ありません(当然か)。おぉ、これは使えるよ。

ただ、録画後エンコードのCPU負荷がなかなか高く、その最中に録画が入ると、悲しい事態になるかもしれず… ではあるのですが、BDレコーダーが壊れた状況のままにしておくこともできず、とりあえずこのまま運用についています。

Kodi、まだ、うちでは、おまけ以上にはできておらずですが…

 EPGstationは、ブラウザでアクセスして録画・再生するので、通常のTVを使って操作するには少し工夫が必要、ということで、Pi ZeroWを、LibreElecを使ったkodi機として仕立てました。ラズパイはユーザー層も広いようで、LibreElecコミュニティーでも、先陣を切りサポートされるようです。LibreElecサイトでリリース情報を得られます。後で述べる点と合わせて、今後整備、と言うところです。

本格化するには

 もともと、BDレコーダーはマルチチューナー機ではなかったので、1ch.チューナーで運用する事自体には家族からクレームはないのだけども、試験として調達した、地デジオンリーな状況には不満の声があがってます。ということで、地デジ/BSタイプのチューナーの調達、が一つ。
もう一つはPi3、HDDレコーディングするとは言えUSB2.0、が、録画と再生が重なった時には不安が出てきます。USB3搭載のボード、Pi4とか、うちのサーバーとして動いているrock64などに交換する必要がありそうです。使用メモリ自体は、1ch.録画で運用している分には1Gで余裕があるようです。念のため、swapエリアを1Gに広げてあるのですが、ほぼ使用していません。もし、マルチチューナーにする場合は、応じたメモリ空間が必要になるかも知れません。

※ 8/16追記
 BS/CS録画ニーズが高く、一ヶ月も経たないうちにPX-W3U4も仕入れる羽目に。この本体にはカードリーダーが内蔵されてるんですが、こいつはまだLinuxでは使えない、ということに気づかず、一日(と、都合4時間ほどの録画を)無駄にしました…。

その他の機器

 壊れたBDの代わりについて逡巡していた時、EPGstationによる地デジ対策に加えもう一つ頭に浮かんだのは、auひかりテレビでした。これ、地デジを通してないなど登場当初は使い勝手に難ありではありますが、CS/BSで放送されているチャンネルの多くはカバーされているし、せっかく契約しているのだから(現住居に引っ越してくる前はitscomを使っていたので、auひかり契約時、ひかりテレビチャンネルに、子供向けアニメチャンネルがあることもあり、それほど深くは考えずに契約もした)、使わない手はありません。いつの間にか、TELASAも見れるようになってる!と思ったら、ビデオパスがTELASAに名前変わったんね…。
契約当初はまだ「スマホでストリーミング見る」時代には早く、かつ、DTCP-IP?DLNA?という頃だったこともあり、Dixim BD Burnerを使ってはいたんですが、子供向けチャンネルから卒業していくと、そのサービス切れを機会に、無駄金を貪って(スミマセン…)いる状態でした。つまり、このSTBで録画したものを、メディアに落としたりするためには、DTCP-IP対応のHDD/DVD/BD機器が必要になるため、ぐるぐる逡巡することになるメニューの一つになっていました。BD burnerの終了後、なるべくローコストでそこをクリアするには、SonyのPC TV Plus、それは判っていたんですが、ようやくそれを調達。
残るは、DTCP-IP配信。これ、kodiで対応できるはずなのですが、放送中番組リストの取得、録画済み番組リストの取得はできているものの、再生することができていません。ただ、今現在使っているSTBには不具合の雰囲気あり、交換機材を送ってもらえるので、その後検討、となりそうです。

…、この領域は、今やSTB自体android機だったりしてまさに組み込み機の世界で、むかしチョロッと関わったこと無くはないのだけど、全然遠い世界になってましたね…。だいぶ取り残されている感じです。

追記

 kodiはAmazon Primeも対応してたよね、と思い、プラグインを足してみると、「ARM6はwidevinecdmサポートしとらんけんね、再生できんとよ。」と言われる。kodiのwidevineサポートを調べると、どうやらPi Zero及び初代Pi(つまりARM11機)が該当する模様。あうぅ…EPGstationで録画したものの再生には問題ないのに、どうやらPi3以後か、他にHDMI内蔵されてるボードを探さないとならなそうです(はっ、BBB…???いやいや…)。

2020年6月21日日曜日

NanoPi NEOにMPD

モチベーション/2020年6月21日

 その昔、3.5"サイズのx86ボードにmpd(music player daemon)を載せて音楽サーバーやらせてたんですが、HDDがお亡くなりになって以後、代替を用意することなく、だったのですが、それをNanoPi NEOで再現してみようと思います。

最近のNanoPi NEOには、CVBS(NTSC)出力も追加されているようですが、アナログオーディオインターフェースも、2.0mmピッチのスルーホール5pinで用意されています。
最初、これを使うために、PCで見るようなコネクタを搭載しようと用意したんですが、狭い、UART0とUSBポートの隙間で、干渉してしまうため、直接半田付けしてライン出力を引出しました。元々ランドがあんまり大きくないんですが、加えてGNDポートはサーマルランドになってないのか、なかなかはんだがうまくのってくれなかったんですがそれはさておき。

しかしこのライン出力は、NanoPi NEO回路図を見ると、H3端子が直接ACカップリングされているだけです。これじゃ多分、パワー足んないよね、とはおもいつつ、とにかく、PC用の、アンプ内蔵スピーカーをつないで、音を出してみることにします。

NanoPi NEOのオーディオ

 FriendlyARMのWikiにもかかれていますが、確認するもっとも簡単な方法は、alsa-utilsを使ってaplay -lかと思います。確認してみると:
user@nanopineo:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Codec [H3 Audio Codec], device 0: CDC PCM Codec-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
user@nanopineo:~#
となってます。

MPDと設定

 MPDはごく普通に、aptでインストールしてやります。設定も、あちこちに先人がおられるし、特に難しいことは不要なはずです。ただ、うちでは、ファイルサーバーにまとめて音楽データも置いてあるので、それをautofsを使ってマウントするようにしてやり、それを参照します。
/etc/mpd.confには、aplay -lで確認した結果を反映してやります。

audio_output {
        type            "alsa"
        name            "My ALSA Device"
        device          "hw:Codec,0"
        mixer_type      "software"
}

動作確認

 MPDのクライアントアプリケーションとしてmpcというCUIアプリがありますが、それだけではなくスマホからも接続してみます。
MPDを動かすNanoPi NEO以外の、スマホを含む端末からアクセスしたいので、mpd.confのbind_to_addressは、個別のアドレスが判っていない場合anyとするようです。ネットワークアドレス使えないのか試してみましたが、エラーになってしまいます。何か方法あるんでしょうか…。
で、rock64からアクセスしてやると:
foo@rock64 >> mpc
volume:100%   repeat: off   random: off   single: off   consume: off
foo@rock64 >>
おーOK。なので、updateコマンド入れて、データベース(音楽リスト)を更新してやります。

次、スマホ。Android向けにもiPhone用にもいくつかクライアントがあるようですが、Android向けにMPDroidを試しました。これはAndroid10よりも前のバージョンまでの対応のようですが、動いてくれているので、試験用途としてはOKかと思います。
で、さっきmpc側でupdateしたので、MPDroidでつないでやると(サーバーアドレスを設定してやります)、サーバー上にある音楽データのリストを取れます。MPDroidでもサーバーデータはアップデートできます。
リストから適当に選んで再生してやると、NanoPi NEOにつないだスピーカーから音が出ます…、が…、案の定ゲインが全く足らねー…(泣)。ボリューム最大で、スピーカーに耳近づけてヘッドホンで聞いてるようなレベルです。こりゃちゃんとプリアンプ入れてやんなきゃダメだぁ〜。


がまぁ、なんにせよちゃんと動いてくれてますんで、アンプ用意したら運用に入りたいと思います。
あとは、サーバーに音楽データをアップロードするところを用意して、子供らでも使えるようにすれば完成、ですかね…。

アンプ/2020年8月9日

 8/1に何やらChina Postから配達されてきたものが。はて?まさか、はやりの「種」…?
出てきたのは…、そうそう、こないだAmazonでオーダーしたアンプだ!
案内があったのは月末〜9月頭だったので、ほぼ4週間も早く届いたことになります。サイズイメージのために、となりにCR2032をおいてみました。
アンプをAmazonで探してみると、出力段アンプはいろいろ見つかるんだけど電源が大抵12Vだったりして、あんまり考えずにこういうところで使える、5V以下のものって意外と球数がなく、ヘッドホンアンプから選んでみました。で、こいつをNanoPi NEOのオーディオ出力につないで音を出してみると…

あれ?カラオケ?

つまり、左右どちらかが逆相になっている?いやいや…。んー、それにこのハム音は…

まずハム音。NanoPi NEOコンソールとして使っているUSB-UARTが、どうやら接続先からもらってきているらしいので、それは最終的にはなくなる、と。
PC用のアンプ内蔵スピーカーでテストしていて、こいつがUSB端子から内蔵アンプ用の電源を得るタイプのものでそれもちょっと原因ぽく、NanoPi NEO自身のUSBポートにしてみると、ACアダプタがたまたまあまりノイズを吐かないのか、調子良さげ。
そうなると、USBポートを取られてしまうので、USB Wi-Fiでネットにぶら下げていたものを一旦有線にしないとならず…しかし、まずは…

NanoPi NEOを有線にして、も一度試すと…あら不思議。ちゃんと鳴るじゃん!
USB Wi-Fiに戻すとカラオケに。んー。どうやらUSBの使い方に影響を受けるようです。
多分、チップレベルでの設定に関係してるんだろな。

となると、最終型は、有線LANで使うか、あるいは、I2SにDAC持ってくる形にしないとならんのかな…。まぁ、とりあえずは有線でちゃんと動くようだし、箱を何とかしましょうかね!

2019年8月10日土曜日

カメラをいじる・下準備編

その昔手に入れて放置されてるMTV-54K0DN、これ、NTSC出力に加えてBT.656出せます。
最近、ビデオカメラ関連のお仕事が中心になってることもあり、その中でこれやっとかないとダメだよね、という技術があるんです。そこに手をかけておきたいんです。
まずはこのカメラ、とりあえずアナログビデオ系につなげば何か出る、ということで…

JP1に、モニタと電源、付属のケーブルでつなげてやります。ケーブルは切りっぱなしになってるんで、RCAとACアダプタ用のコネクタ付けてやります(右写真)。
ビデオ用の小型のLCDも、このカメラと同じくDC12Vで動いてくれるので、同時に供給してやります。

で、電源入れてやると、あっさり写ります。

右下にチョロッとカメラモジュール自体写ってます。別項NanoPIにHDDつないで試験中を写してみたものですが、ご覧のとおりでだいぶ白いので、AWBくらいは効かせてやる必要がありそうで、arduino使ってやれば、USBアナログビデオキャプチャと組み合わせるとか、色々それはそれで楽しめそうです。が、ここではもう少し先に取り組む必要があります。そうです、直接デジタルで取りこみしてその先XXX。

さて、そこに進むために、BT.656をどうキャプチャするかがなかなか悩みどころ。FPGA使えば取り込みはできそうですが、SoC内蔵品じゃないと、その後の処理系にどうやって取り込んだ絵を渡すのかで悩みます。つまり、USBで接続する事が簡単には行きません。
具合が良い?事に、STのSTM32F4xx、これ、評価用としてボードが多数出回っていて、arduino uno用のシールドを共有することもできたりするし、しかも、書き込みするためのマイコンも、のちに分割可能な形でワンボード化されていてかつ安価。ということで、F4xxで、カメラI/Fが搭載されているF446 nucleoを使ってみようと思います。

MTV-54K0DNは、BT.656は10ピンフレキで出力されているため、それをどうnucleoにつなぐかというポイントがありますが、それ用?と思うくらいちょうど良い変換基板がありますんで、それで解決。

ということで、ハードウエア的な準備は万端。

マイコンIDEですが、x86な環境は死滅状態と言っても良いくらいなので、mbedかな…。再び死蔵することになるかもしれませんが、ここから先はまたの機会に。



2019年7月6日土曜日

NanoPiでサーバー…

モチベーション / 2019年7月6日

結構お仕事がbusy状況になっててうちの方は放置プレイ状況が続いてますが、二ヶ月(!?)ほど前の、P4なサーバーの寿命が気になり…を放置もできず試行錯誤中です。つまり、何もしてないかというとそうでもなく、ぼちぼちやってる、というところ。

サーバーに使うにはどのボードが良さげ?

NanoPi NEO、Raspi3、rock64と転がってるったって単に転がってるわけではないんですが、この中でNanoPi NEOだけがヘッドレスでかつ複数台あるので、ファーストターゲットです。今ではラインアップからはなくなってそうですが、NanoPi NEOにはNASとして使えるタイプのボードがあったこともあり。
HDDのっける点では、rock64がUSB3対応してるんでその方が良いかもと逡巡しつつな状態ではあります。

まぁとにかく、NanoPi NEOにUSBなHDDをつなげて、モノは試し。
HDDは、使い古しですが1TなSATAがあるので、それを、外付けUSB3ケースに放り込んで使います。
NanoPiでは、直接USBからブート可能なストーリーが提供されていないようですので、microSDをすっぱり捨てることはできず、u-bootと/bootのために使うことにして、それ以外をHDDに移せれば良い、と言うことになります。

ツール

シナリオは、いっぱいになってしまったHDDのパーティション引越しするような感じではありますが、armbianを使っている場合は、armbian-configのINSTALLセクションで悩むことなく実行することができます。ただ、あらかじめパーティショニングされているHDDを流用したせいなのか、パーティショナーは起動せず、rootfs移動先のパーティションの指定→そのフォーマット→移動実施と言う具合に進みました。コピーが終わるとrebootするかと聞かれますんで、再起動してやります。


終わり…?

もうちっと何かあるかなと思ってたんですが、なにもなくこれですんなりできてしまいます。後はrsync…。
NanoPIは、3種の手持ちボードの中ではもっともメモリ容量が小さく、対ディスクのトラフィックが多いと「おっとっと」な応答になってしまいます。しかしまぁ、microSDにswapがあるのよりは良いような気はするんですが、どんなですかね…。しばらく仮運用してみたいと思います。

止るのはなぜ… / 2019年7月28日

約一日稼働すると、どうもhddが止って、再度スピンアップできない模様で止ってしまう。しかしこれ、hdd側の自動停止なのか、Linux側によるUSBの自動停止なのか釈然としない。
とにかく、hdparmを確認してみると、APM levelは254が設定されているようで、offに設定を変更。
もう一つ、USB device側のautosuspendを止めておく。/sys/bus/usb見て、ドライブを探す。これ、デバイスのバスが変わるとそれに合わせて変更する必要があるので、udevで書きたいところですがとりあえず。
hdparm -B 255 /dev/sda1
cat -1 > /sys/bus/usb/drivers/usb/5-1/power/autosuspend
参照:"Power Management for USB"

で、再び様子見。夏休みに入る前には終わらせたい…。けど、それ以前に、Nano Pi NEOのUSBは2.0までなので、これ以上パワー注ぐなら、はなから3.0対応してるrock64でやるべきかもしれない。

それだけではない何か / 2019年8月10日

ほらやっぱり夏休み… 激暑で冷房なしにはやってられないステータスですが、解決に至らずstrugglingな状態。関係ないけど、一昨日は使えたエアコンのリモコン、操作に突如エアコンが反応しなくなり…。応急運転でエアコン自体動くことは確認できたので、どうもリモコンがダメになった?とおもい、スマホカメラでIR発光するか見てみると、案の定ダメ(リモコンは大抵NIR - 可視光に近い近赤外を使っており、スマホのカメラでもその発光状態を確認できる。最近ではよく知られてると思いますが)。ということでamazonに駆け込んで調達しました。エアコンない部屋でこんな作業、到底やってられないです…。

肝心のHDD。
一度rock64がよぎった以上は確認、と言うことで、rootfsだけを、USB3に接続したHDDに移動して動かしてみると、どうもディスクアクセス途上でスタックを起こします。rootfsディスクアクセスに絡む様々なエラーメッセージを発して、最終的にはrebootに至ってしまいます。
この原因が判らず、webさまよっていると、いくつか原因候補がある中で、どうやらUASに起因する、ドライバレベルの問題があるケースに該当、するような動きです。UASを使わずusb storageで運用すれば、この様な問題には至らないようです、若干、hdd側の動き方には怪しい面もありますが…。armbianではusb-storageはカーネル組み込みになっている関係で、bootloaderレベルで、該当のUSB HDDコントローラのdevice ID、product IDをusbstoragequirksに付け加えてやります。

さて、NanoPIですが、linux-sunxi.orgのUSB/UASによると、今使っているUSB3-SATAケースUNI-HAL35で使われている、JMicron  TechnologyのJMS539/567は、オレパイでとはいえベンチマークに使われており、quirksには該当しないようにも思います(故のquirks?)。再起動時など勝手に電源切れてくれちゃうのがいまいち気に入らないんですがそれはさておき、むしろ使っているドライブに問題があるのかもしれません。引き続き一日で止ってしまうようであれば、やっぱりrock64で、かな~。

この暑い時期、P4ホストは室内にあるとはいえエアコンがあるところにあるわけでもなく、ファンの唸りが増してますんで、早めに切り替えたい今日この頃、です。

バトルは続くよどこまでも… / 2019年9月15日

色々試し始めてからはや2ヶ月すぎ、なところですが、安定した結果を得られないままです。この間に、本家Debianがstretchからbusterへとバージョンアップし、armbianもraspbianも同じく更新されました。現行サーバー自身はまだjessieです。それで状況が解決に向かうなら良いんですが、特に変化なし。Nanopi→rock64でUSB3を使ってもUSB2を使っても、UASを使おうがusb_storageを使おうが、スタックしてリブートかかるときもあれば単にプロセスが死ぬ、ロックするときもあれば、という状態で、一歩も進みません。
HDD相性問題だとしても、商売でやってるのではないのでHDDあるいはUSB-SATAブリッジしかもケース付きを湯水のごとく買うわけにも行かず。

このエリア、ゲームでもしない限り、パフォーマンスにそれほど難点はなくなったとはいえ、armプラットではまだ無理で、x86いやx64に戻ってくるしかないのか… あるいは、その中でも安定度が比較的高いraspi3Bで妥協するか、と言うのが今日までのところです。

そしてどうなった… / 2019年11月9日

あれこれ試行錯誤をしている内に、本当にHDDの方が寿命となってしまいました(つまりエラー多発してろくに動作確認もできない)。
昔のHDDてば、最後にスピンドル方面が「ぎゃっ…」と悲鳴をあげて(いや本当に音がするんです。多分ベアリングが逝っちゃうんだよね、あれ)うんともすんとも動かなくなることがよくあったんです。最近のHDDはこそこそっとエラーを発しては、どっちかというと、「仕事するの疲れたからもう寝る…起こさないでZzzz」みたいな動かなくなり方をしてくれます。結果、本当に使えないのかまだ試験用程度なら使えるのか、判らないまま深くハマっていってしまう、その泥沼の中にいた、という感じですね。

で、新に1TのHDDを調達しまして、また頭からやってる、と、そんなところです。
一時期uasに不信感があったんですが、HDD新調してからはUSB3でもUSB2でも問題なく動いてくれます。
当初rock64で動かしていたのですが、どうもzram絡みでエラーログが残るしカーネルレベルの問題の様子(本家Debianカーネルではなくubuntuカーネルでは対応がされているようないないような記述があるんですが…)であるため、インターフェースはUSB3 -> USB2ではあるもののNanoPiで現在作業中です。
時々クラッシュする(黙ってリブートする)ため、熱対策か電源対策か、その辺で何か問題があるのは間違いないのですが、32bit core processorが終息していく中、H3なNanoPiにはもうしばらく頑張っていただければと思う次第です。


LDAPサーバーの引越し準備/ 2019年12月1日


早いものでもう12月。悩み始めてもう5ヶ月も経ってしまいました。
紆余曲折のあったファイルサーバーですが、概ね一週間単位では止らず動いており、懸念があったClamAVも512Mbytesでやりくりできているようでクラッシュしないようなので、いよいよ本格的に長期間…と言う前に、もう一つ、日頃そんなに触ってないが故に問題になるところをやっておく必要がありました。
うちでは複数のLinux端末やら何やらが動いている関係で、誰がどの端末にでもログインできて使えるようにしています、当人達がそうしたいかどうかはさておき。
一時NISでやってたんですが、数年前に、何かが原因(もう忘れた…)でLDAPに移行している関係で、そいつも引っ越さないとなりません。
ということで、NaniPi NEOにopenldapをパッケージインストールして設定して…さて、引越しってどうやったら良いの?と、ググらせていただいた結果としては、単に旧サーバーでslapcatしてそいつを新しいサーバーでslapaddせい、という簡単な解。大体、そんなに日頃っからそんなところ大していじらないわけで、覚えらんねっす、というのが本音です。

というわけで、忘れていた初期設定値など現在のサーバーでslapcatした内容で確認しつつですが、大きな問題がひとつ。

LDAPはでぇたべぇすなわけで、最初に設定したjessieの時には、Berkeley DBがバックエンドのHDBで設定してました。それが最近はMDB推奨ということで、何か変更しないとならなそうです。
slapcatしたもの見ると、所々HDBというキーワードが出てきますが、そいつはMDBと書きなおしてやるだけで良いようで、かつ、MDBでサポートしないキーワードがあるがそれは削除して大丈夫、しかしslapaddしてやると何か文句言ってる。そうかそうか、初期設定した段階でslapd動いてるしデータ握られてんだからいろいろ不都合だよね、ということで、slapdを止めて、管理されてた初期設定データを削除してやります(/etc/ldap/slapd.d以下は削除してしまう)。
改めてslapaddしてやると、configデータはOKですが、ホスト、アカウントなどのデータはまだ文句言われます。いろいろググった結果としては、「重複している設定がある、と言う文句なら"-c"使え、それで大丈夫」、とのこと。
slapdを改めて動かして、slapcatしてみると、ちゃんと引越しできました!

ということで、着々と引越し準備は進んでます。 どうやら最後に残る問題は、NanoPi NEOにはアクリル板でできてるケース未満の上下ガードを付けてあるんですが、ほぼむき出しなわけです。HDDは外付けケースに入ってるとはいえそのまんま置いとくの??ということになりそうな状況です…。

最後に(?) / 2019年12月31日

のんびり?やってきたこの整備、概ね落ち着いたので最後、メイル関連の設定をして完了です。メイルったって、以前はちゃんとISPのMTAとコミュニケーションできるようにしなきゃってやってましたが、今やweb基盤のツールがほとんどなので、セットアップしなくても済んでしまう状況でもあるわけで、昔の名残り、ですね。
今まではDebian defaultなexim4を使ってきてたんですが、そもそもjessieのままで長らく運用してしまった関係で、今のパッケージについていけない状況(笑)で、SMTP AUTHでひとしきり悩むことに。思い切ってpostfixに入れ替えてしまいました。もうほぼいじらない領域の事なので、先人の知恵をそのまま使わせていただくことにして、スマートホストを使用するよう初期設定しSMTP AUTHを追加することで、すんなりセットアップは終了と相成りました。ISPからの取り出しは、fetchmailしてきます。

さぁ、以上でセットアップ関係は終了です。年内に終わらせたかったんですがとうとう間に合わず、年明けにホームディレクトリの引越しをして、サービスインです!

後日譚 / 2020年1月26日

このNanoPiサーバーですが、年明けに実運用始めて見たところ、やはりClamAVが実メモリ不足で、頻繁にクラッシュしていることが観測されてしまいました(再起動するわけではない)。試験時点では間に合ってたようなんですがね…。
それ以外は順調に動いていると思うのですが、しかたがないのでClamAVは停止させました。

ということで、今現在rock64へ再度移動の準備中です。

後日譚その2 / 2020年3月31日

rock64化したサーバーは順調に稼働しています。
ひょんなことからRaspi3Bでubuntu bionic 64bitを試してみておりますが、その際にHDD起動にしてみました。全体に重いことは重いんですが、加えて悪いことにはUSBが飽和してしまうのか、USB audioから流れる音はブツブツ切れてしまいます。

ん〜、これでは…。こいつをサーバーにしなくてよかった…。