NASと録画鯖の一元化 -> CentOS7にNextCloudを立てたお話
近頃SynologyのNASを譲ってもらったので使っていました。
ソフトウェア面が最高で、一般の方にも優しい設計。
ファイルのバックアップも同期も簡単で、
VPNやらドメイン設定まで簡単に出来てしまった。
素晴らしいと思います。
ただ、やはり別途鯖を立てることになる関係上、否応なく消費電力が増えてしまう。
あと、やはりCPUが貧弱なので大量のメディアを扱うとなると力不足。
というか、我が家にはRyzen 7な録画鯖があるのにこれを使わないでどうする？！
ということでNextCloudを立ててNASの機能をある程度録画機に移した。
参考:
Synology DS216j NAS HDDx2 消費電力 18~22W
Ryzen7 1800X 低消費電力化Tune (PT3+SSDx3) 消費電力 34~37W
ERATO Apollo7 の電波事情 についての追記
以前の記事でApollo7の電波がシビアということを書きましたが、
その一部はスマホ依存の問題だったようです。
s-sef.hateblo.jp
当初はiPhone6にて使用していましたが、
先日iPhoneXに機種変更してから格段に調子が良くなりました。
まずズボンのポケット等に入れても切断しなくなりました。
駅のホームや信号機の多い交差点など、 iPhone6の時に切断が発生しやすかったスポットでも切断しなくなったのは驚きです。
以前は『見えないケーブルに繋がれている』というようなことを書きましたが、全く気にならなくなりました。
これがイヤホンジャックを廃したiPhoneXだからなのか、
それとも最近のBluetoothレシーバーの性能が上がったからなのかは分かりませんが、
最新の環境でのApollo7のワイヤレス体験はとても素晴らしいものだと思います。
左右分離型のワイヤレスイヤホンの安定性に不満がある方は、折を見てスマホの機種変更に踏み切るのもひとつの手かもしれません。
2017年最後の録画やらかし案件
node.jsのPathを消してしまっていた
おそらく2017年最後のやらかし案件
録画されていないと思ったらMirakurunが起動していなかった。
慌ててサービスから起動するも失敗
ログを読むもエラーが記録されていない
ふとPowerShellからnpmをタイプするとnpmが見つからないと出てきた。
調べてみると、なんとnode.jsにPathが通っていなかった。
VisualStudio2017を導入した時にnode.jsのPathを誤って弄ってしまったらしい。
無事起動はできたけど3日分の録画予約が吹き飛んだ。
忙しい時ほどしょうもないミスをする。
ERATO Apollo7 の電波事情
遅ればせながら左右完全分離なBluetoothイヤホン買いました。
試聴は何回かしていたんですが音質的に気に入ったApollo7がやたら高くて手が出なかった……
のですが気がついたらポチっていました。
iPhoen6でひと月ほど使っての感想です。
まだまだ完璧には遠く、過度な期待は禁物というのが率直な感想です。
ただ、今後有線のイヤホンを買い足すならワイヤレスを買い換えるんじゃないか、
そんな予感がしました。
https://eratolife.com/products/apollo-7-true-wireless-earphones
続きを読む録画失敗あるあるまとめ。 (突然PT3にアクセスできなくなった Bus::Run() (0x00000401))
朝、録画フォルダを見るとそこにファイルがない or 0kBのtsファイルが…….
そろそろバリエーションが溜まってきたのでチェック項目をまとめてみる。
1. Chinachuのエラーを確認する
まずは録画のタスク実行前後でエラーが出ていないかを確認。
と言ってもChinachuがエラーを出したことはほとんどない。
あったのはディスク書き込み権限関係とMirakurun 応答なしぐらい。
フォルダの再作成や場所移動した後はパーミッションも忘れず設定しよう。
Mirakurun が落ちていた場合は当然Mirakurun 側のログを読むことになる。
2. 視聴アプリケーションで動作を確認する。
TVTestからBon_Mirakurun_Driver -> Bon_Proxy -> Bon_PT3で視聴ができるか試す。
視聴できない場合はその箇所に問題があることになる。
Bon_PT3で視聴できない時はケーブル抜けとBCASカード抜けをチェック。
ちなみにBCASカードが読み込めなくなった場合Mirakurunにエラーが出ているはず。
稀だがBCASが別のソフトにロックされてアクセスできなくなっている場合がある。
TVTest等BCASカードにアクセスするソフトがクラッシュした後は念のため確認しておく。
3. PT3にアクセスできるか確認する
PT3 ソフトウェアのダウンロード (最新版／SHA-2) からPT3-Example-xxx.exeをダウンロード。
起動してPT3が検出されるかをチェック。
検出されたPT3のバス番号を入力しメニューが表示されれば問題なし。
Device::Open() (0x0000040a) -> デバイスが使用中。
他のアプリケーションに使用されている可能性あり、再起動で改善。
Bus::Run() (0x00000401) -> ドライバのエラーでアクセス出来ない。
ドライバの再インストールで改善できる。
これはWindows update後に一度起きたことがあった。
はじめはPT3が故障したかと焦ったがソフトウェア的なトラブルだった。
4. 録画ルール作成ミス
最近一番多いのがこれ。
正直なところChinachuの録画ルールの管理はイマイチ。
というのも、そのルールでどの番組が録画予約されているかがわからない。
1話は録画できても2話で失敗というのがありがち。
バッチファイルからなぜかネットワークドライブにアクセスできない
仮想含め複数のマシンを運用してるとネットワークドライブはとても便利です。
自動マウントで何もしなくともローカルのドライブと同じように扱えるのは素晴らしい。
ただ、ふとした時にアクセスエラーが起こることも。
実はWindowsの場合、管理者権限に昇格したプログラムからはアクセスできないことがあります。
PSexecで管理者として起動したメモ帳からネットワークドライブが見えない。
エクスプローラからは見えているのにコマンドプロンプトからはアクセスできない、という難解な状態になってしまうらしい。
これはUACの関係で管理者権限に昇格したときに別ユーザーとしてプログラムを立ち上げるために起こります。
何気なくbatファイルを書いているとこういうところで躓くので厄介ですね。
batファイル等では次の一行を実行すればドライブに接続できるようになる。
net use V: \\server\folder /Yes
この設定はユーザーのログアウトまで有効なので一連のbatファイルでは気にせず使えるようになります。
ただし、実行中のユーザーに反映される訳ではないので注意が必要。
管理者の方がアクセスできないというのはなんとも新鮮な経験ですね。
