2021年1月30日土曜日

NanoPi NEOにSPI LCD - OpenCVにpythonのthread

 あるカメラ(モジュール)の動作確認・設定を行うための専用の端末が必要になりました。もちろん、そんなものはWindowsなりLinuxなりのPCでやるよう構築できるものと思いますが、現場作業ものだし、『専用』なので、それだけの投資(あるいは維持)をしないとならなくなってしまいます。
そういうこと?で、なるべくお手軽にしておきたいわけで、先日せっかくTinyDRM使って『小型端末化』できるようになったNanoPi NEOにご登場いただこうか、というところです。

OS

いつものごとくarmbian使うんですが、armbianサイトに置かれているbusterイメージ、ぶっ壊れているみたいで、torrentしても、その時はunxzすることできず。手っ取り早くbionicで進めることにしました。
一時は本家Debianばっかり使ってたんですが、rock64でayufanを使う必要があったところから、だんだんubuntuが増えてきてます。(ちなみに、インストール後数日経過してるところで書いてるんですが、今現在focalにupgrade中です…)

まずはシリアルコンソールで立ち上げ、先日のdtsを持ってきてoverlayを追加し、キーボードとマウス、それにUSBドングルタイプのWiFiを用意してセットアップ開始。何分、NEO2ではなくNEOなので、軽くしておきたくGUIとしてxubuntuを選択。

OpenCV

C++から使う能力は私にはないので、python3で使うべくopencv-pythonをpipでインストール。想定どおり、build過程でout of memoryしてこけるので、1Gのfilesystem swapを追加してしまいます。これ、安定して稼働してくれれば無くしても大丈夫なはず。
しかしout of spaceで再度build中断。おや?filesystem full?そんなはずは…と思ったら、どうも、opencv-pythonをソースからbuildさせるとダウンロードしてくるため、/tmpを食いつぶしてしまいそれで起こっているようです。
このため、TMPDIRを設定してやって仕切り直し。
これで問題ないかなーと言うとさにあらず。 No module named 'skbuild' ?なんじゃこりゃ、と、お助けを乞うたところ、pipが古いのだそうな。セットアップしたばっかりなのに…(ったって、そのインストールイメージ作られたのがいつなのか、と言う問題なんだから…)。その他に、setuptoolsもupgradeしておく必要があるようです。

さすがにopencv-pythonのbuildには数時間必要。計ってはないんですが、12時間くらいかかってますかね…。

動作確認。pythonでopencv使ってjpeg読んで、LCDサイズに合わせて表示させました。


 

『箱』

NanoPi NEOには、上の写真に見て取れる、アクリル板を使ったケースというかガードというかなんというかがオプション品にあるんですが、さすがに、用途的に、LCDと、それをつなぐケーブルをぷらぷらさせておくわけにはいきません。そのため、何らか箱に収めたいんですが、NanoPi NEOは高さが結構ある関係で、LCDの配置次第で、大体40mm以上高さがあるケースが必要になります。これって結構な制約条件で、高さ方向として約40mmとろうとすると、結構大きなケースになってしまいます。NanoPiとLCDを横に並べた場合でも、高さは概ね25mm必要です。

その昔、円筒形のガムの空きボトルを使ったことがあります。あれ、ポリエチレンで、カッターで切れるし、直径が70mm近くあるんですが、コネクタ類(USB、Ether)をちゃんと出したいしLCDが2.8"だと2:1くらいに縦割りし、横倒しして使うイメージになるため、転がらないような対策も必要だし、あまりよろしい結果になりそうにありません。アクリルケースは意外と希望サイズに近いものがなく、かつ加工の際に割れるとな〜、放熱もちょっとな〜と思うと、選定しづらい感じ。アクリルのパネルから6枚切り出して…と言うのも考えましたが、コーナーに角材を入れないと接着強度が気になる。

結局アルミケースか、と探してみると、やはり高さネックでなかなかちょうど良いのがなく…と、これだけで結構な時間悩んで、最終的にたどり着いたのがタカチのTS-1S。傾斜ケースで、上面にLCD用の開口とLCD取り付け用の穴を開けないとならないので、結構な作業です。で、側面にUSBとEthernet、USBは拡張コネクタからも引っ張り出しておくので、上面に5つ、側面に3つの都合8個穴を開けることになります。上面はLCDパネルとキャリアボードのサイズの関係で左右が均等にならないし、NEOのRJ-45とUSBはあんまり間隔が開いてないので、そもそもそんな穴あけあんまり精度良くやる自信ないわぁ、と思いつつ、電ドリとハンドニブラー、ヤスリで何とか開けました。案の定若干ずれてますが…。ケースの保護フィルムは張ったままです、多分永遠に(笑)。


