2024年5月アーカイブ

● 概要
「Mirakurun + EPGStationで録画サーバを作ってみた」みたいな記事はもはやそこら中に溢れてるし、手順通りやると構築するだけなら難しくないので、ここではそういうのに書かれてなさそうな点を中心にメモしておく。

● パソコン
TRIGKEY G4 N95にした(Amazonアフィ)
ライセンスの怪しいWindowsは使わない、技適が怪しいBluetooth/WiFiは使わない。
以前にも書いたけど、BIOSで「Advacnced→Power→GT→RC6」を「Enable」にするとGPU消費電力を抑えやすい。あとは、PL1/PL2制限をキツめにし、Ethernetを100Base-TXに制限し、不要なUSBは接続しない(キーボード・マウス)、不必要なHDMIを接続しない、systemctlでbluetoothdを止める、/sys/devices/system/cpu/cpufreq/policy0以下で「energy_performance_preference = balance_power」「scaling_governor = powersave」「scaling_max_freq = 1500000」とかしておけば、idle時で5W前後にはなるはず。WiFiドライバやBluetoothドライバをrmmodしても特に変化は見られなかった。

● チューナ
PLEX PX-W3U4(Amazonアフィ)
px4_drv.git(@nns779)という非公式ドライバがあるが、メンテが止まっちゃっているので、forkしたこっち(@tsukumijima)のほうがいいかもしれない。Ubuntu-24.04LTSで試すと、UBSANのオーバラン誤検出でdmesgが汚れて困ったので、パッチ(0001-change-usage-for-variable-array.txt)作った。が、同じようなパッチを作った人がすでにいた(px4_drv_chrdev20240521.patch)。

● ICカードリーダ
SCR3310/v2.0(Amazonアフィ)
可能なら、ICカードリーダはPX-W3U4に内蔵のを使ってみたかったが、Windowsで実際に動かしてUSBバスのダンプを取って...みたいなリバースエンジニアリングする気力までは出なかった。

● Mirakurun(チューナサーバ)
docker拾い食いに抵抗がないなら、docker-mirakurun-epgstation.gitが楽だと思う。recpt1を自分でコンパイルして準備し、tuners.ymlとchannels.ymlを整える必要はあるが、逆にそれだけ行えばもう動いてしまう。後述するが、私はEPGStationは自前で立てることにしたので、docker-compose.ymlでそのへんをごまかした。

● EPGStation(録画視聴サーバ)
Ubuntu-24.04LTSのaptで取れるffmpegでも、vaapiとIntelプロプラドライバを整えれば、QSVによるハードウェアエンコードができるということがわかったので、Ubuntuホストのffmpegを使うためにも、EPGStationはdocker板ではなくて自分で立てることにした。とはいえ公式のレポジトリから持ってきて手順通り動かすだけだけど。ffmpegをvaapiのh264で動かすために、config.ymlとenc.jsを変更した。QSVを使うとN95の1.5GHzでもh264エンコードは余裕だった。まぁソフトエンコでも-threads対応だから200-300%くらいでリアルタイムでも回るんだけど。改めてN95/N100シリーズってすげぇ。

● サスペンド
いくら省電力とはいえ、何もやっていないときにも動かしっぱなしにするのはなにかもったいない。ということで、スケジュールをチェックしてサスペンドするsuspendd.plのPerlスクリプトを書いた。次の録画予約、3日に1回EPGデータ巡回、重要なプログラム(sshログイン・Sambaアクセス中・recpt1使用中)、をチェックして空いていたらサスペンドする(rtcwake -m mem -s 3600)ようにしてみた。注意点として、EPGStationは公式にはサスペンドをサポートしていないので、起き上がってきたらresettimer(curl -X POST "http://127.0.0.1:8888/api/recording/resettimer")をしてタイマーのイベントドリブンを再スケジュールする必要がある。しなかったらタイマーイベントがずれて録画予約に失敗する。

● その他
マジメに使い倒すならばデータ置き場をHDDにしたりもいいんだけど、まぁ遊びだから、たぶんこのくらいまでにとどめておくことになるんじゃないかなと思う。暇があれば、生のMPEG2-TSからパケットパースしてschedule EITやpf EITをひろってきて番組表を自力で作る、なんてのもいいのかもしれない。

Amazonアフィリンク

鉄道業界が社会や地域へ貢献できなくなっている具体例を示して問題点を指摘する本。地方赤字路線の廃止を主題にしつつも、鉄道存続そのもののみを議論しても意味がなく、交通を介し地域や自治体が自身を今後どのように運営するべきかを考えないといけない、と説いている点が特徴となる。