これはほぼ最終状態のスナップショットなので、アプリショートカットやら何やら設定した後になります。

 

おまけ -- focalへのupgrade

 これを書いている間に、focalがリリースされたけどインストールする?と、ダイアログがでました。もちろん進めるんですが、do-release-upgradeで何かエラーが起こってる。なになに?KeyError: 'suite'?
これは(も?)初体験に付き調べ回っていると、事象はこちらのサイトで話されていることと同じようです。GzipIndexが使われているのは02-armbian-compress-indexesだけなので、こいつを変更してやると、あとはupgradeが進みました。


2021年1月8日金曜日

NanoPi NEOにSPI LCD - TinyDRM

  ここのところ、GPSや多軸加速度センサを使った工作をarduinoでやったりしていたのですが、あるデバイスをコントロールするための、CUIあるいはGUI付きの箱を一つ作る必要がありそうで、以前このblogにも書いた、NanoPi NEO + LCDで構成することを考えました。

以前の記事、もう2年以上前になっているわけですが、当時はLinux4系列で、fbtftを使っていました。その時でもfbtftはstagingで、すでにtinydrmの紹介はされていましたが、多くの情報があるfbtftをそのまま使い、そのメモ書きを残していたわけです。

いま、armbianはLinux5.9、TinyDRMを使わなければなりません。

fbtftでは、fbtft_deviceを呼ぶ際に、使用するgpio端子を記述でき、initコードもquick hack的に試すことができました。TinyDRMではdevice treeを作成する必要がありますし、使用できるコントローラも限られそうです。initコードを変更する必要があった場合には、ドライバを変更しないとならないようです。手元には、いずれもaitendoで入手したものですが、SPIを使用するQVGA LCD、コントローラがili9328のもの、ili9341のものがあり、ドライバの観点では、ili9341なら容易に動かせるかもしれません。(スタンドアロンでili9328を動かすコードを公開されているかたが居られるので、それを参考に、notroさんが公開しているili9325用のドライバを修正できるかもしれませんが、将来…。)

 ということで始めてはみたものの。

Device treeのドキュメントは存在してはいるようですが、汎用的なため、体系的理解が進めば良いのかもしれませんが、LCDを動かすためにはちょっとだいぶ重荷だったので、世間の皆様に頼ることにしました。

試行錯誤の結果、次のようなdevice treeを作成: 

/dts-v1/;
/plugin/;

/ {
        compatible = "allwinner,sun8i-h3";

        fragment@0 {
                target = <&spi0>;
                __overlay__ {
                        status = "okay";
                        spidev@0{
                                status = "disabled";
                        };
                };
        };

        fragment@1 {
                target = <&pio>;
                __overlay__ {
                        M028C9341SD_pins: M028C9341SD_pins {
                                pins = "PG9", "PA1";
                                function = "gpio_out";
                        };
                };
        };

        fragment@2 {
                target = <&spi0>;
                __overlay__ {
                        /* needed to avoid dtc warning */
                        #address-cells = <1>;
                        #size-cells = <0>;

                        M028C9341SD: M028C9341@0{
                                compatible = "mi,mi0283qt";
                                /* compatible = "ilitek,ili9341"; */
                                reg = <0>;

                                spi-max-frequency = <32000000>;
                                spi-cpol;
                                spi-cpha;
                                buswidth = <8>;
                                rotation = <0>;
                                reset-gpios = <&pio 0 201 0>; /* PG9 */
                                dc-gpios = <&pio 0 1 0>;    /* PA1 */
                        };
                };
        };
};

相手はNanoPi NEOなのでSPI0、それにD/C(RS)と、resetで使用するピン、それぞれPA1とPG9を使っていますが、それを宣言してやります。

これを適当な名前でsaveして、armbian-add-overlayし、rebootすると、TinyDRM関連ドライバおよびmi0283qtがロードされ、コンソールとしてブートメッセージが流れてくれるのを見たときには、ちょっと感動しました(笑)。

SPIを使用するLCDなら、それに合ったドライバを指定し直すことで、上記の構造はそのまま使えるはずです。このLCDモジュールにはSDカードコネクタもあるので、SPIモードであれば動かすことができると思いますし、もし、タッチパネル付きのものの場合は、それに応じた追加指定が必要です。NanoPiNEOの場合SPIは1ポートしかなく、armbian-configを使ってSPI1用のCSを追加してやれば、SPIの仕様的にはそれら更なるデバイスの追加は可能なように思えますが、LCDのパフォーマンス的にどうなのかな?とは思うところです。

 

さて、これを元に、 「箱」に仕立てる算段をすることにしましょう。キー入力とかどうしようかな…。

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持ってくる形にしないとならんのかな…。まぁ、とりあえずは有線でちゃんと動くようだし、箱を何とかしましょうかね!