趣味のジャンルで活動する人が多い鉄道系YouTuberの分野で、社会問題の観点で語るYouTubeチャネルを運営する鐵坊主氏の著作。元旅行代理の経歴から鉄道を切り口に地域や自治体のあり方を考える動画をカナダから投稿する、というなかなか類のない活動を行っている。自治体や会議体の公表する資料を読み解きながらていねいに根拠を積み上げて議論する、という点も著者の強みとなっている。

鉄道事業は固定費が重く、また関東ですら今後人口減を迎えるため、それを踏まえ各社は長期計画を立てて運営していたが、それが新型コロナの登場で短期計画がすべて吹っ飛ぶほどの赤字になり経営が揺れ動いた。このため、各社により温度差はあるものの、どこも人口減を見据えた長期計画を前倒しで始めざるを得なくなった。これが、特にJRで、地方の赤字鉄道路線を維持するのはこれ以上はムリだとして廃線に向けて議論を加速したい動きになっている。方や地元自治体は、従来通りの廃線反対な声を上げるだけの例が未だに多い。議論を単に先延ばしにするだけではダメで、人口減の速度と社会情勢を踏まえた地域交通のあり方を真剣に考えなければいけない、と著者は説いている。

私も素人ながら地域や都市機能と交通とのあり方をおぼろげながら考えることがあったけど、著者のYouTubeチャネルを見始めてから、かなりマジメに考えるようになった。特に、ここ25年ほどは一貫して、(新幹線を除き)鉄道路線の整備よりも高速道路網の整備が優先され続けてきていて、それにより、高速バスがJRの特急に勝つ方面が増えた、という点をきちんと理解できていなかったと反省している。是非はともかく、JR分割民営化により、大都市部と新幹線以外はもう諦めて手を抜くんだという国交省の方針の成れの果てが今なんだと思い知らされた。これでは、未だに「国鉄」の認識と変わらない主張をするような自治体とは議論がかみ合わないわけで。

新聞や銀行と並び、もはや斜陽だと言われることもある鉄道業界の現状を知るうえでの良本。特に、鉄道を主人公に語るのではなくて、自治体や社会のあり方に踏み込んで考えている点がよい。逆に、現在の議論が停滞している状況を一変させるアイディアを語っているわけではない点には、現実的になかなかいい案があるわけではないとはいえ、仕方がないのかもしれない。

● 前置き
画面を動画形式で他の人へ共有するとどうしても遅延に悩まされる。
terminal上での操作を共有したいという場合ならば tty の出力をそのまま共有すればいいのではないか、というアイディアが出てくる。

● 同一ホストで共有する場合
ほぼ下記の記事ですべて語られているけど、
tty script コマンドでLinuxサーバ作業を他者に共有
https://qiita.com/kikudai/items/66ff7155623d635d10c2

- 配信したい人のマシンをA、ターミナルをa、
- 視聴したい人のマシンをB、ターミナルをb、
として、bで閲覧するためのterminalを実行し、ttyコマンドを実行して、その結果「/dev/pts/22」などをメモる。
これを配信者に伝え、aの上で、
- script -fq /dev/pts22
を実行し、aの上でそのまま作業すればよい。終わったら、aでexitする
(bash終了と同時にscriptも終了)
(注意：scriptという名前のコマンドがありそれを使っている)
下記のような記事もあるけど、straceは明らかに過剰で負荷が高いと思われる。
ターミナル画面を勝手に共有して他人の作業を覗いてみる
https://qiita.com/nashiox/items/f9b026b7433fcf984d45

● 同一ホスト別ユーザの場合
難しいことは考えずに、先と同じ方法で同一ユーザでttyをつないだあとに、suなどすればよいと思う。

● 異なるホストの場合
まず、aの別ターミナルとなるa2を開いて下記を実行する。
- mkfifo /tmp/testsharetty
- cat /tmp/testsharetty | nc -l 10333
次に、bで下記を実行する
- nc -N 192.168.123.45 10333
最後に、aで下記を実行する
- script -fq /tmp/testsharetty
mkfifoとnc(netcat)を介することで、TCPごしに相手に見せれる。
serverとclientは入れ替えできると思う。
グローバルに公開していい？認証？それは知らん。。

● 複数人宛に同時に配信したい場合
上の方法で、mkfifoしたunix domain sockerから1回readするごとに、
TCP socket serverにつなぎに来た人全員に1回ずつwriteする、
ということを行うサーバプログラムを作れば良い。
...うん、ちょっとがんばれば作れそうだね(あとは誰か頼む

● あとで再生したい場合
"script"コマンドで取得したログは、in/outのタイミングが記録されておらず、これをterminalに食わせても超高速で流れていくだけとなる。
なので、下記の記事で紹介されている ttyrec ttycast を使うのが素直かと思う。
ターミナル操作をウェブで配信する
https://qiita.com/ohtaman/items/775b3831754336c75208

● その他
帯域が狭い・だけど遅延は減らしたい、みたいな場合は、ssh -C でsshセッション越しが楽だと思う。