更新：2024/5/26 スクランブル未解除ファイルの解除方法を追加

● メンテ＆トラブルシューティング　now!
　∟ 定時診断スクリプト
 前編
　１．ラズパイとサーバーの概要
　２．録画に必要なものを集める、購入する
　３．OSのインストールとセットアップ
　４．NASの構築
後編(docker-dvb版)
後編(docker-px4_drv版)
　５．チューナードライバの導入
　６．docker-mirakurun-epgstationの導入
後編(非docker版)
　５．チューナーの導入、テスト録画
　６．運用のためのツール、mirakurun、epgstation
運用実践編
　７．録画管理方法
　８．エンコードと再生
　９．システムバックアップ
番外．まとめ版
番外．Mirakurunのチャンネル手動設定
番外．ラズパイ用ケース作成
発展途上スクリプト
ニチアサが放送されるかどうかを告知してくれるシェルスクリプト
 スポーツ中継検出シェルスクリプト

ラズパイ4録画鯖の日頃のメンテ及びトラブル解決手段
LinuxはOSだけでなく各パッケージがアップデートされるため、一度構築したからあとは勝手に、というのも意外とうまくいかない。そのため、メンテナンスは重要。やたら長くなったのでページ内検索を適宜活用推奨します。

直近の緊急項目

・放送大学の移動に対応2024.11/12
Mirakurunのチャンネル手動設定

・dockerのビルドが動かない現象2024.1/6

sudo docker-compose pullなどでエラー.

TypeError: kwargs_from_env() got an unexpected keyword argument 'ssl_version'

この場合、

暫定処置.

sudo pip install docker==6.1.3
を行い、そのあとでdockerのビルド等を。pipdockerが7.0.0だとSSLのバージョンが何たらだったか、でバージョンを下げるとOK。詳しくはググる等でお願いします。

よくやるコマンド、その他更新のたぐい

＊更新作業は録画予約が入っていないタイミングで、トラブル時の復旧時間を考えて行いましょう。更新・再起動した後は最低限ストリーム再生がきちんとできるかすぐに確認しましょう。
＜最新版チェック＞
ラズパイOS　EPGStation　Mirakurun
(Win)TVTest　(Win)TVTestビルド済み　 MirakTest

Mirakurunに登録するチャンネル情報の最新版(私版)

OSのアップデート、システムバージョン表示、システム起動時刻.

sudo apt update;sudo apt -y upgrade
lsb_release -a
uptime -s;uptime -p

↑これらのコマンドは、(少なくともWin上では)トリプルクリックで選択できる。あとは右クリックor Ctrl+C でコピーして実行したい場所に張り付けて実行でもするがよい。
sudo apt update　で内容取得、sudo apt -y upgrade　で適用。
パッケージのインストール失敗がOSアプデかけてないということもある。

docker-mirakurun-epgstationのアップデート、停止、起動、再起動.

アップデート
cd docker-mirakurun-epgstation; sudo docker-compose pull; sudo docker-compose build --pull;sudo docker-compose up -d; cd ~
停止
cd docker-mirakurun-epgstation; sudo docker-compose down; cd ~
起動
cd docker-mirakurun-epgstation; docker-compose up -d; cd ~
再起動（MirakurunだけならMirakurunの管理画面からでも行けます）
cd docker-mirakurun-epgstation; sudo docker-compose restart; cd ~
停止＋起動
cd docker-mirakurun-epgstation; sudo docker-compose down; docker-compose up -d; cd ~

ただしアプデしたがゆえにうまく動かないケースもあるので、そこは了解したうえでお願いします。
いうまでもなく更新作業中は録画不可なので、EPGStationの予約欄等を確認して大丈夫か確認でお願いします。
↓1行ずつの場合 cd docker-mirakurun-epgstationで移動してから。終わったら元に戻すcd ~推奨。
＜アップデート＞
１．mirakurunとdbを更新
sudo docker-compose pull
２．epgstationを更新
sudo docker-compose build --pull
３．最新のイメージを元に起動
sudo docker-compose up -d
＜停止＞
sudo docker-compose down
＜起動＞
docker-compose up -d
＜再起動＞
sudo docker-compose restart

非docker版でのアップデート、停止、起動、再起動.

余裕あったら書きます

OSの再起動等.

sudo reboot
もちろんGUIから行ってもよい
また、録画中がない時のみ再起動実行のシェルスクリプトが↓にあります。

シャットダウン(すぐする)は
sudo shutdown now

各種管理画面の場所。ipアドレスは↓1.22の時、実際は各自の環境に合わせてください。
mirakurun管理画面：http://192.168.1.22:40772/
mirakurunのapi：http://192.168.1.22:40772/api/debug
epgstation管理画面：http://192.168.1.22:8888/
epgstationのapi：http://192.168.1.22:8888/api-docs

B-CASカードの更新.

テレビやレコーダーがあれば、そちらに挿せば更新されるはず。
casのキーの更新タイミングは1週間前からわかるらしく(EPG参照らしい)、
5chのcasスレが騒がしくなるとのこと(違法?なのは改造なので、更新把握は問題ない)、
XTwitter検索っても情報少ないです。
カードリーダーを使った更新(違法か規約違反か)は、Windows上で行い、
ツール(角鶴?GUI)使用とCUIツールバイナリ編集の方法があるが前者が簡単か。
詳しくは知らんが上がってくる文字列をiniに加えて保存して起動でもすればいいんだろうか？
とりあえず、なんかっぽいURLを適当に載せると

ラズパイの設定コマンド.

sudo raspi-config
sudoが必要なことに注意

ストレージの書き込み権限全廃.

chmod 777 (対象のフォルダパス)
まぁ必要ならば最初にやっているとは思いますが。

温度や電力不足。基本的にラズパイOS用のコマンドなのでそれ以外では多分使えない.

温度表示コマンド（少なくとも60度以下なら大丈夫では）
vcgencmd measure_temp

電圧状態表示コマンド
vcgencmd get_throttled
－－－－－－－－－－－－－
　throttledの値	状態
　0x0	　　正常
　0x50000	過去に低電圧状態になったが、現在は正常
　0x50005	現在低電圧状態にある。
　0x80000	過去に熱によりクロックダウンした。
　0x80008	現在熱によりクロックダウンしている。
－－－－－－－－－－－－－
Pi本体の状態なので、チューナー等接続デバイスの情報は表示されない。

デバイス接続のチェック.

USBデバイスを表示する。-tを付けるとツリー表示
（現在接続されているデバイス等の表示）
lsusb
lsusb -t

搭載しているチューナーで表示は異なります。↓↓一例
＜PX-S1UD、Q1UDの場合＞
Bus *** Device ***: ID ****:**** VidzMedia Pte Ltd
＜PX-MLT5PEの場合＞
Bus *** Device ***: ID ****:**** N'Able (DataBook) 
Technologies, Inc. PXT5PE

B-Casカードリーダーの接続もlsusbで確認。↓一例
Bus *** Device ***: ID ****:**** SCM Microsystems, Inc. SCR3310-NTTCom USB Smart Card Reader

デバイスファイルのチェック
（現在接続されているデバイスファイルの表示。ドライバが読み込まれていないと出てこない）
ls /dev
PX-MLT5PEの場合はpxmlt5video*

コマンド打つ順番としては、
1. まずは lsusb を打つ。デバイスが認識していればlsusbで表示される。
2. 次にls /devを打つ。ドライバが読み込まれていないと表示されない。

チューナートラブル自動復帰と通知

録画サーバーを立てていると、ラズパイ自体の動作がおかしくなった、再起動等に失敗している、チューナーの動作・認識が狂っているという状態が少ないながら起こりえます。そんな状況はできるだけ早く状況の自動通知あるいは自動復帰したいところ。その手を扱う記事は非常に少ないです。

・異常検知方法

理想はPi自体での検知と、lan内の別端末(別のPiやスマホ、稼働時のみだがWindows)からの検知を両方行えばより確実に異常の通知が行え、録画失敗を防げると思われる。
Pi内での自己診断をする場合、ハードの各種チェックコマンドやMirakurun,EPGStationのAPIにアクセスが使える。
Piの外からチェックではpingを使った生存確認やMirakurun,EPGStationのAPI利用。
どれもそうだが、場合によっては誤作動を防ぐために2,3回コマンド実行チェックも手。あと、端末が再起動中の可能性も見積もっておいた方がよい。

・通知方法（自己診断）

異常等起こった場合にどうやってそれを伝えるか
通知をせず自動再起動する設定にする
　通知する方法が不要になる点は楽だが、そううまくいくか...？
　そのまま再起動ができない環境(Q1UDで配線無改造など)は注意。
　設定ミス、誤作動には注意。また再起動では治らないケースも注意。
Lチカもしくはミニモニターを使った通知
　邪魔にならない点は〇
　外出先など遠隔で知ることができない、それ用のハードを用意する必要がある。
スピーカーなどを付けて音で通知する
　スピーカーはダイソーでも買えるのでハード面のハードルは低め。
　外出先など遠隔で知ることができない。家族が留守番時などはうるさくさせてしまう。
メール送信、ライン通知、ファイル作成
　他の端末で異常を受け取る方法。
　メール：私は実装方法がわからないがアリでしょう。
　LINE通知：これがかなりベターなのでは。
　調査結果をファイルに記載：piの診断結果を定期的に保存し、それを定期的に確認。
音やラインなどの通知だと頻度によってはうるさくなる可能性には注意すること。

・通知方法（外部から監視）

録画Pi自体が落ちた時のために、別端末から監視できるのが理想。
・別鯖(ラズパイでも他の鯖でも)でbash等を定期実行
・稼働時のみにはなるがWindowsから定期実行や随時実行
・Android等スマホからpython等のスクリプトを任意実行
通知方法は、スピーカーやライン、メールなどを使用。なお、そもそもルーターが落ちてしまうと録画Piの異常チェックができない。ルーター他にアクセスできるかチェックも必要かと。

otherpicheck.sh そのうち統合した改良版を作りたい

#!/bin/bash
# このシェルスクリプトをcronに登録して実行する(もちろん録画しているのではない方のpiなどのサーバー)。
# 当然ですが寝ている時仕事など留守中は実行しないほうがいいです対応できないし。
# ↓IPアドレスやaquestalkpiは環境に合わせて変えてください。ターゲットでepgstationが実行していない(もしくはpiが見つからない)としゃべります。
abc=$(curl -s http://192.168.1.22:8888/api/streams?isHalfWidth=true)
echo $abc
if [ "$abc" = "" ]; then
 echo "ラズパイが認識できません"
 ./aquestalkpi/AquesTalkPi -b -s 60 "録画のパイが認識できません。落ちているかルーターがおかしいのか" | aplay -D plughw:2,0
else
 echo "ラズパイは認識できています"
fi

・解決方法

デバイスのちょっとした問題なら大概は再起動で解決する。チューナーの電源オフをソフト上で実行できればいいが、うまくいく方法がなさそう(GPIOでスイッチを作るという戦略は考えられるのだろうか？)。なお、物理的なシャットダウンや再起動ボタンがあれば家族等に頼みやすいかもしれません。
症状によっては再起動せずともドライバ再ロードで可能かもしれない。B-Casリーダーはdocker再起動でOKっぽい。

・memo:チェックの方法（極力自動化を）

・チューナーの認識チェックのためにlsusbやls /devなどの実行を。
・動作が暴走(pidが増え続ける)している場合はmirakurunのapiを使ってチェック。同軸ケーブルが外れているだけの時との判別が難しいのは了承ください。
・スクランブルのチェックは効果的な方法がよくわからない..
・異常時に自動再起動をかける方法もあるが、安易に実行も避けたいか。
・内容を随時まとめていきたい↓
■■■ 自動チェックするシェルスクリプト(bash) ■■■

トラブルシューティングのたぐい

録画ができない、または録画の確認ができない場合、どこがおかしい？

・番組表が見れないだけでなく、sambaサーバーに接続できなかったりvncで接続できない場合は高確率でラズパイ自体起動に失敗している(pingをかければなお確実)。またはルーターがおかしくて接続できないだけの可能性もあるが。
・OSの起動に失敗している場合の理由としては→たまたま失敗した、OSのシステムがおかしい、など。ヘッドレス運用の場合、VNCやSSHで接続できなかったらこれ。強制再起動、あるいはUSB起動の場合はポートを変えてみるとか。
・頻繁に強制再起動される場合、Piの電源が劣化している可能性もある。電圧降下をコマンドで定期的に調べ、多すぎる場合注意。
・OSは起動できたがsambaが動いていない→かなりのレアケースでは。とりあえず再起動か。直らないときはsambaの設定確認か再インストールを。
・Mirakurunでpidが暴走していたりEPGStationでうまく録画されない場合はチューナーの動作がおかしい可能性。チューナーが見つかるかをまず試す。チューナーとOSの電源をまず切って再度起動する。なおチューナーが動かない場合はたしかmirakurun,epgstationも動かない。
・Mirakurunからストリームは動いているが予約録画がうまくいかない場合はepgstationに問題あり。
・録画自体はできてもスクランブルが外れていない場合はカードリーダーの接続や認識に失敗しているかbcasカードをきちんと読みこめていない。

・ラズパイ自体にアクセスできないのでOSの再インストールしようと思います

早まらないでください！ただ単にルーターの調子が悪く接続できないだけでPiは正常というケースもあるので。ルーターの再起動の他は、可能ならhdmiなどで画面を映す、他の機器でネット接続やラズパイへのアクセスができるかなど様々な経路を確認した方がいいです。

・ラズパイの再起動後にEPGStation/Mirakurun(docker)が動いてない

（録画失敗, MirakurunとEPGStation動作失敗）
私はシステムのアプデ＆再起動後にこうなった。
1.まずdockerの起動(↑上の方にある)を試してみる。
もしデバイスが見つからない的なエラーが出たら、ls -devやlsusb
(mirakurunはデバイスが動かないと起動しないみたい)
録画デバイスが表示されない場合の処理だが、

非公式ドライバ使用の場合.

cd px4_drv
cd driver
＊現在px4_drv\driverディレクトリ
sudo modprobe px4_drv
でドライバを読み込ませて、再度
ls -dev
これでチューナーらしきのが見つからないなら、
＊現在px4_drvディレクトリ
sudo apt-get -y install raspberrypi-kernel-headerscd driver
make
sudo make install
再度インストール完了させてmodprobeで読み込ませる
sudo modprobe px4_drv

これでどうでしょうか

・(DHCPのため)ラズパイのパスがわからない

2から順にしらみつぶしに試してみる、advanced ip scannerなどのlan探索(?)ツールを使ってみる、など。インストール時は仕方ないにしても、できるだけ早く固定IP設定しておいた方が楽です。ただし、家庭内LANの規模であればDHCPでもそうそう頻繁にアドレスは変わらない傾向ではあります。

・ラズパイのデフォルトパスワードなんだっけ？

id:pi　pass:raspberry
なお、VNCのアクセスも同じです。

・SSHで接続できない

もしかしてssh ＜IP＞してますか？ssh pi@＜IP＞です、お忘れずに。
ヘッドレスでインストール直後ならSSHの許可(空のフォルダ等作る)を忘れている可能性も

・vncでアクセスしてもguiが出てこない

場合によっては起動してからしばらく待たないと出てこないことも。ラズパイOSはliteではないですよね？

・HDD/SSD等ストレージを読み込めるけど書き込めない

chmod 777 (パス) 等で書き込み可能にするのを忘れずに

・makeできない

(私には)詳しくはわからないですが、現在のパスが合っているか確認

・定期的に再起動した方がいい？

OSの安定性だけからいえば極稀でいいはずですが、チューナーの認識の方が不安定になりやすい環境の方もいるよう。安定性があまりよくない場合は週１再起動した方ががいいかもしれない。何時、何曜日にするかは利用次第で、月曜朝４時あたりが一番影響ないでしょうか？(もちろんcron使って自動再起動。その時間に起きろなんてさすがに言わないぞｗ)ただし再放送か特番かでその時間に録画したいものがある可能性も微レ存。そんなことを考え、再起動をするが、録画中or録画が近いときは再起動を行わないというスクリプトを書いたので、使いたい方はご自由にお使いください。
ただし自動再起動でトラブルが起こる可能性もないわけではないので再起動は手動で行うという考え方もあることを留意しておきましょう。直近で録画予約があるか、あるなら何分後なら余裕持って再起動できるかを教えてくれるスクリプトどこかに落ちてないかなー？
bashの設置方法よろしく、文字コードUTF-8、改行コードLFで保存でお願いします、メモ帳じゃできないのに注意。

reboot_nonrecording.sh

#!/bin/bash

# システムを再起動するスクリプトだが、録画中と録画まで10分以内は再起動しない。cron定期実行を想定。
# ストリーミングされているかチェックはしていません。ご留意を。
# EPGStation環境必須です。ない場合は失敗します。
# jqコマンド必須です。インストール→sudo apt -y install jq

#● EPGStationのURL
epgstation_url=http://localhost:8888/

# 現在時刻をUnixで
timenow=$(date +'%s')

# ■ 録画中が何件かチェック→次の予約までの時間をチェック。
abc=$(echo $(curl -s $epgstation_url"api/recording?offset=0&limit=24&isHalfWidth=true") | rev | cut -c 2-2 |  rev )
if [ $abc = 0 ]; then
# 録画中でなければ、次の録画まで何分かをチェックし、10分以上あるなら再起動を行う。
# offsetは現在から何番目の予約から開始か(最初0)、limitはそこからの数(最低1)
  def=$(curl -s $epgstation_url"api/reserves?offset=0&limit=1&type=normal&isHalfWidth=true" | jq -c '.reserves[] | [.startAt]' | cut -c 2- |  rev | cut -c 2- | rev)
  if [ $((($def/1000-$timenow)/60)) -gt 10 ]; then
    sudo reboot
  fi
fi

Q1UDを補助電源挿したまま再起動しようとすると起動しないことがある(補助電源からPiへ電力逆流が起こり起動しない？)ので、そこは注意。なお、補助電源挿したままでチューナー自体の動作に問題ない場合、dockerだけを再起動するという手もある。
なお、理由はわからないが再起動自体に失敗？してOSが立ち上がらないケースもある。再起動後にきちんと動いているかはチェックしておきたい。

crontabでの実行例.

＜編集はcrontab -e、内容表示はcrontab -l＞
月曜朝と金曜朝3時57分に再起動する
57  3 * * 1,5 sudo /sbin/reboot
月金以外の朝3時57分にdockerコンテナを再起動する
57  3 * * 0,2,3,4,6 cd docker-mirakurun-epgstation; sudo docker-compose restart; cd ~
月曜朝3時57分に上記のスクリプトを使って再起動する
57  3 * * 1 bash reboot_nonrecording.sh

・[非docker版]mirakurun,EPGStationが自動起動しない

pm2 status, sudo pm2 statusで確認

・温度および電圧状況を自動チェックする

即時で調査するなら↑上記にある1行のコマンドを
自動チェックはこちらのスクリプトを。

・カードリーダーが邪魔です

ご自身でどうにかしてください。自己責任でsoftcasを入れるという手もありますが。あえて言うならワイヤー等を駆使してどこかに括り付けて邪魔にならないようにするのがいいでしょうか。例えばSCR3310-NTTCom系なら一度蓋を開けてひも(100均の園芸用ワイヤーが一例)等を通せば金網などに括り付けるのもやりやすいでしょう。

MirakurunのUIもEPGStationのUIも録画コマンドも動くがMirakurunで受信が始まらない

非公式ドライバpx4_drv使用時は特にですが、
docker-compose.ymlの
- ./mirakurun/run:/var/run/
- ./mirakurun/opt:/opt/
追加と
cp -p /usr/local/bin/recpt1* mirakurun/opt/bin/
を忘れていないでしょうか？

コマンドで録画テストしても字幕とかだけで画面が真っ暗、または録画したデータがサイズは問題ないのに再生できない

スクランブルかかったままでb25が動いてないのが原因の可能性。CS受信できるなら、ショップチャンネルとQVCの再生ができるなら確定。tvtestで再生すればスクランブルの存在も確認できる。dockerの場合b25は明示せずとも勝手に入るのでコマンドテストして、あれ？と思う可能性はあるかも。

B-Casリーダーの認識の問題か

何らかの原因でB-casリーダーの認識が外れている可能性がある。再起動したら直ると思われるがdocerの再起動だけでもOKっぽい。もしカードが抜けかけてたらもちろん挿しなおす。なお、lsusbでの表示が問題なくても(認識してても)スクランブル解除の動作がされてないことも多いか。

B-Casリーダーの認識の問題か

BS,CS有料系だけおかしい場合はキーが更新されている可能性なので調べる。また、特定のチャンネルだけ映らない場合、チャンネルが移動している可能性があるので調べる。

自動検知

おかしくなった時に自動的に察知して知らせるか自動的に再起動等する方法→スクランブルの検知方法はわからん！b25を何らかの形で実行するとか？

BSやCSの有料放送を見てますが録画がある時期から再起動等をしても再生できません

...あの...どういう方法で環境構築したかはあえて聞きませんが、そういうのは合法違法問わずリスクや対処方法について自分で何とかするのが原則ですよ。キーを更新するには、レコーダー等に差し込んで更新されるのを待つか、Windows機にカードリーダーを挿してiniファイルを編集したなんとか鶴GUIといったツールを使うかでしょうか、知らんがな
なお、スクランブルで再生できないファイルについては、

スクランブル解除に失敗したファイルはどうする

何らかの理由で(キー更新忘れ以外にもなんか失敗するケースは稀にあるようです)スクランブルが残ってしまったファイルは削除しかないのでしょうか？実は、Win上でカードリーダー(とBCas)とvlcを使えば解除が可能です。

字幕の抽出をする場合は、この工程ではうまくいかないかつスクランブル関係無く行えるので、先に行っておく。
Winとカードリーダー(+再生できるBCas)を用意する
vlc(ver3以上)をDLして起動する
メディア > 変換/保存 > ファイル選択 > 追加 > 解除したいファイルを選択 > 設定、変換、プロファイル > 新しいプロファイルを作成(名前は適当に"ts"とか、カプセル化mpegts,ビデオオーディオともにオリジナル保持) > 出力ファイル > 参照 > 開始

いつメンテをすればいいのか

アップデートをする、新たなOSを別ディスクで試してみたい時など、いつ行えばいいのか。まぁ簡単に、無責任に言えば、好きな時にで構わないのですが...実際には、
・録画中、あるいは録画が近い時
・誰かが再生、コピー等を行っている
時は避けた方がいいですよね、特に前者は。(後者は後から再試行できますが前者は基本不可) 録画中か、次の予約が近いかはepgstationから見ればわかるのですが、イマイチ一覧性が悪い(録画中はともかく直近の録画は何時間後とかは書いていない)。なので、定期診断スクリプトにはそこらへんも合わせてみました。

チューナーに関すること

・電力不足が原因

各種症状の原因が電力不足でチューナーの動作がおかしくなる場合がある。この場合の解決は、
　いったんチューナーを外してもう一度接続する
　OSを再起動する
　OSをシャットダウン、チューナーの電源をいったん断って再接続、OS起動
チューナー再接続は(物理的に)意外と面倒なのでまずはOS再起動をためす場合が多いです。なお前編とかで述べたがQ1UDは補助電源を挿さないと電力不足しやすい(特に3番組以上同時で)し、補助電源挿したままだとOS再起動に失敗するので注意。デバイスの問題なので、dockerを再起動しただけではおそらく直りません。

・電圧降下が頻発する

チューナーの問題ではなく電源の問題とは思いますが、以前は少なかった電圧不足が頻繁に起こるようになったら(そのためにも電圧不足の記録スクリプトは有用)電源が壊れかけている可能性があるので早急に新しいのを用意した方がよい。

・チューナーの一部が不安定で優先して使いたくない/負担を分担してあげたい

しばらく使っていると気づくとは思いますが、Mirakurunは最初のチューナーから使用します。ローテーションあるいはランダムにする設定は無いんですよね。そんな時は、定期的に手動で順番を変えてあげるといいかもしれません。チューナーが2つなら奇数月に1番を上、偶数月は0番を上にする、チューナーが5つなら1月6月11月に1番を上、5月10月に0番を上に、といった規則案を出しておきます。

↑　Mirakurunの設定画面を開いて、順番を上下して保存するだけ

・EPGStationから予約録画をしても録画されない、おかしい
・リアルタイム視聴ができない
・チューナーが認識されない、おかしい

→　チューナーの認識異常、ドライバや電力不足など
（OS=OK, Samba=OK, 録画=NG, EPGStation=OK, Mirakurun=△）
要因はいくつか考えられるが、たぶんチューナーの動作が不安定、認識がおかしい。電力不足の可能性も。OSの再起動をまず試すべきか。番組表やSambaは正常なので、異常に気付きにくいので注意。mirakurunの管理画面でチューナーの使用状況もチェックすること。
他にも、ls /devでモジュールが読み込まれてないケースもある。lsusbなど認識自体はしているのなら壊れているということはないと思う。一度ラズパイをシャットダウンしてチューナーの外部電源も一度外してからまたつけると普通に認識することもある。

・EPGStationで予約してもうまく録画されない

また、チューナーがすべて使用中である可能性。特に１チューナーしかない条件は注意。mirakurunの古いバージョンの場合getepgコマンドが動いていて失敗する可能性も(アップデートしなさい)。
http://192.168.1.**:40772/
でmirakurunの管理画面からチューナーの使用状況を確認。（ただしrecdvbコマンドで直接録画を使用している分は表示されない。crontab等を使って録画をしている時は特に注意）
EPGStation/mirakurunに原因があるのか、録画機能そのものに原因があるのかを切り分けるために非dockerの場合はrecdvbコマンドで試す。場合によっては局によって録画できない場合？複数チューナーのうち一部がうまくいかない可能性があることにも注意。なお、録画予約して時間になっても、録画が始まらない(チューナーが使用状態のまま解けないというわけではない)ケースもある。そんな時は、dockerを再起動を試すのは一つですね(ハードの問題ではない場合はソフト的に再起動するということ)。

・Mirakurunのチャンネル情報を編集したいが何も考えずにしていい？

Mirakurun管理画面から行ってもchannels.ymlを編集してもいいですが、そのあとチャンネル情報の再取得が起こり(さっさと終わらせるならmirakurunを再起動させる)、それに10分？30分？くらいかかるので、直近に録画予約があるときにはやらないようにしましょう。
なお、再取得中に予約リストを見るとルール設定したものが表示されず個別のものも局がよくわからないことになってますが、仕様です、消えてはいないはずです。ただ、再取得が完了する前に放送が始まった番組は追っかけて録画をしてくれはしない模様(というかそんなタイミングで情報編集すんなｗ)なので、手動で再登録しましょう。

・EPGStationの画面が動かない

ページ自体が見つからない場合は起動していない可能性が。
cannot getと表示され、＜IP＞8888/api-docs/?url=/api/docs#/の方は表示される場合は...すまんいくら調べても原因がよくわからなかったとだけ報告しておく。
上部だけ表示され、番組表が表示されない場合は、数十分待っていれば大丈夫だと思われます。

・mirakurunの管理画面を見ると、pidの値がどんどん増えていく

（OS=OK, Samba=OK, 録画=NG, EPGStation=OK, Mirakurun=△）
これもチューナーの認識関連。電力不足の可能性が高い。チューナーの接続等が問題ないかを確認したうえで、OS自体を再起動すればなおるケースが多いか。またはチューナー自体の電源も一度切っておいた方がいいかもです。

・チューナーがフルに使えない

（OS=OK, Samba=OK, 録画=△, EPGStation=OK, Mirakurun=△）
4チューナーあるはずなのに4番組同時録画ができず３止まりになる等。mirakurunの管理画面を見ると稼働状況がわかるはず。古いmirakurunだとgetepgの最中はそのチューナーは使えないという現象が起きていたが、最近の(少なくとも3.8以上は)バージョンでは録画や視聴が優先のはずなのでその現象は起こらないので、とっととアップデートしなさい。また、例により電力不足の可能性も。その場合はpid値増殖すると思うので確認を。

・コマンドでの録画テストも失敗する
・デバイスの認識はする
・数時間とか動かすと動かなくなり再起動直後は大丈夫
・FILTER 8192: DMX SET PES FILTER: Connection timed out(非docker:録画コマンドで発生)

電力不足かも？
コマンド録画が失敗するときは、スクランブル解除失敗が原因か録画自体失敗かも確認してください。

・EPGStationで赤い点線

チューナー使用数オーバーでしょうか？もしきちんと数があるなら、mirakurunのチューナーの種類があっているか確認の上で、dockerを再起動してはいかがでしょう。
なお、MLT5/8の場合、MLT5で[地上波5+BS5]とかも操作上は可能ですが、実際には6つ目以降は録画できません仕様です。[地上波5][BSCS5]で認識しているが物理的には合わせて5ということで、考えりゃ普通わかるでしょうけど(わかんなかったら学習)。もっともそんなに同時に録画することもないでしょうし覚えておけばいいだけの話です。

・チューナーがきちんと受信しているかを確認、電波の強さを調査

電波の信号の強さをチェックするのも手。
docker版の場合はchecksignalを使うか別途コマンドrecdvbchksigをインストールする必要。
checksignal --device <デバイスの場所> <物理チャンネル>
recdvbchksig --dev <デバイス番号> <物理チャンネル>
SNPの強さを見るためのコマンド。(300でかなり強い、200あれば受信可能？)
recdvb1.31以下では動作がちょっとおかしいので、パッチの当たった1.3.3を使ってください。CNRが25とかあれば大丈夫ということ？SIGは電波強度で、大きい(マイナスの数値が小さい)ければいいということでもないとのこと。コマンド動作はずっと続いてしまうので、ctrl+Cで動作を止めましょう。

[非docker版]録画テスト.

# 連続実行(物理チャンネル16,28,30,32)
recdvb --b25 --strip --dev 0 16 7 /home/pi/ssd/recdvb0_nhk.m2ts;recdvb --b25 --strip --dev 1 28 7 /home/pi/ssd/recdvb1_rab.m2ts;recdvb --b25 --strip --dev 2 32 7 /home/pi/ssd/recdvb2_aba.m2ts;recdvb --b25 --strip --dev 3 30 7 /home/pi/ssd/recdvb3_atv.m2ts
# 連続実行(recdvbワンセグ除,物理チャンネル16,28,30,32)
recdvb --b25 --strip --sid hd --dev 0 16 7 /home/pi/ssd/recdvb0_nhk.m2ts;recdvb --b25 --strip --sid hd --dev 0 28 7 /home/pi/ssd/recdvb1_rab.m2ts;recdvb --b25 --strip --sid hd --dev 0 32 7 /home/pi/ssd/recdvb2_aba.m2ts;recdvb --b25 --strip --sid hd --dev 0 30 7 /home/pi/ssd/recdvb3_atv.m2ts

電波テスト_非docker。デバイス0-3.

# 物理チャンネル13_NHKEテレ津軽
timeout 7 recdvbchksig --dev 0 13;timeout 7 recdvbchksig --dev 1 13;timeout 7 recdvbchksig --dev 2 13;timeout 7 recdvbchksig --dev 3 13
# 物理チャンネル16_NHK総合津軽
timeout 7 recdvbchksig --dev 0 16;timeout 7 recdvbchksig --dev 1 16;timeout 7 recdvbchksig --dev 2 16;timeout 7 recdvbchksig --dev 3 16
# 物理チャンネル28_RAB青森放送津軽
timeout 7 recdvbchksig --dev 0 28;timeout 7 recdvbchksig --dev 1 28;timeout 7 recdvbchksig --dev 2 28;timeout 7 recdvbchksig --dev 3 28
# 物理チャンネル30_ATV青森テレビ津軽
timeout 7 recdvbchksig --dev 0 30;timeout 7 recdvbchksig --dev 1 30;timeout 7 recdvbchksig --dev 2 30;timeout 7 recdvbchksig --dev 3 30
# 物理チャンネル32_ABA青森朝日放送津軽
timeout 7 recdvbchksig --dev 0 32;timeout 7 recdvbchksig --dev 1 32;timeout 7 recdvbchksig --dev 2 32;timeout 7 recdvbchksig --dev 3 32

電波テスト_docker版で、px-mlt5peのチューナー0~4.

# 物理チャンネル13_NHKEテレ津軽
timeout 7 checksignal --device /dev/pxmlt5video0 13;timeout 7 checksignal --device /dev/pxmlt5video1 13;timeout 7 checksignal --device /dev/pxmlt5video2 13;timeout 7 checksignal --device /dev/pxmlt5video3 13;
# 物理チャンネル16_NHK総合津軽
timeout 7 checksignal --device /dev/pxmlt5video0 16;timeout 7 checksignal --device /dev/pxmlt5video1 16;timeout 7 checksignal --device /dev/pxmlt5video2 16;timeout 7 checksignal --device /dev/pxmlt5video3 16;timeout 7 checksignal --device /dev/pxmlt5video4 16
# 物理チャンネル28_RAB青森放送津軽
timeout 7 checksignal --device /dev/pxmlt5video0 28;timeout 7 checksignal --device /dev/pxmlt5video1 28;timeout 7 checksignal --device /dev/pxmlt5video2 28;timeout 7 checksignal --device /dev/pxmlt5video3 28;timeout 7 checksignal --device /dev/pxmlt5video4 28
# 物理チャンネル30_ATV青森テレビ津軽
timeout 7 checksignal --device /dev/pxmlt5video0 30;timeout 7 checksignal --device /dev/pxmlt5video1 30;timeout 7 checksignal --device /dev/pxmlt5video2 30;timeout 7 checksignal --device /dev/pxmlt5video3 30;timeout 7 checksignal --device /dev/pxmlt5video4 30
# 物理チャンネル32_ABA青森朝日放送津軽
timeout 7 checksignal --device /dev/pxmlt5video0 32;timeout 7 checksignal --device /dev/pxmlt5video1 32;timeout 7 checksignal --device /dev/pxmlt5video2 32;timeout 7 checksignal --device /dev/pxmlt5video3 32;timeout 7 checksignal --device /dev/pxmlt5video4 32

# シェルスクリプトにしてから実行するのもアリでは

値が小さい場合は、ブースターを入手してで信号増幅する。あと、場合によってはアッテネーターで信号減らす必要がある場合もある（Q1UDはむしろ内部で増幅するためこちらの方が必要となりやすいみたい？）。なお、信号減らすのはケーブルの半挿しでも行える。少なくとも仮の処置としては有効なのでは。

・特定の番組（物理チャンネル）とデバイス番号の組み合わせで電波が弱く録画できない

なぜか私のQ1UD環境で起こっています。Mirakurunは若いデバイス番号から使っていくようなので、デバイス０と対象のチャンネルがかぶると録画失敗するのでどうにかしたいところ。本当はmirakurunがそのバッティングを避けてデバイスを割り振ってくれるとありがたいが、そんな要望聞いてくれるわけない気がする。というわけで、とりあえずの回避方法。Mirakurunでのデバイス番号とそこで指定しているコマンドのデバイス番号をお互い入れ替えるという手がある。デバイス０でやっている用に見えるが実際のコマンドは３でやっている、などとね。

野球中継eteで番組表が逐次更新されてもEPGStationへの反映が遅い

何らかの理由で番組表がその場で変更されることがあります。テレビでは割と即時修正されているのにEPGStationへの適用が遅いことがよくあります。最初はmirakurunの問題かと思いましたが【ラズパイmirakurun経由WinのTVTest】では反映されているのでmirakurunやDBではなくEPGStationの問題です。
さて、これをどう対処するかですが...
・あきらめる。リアタイはどうせWin上のTVTestかAndroid上のIPTV(こちらはどうせ番組表は無い)で見るでしょう。
・録画については、問題になるのは野球中継後の番組でしょうしそれは録画時間をあらかじめ伸ばして対処する。
・取得間隔を1分にしてもあまり変わらないなぁ。

EPGStationの局配列を変えたいのでmirakurunで順番入れ替えればいいですか？

いいえ、EPGStation上の配列はちゃんと設定方法がありますので、左に配置したい局を記述してください。記述のない局はその後ろにちゃんと表示されるので必要なものだけ書けばいいです。
mirakurunの順番を変えてしまうと、基本良いことはなく悪いこともtvtestmirakurun構成の場合にメニューがおかしくなるということがあるので、やはり特別な事情がない限りはデフォルトの順番を厳守するべきでしょう。

EPGStationで番組表が更新されず、予約録画ができない。

ログファイルを参照.

/home/pi/docker-mirakurun-epgstation/epgstation/logs/EPGUpdater/system.log
を見ると、
[2022-02-02T09:10:50.727] [INFO] system - config.yml read success
[2022-02-02T09:10:50.756] [INFO] system - start EPG update
[2022-02-02T09:10:50.757] [INFO] system - start get stream
[2022-02-02T09:10:50.780] [INFO] system - get service
[2022-02-02T09:10:50.875] [INFO] system - start update channel
[2022-02-02T09:10:51.415] [INFO] system - done update channel
[2022-02-02T09:10:51.417] [INFO] system - get programs
[2022-02-02T09:10:51.634] [INFO] system - done get programs
[2022-02-02T09:10:51.643] [INFO] system - start update programs
[2022-02-02T09:10:54.760] [ERROR] system - update programs error

といった感じにEPGが更新されない。Mirakurunのログの方は更新されており、おそらく何らかの原因でEPGStationからMirakurunの読み込み？が失敗していると思われる。何日も調べたが、どうやらMirakurunのBeta版を読み込めない可能性が出てきた。

[docker].

Mirakurunのバージョンを固定するには、docker-compose.ymlを編集する。
version: '3.7'
services:
    mirakurun:
        image: chinachu/mirakurun:3.8.0

通常はバージョンは書いてないが、3.8.0 とすることでこのバージョンに固定できる。あとはdockerを再起動？アップデート？すればバージョンを下げられるようだ。この状態で数時間放置したら、きちんと番組表を読み込めるようになった。やっぱり最新版にしたい場合は:3.8.0を削除してchinachu/mirakurunにする。3.90rc4にしてからはこのトラブルはないが将来再発等したときはこちらを行うといいかも。
なおEPGStationで同様のことをする方法は私はまだわからない。まぁ必要になることもなさそうですが。

・なぜか録画予約しても録画されず、途中でキャンセルしてもチューナーが解放されない

一つの経験談に過ぎないので再現性は不明ですが、チューナーの受信が弱い場合に内部エラーだか何かが起きたのか？の時に起こるのかも。recdvbchksigコマンドでエラー値が出る場合は疑惑アリ。特定のチューナー番号や特定の物理チャンネルに発生する場合の他、チューナー番号と物理チャンネルの特定の相性？でのみ起こる場合があった、私の条件では。上述での電波強度の調節とかも考慮に入れるといいでしょうか。

・EPGStation上では予約されているのになぜか録画されない

ルールとして登録していてもある日突然録画されなくなることが私の環境では起こることがあります(mirakurun上で見てもチューナーは動いていない)。法則性がなく原因も全く分かりません、なのでバグ報告もしていません。データベース上の不具合なのでしょうか？解決方法は、ルールをいったん全部解除して、手動録画を登録したのも一度解除してもう一度登録すればおそらく大丈夫かと。最近は起こっていないので、最新版では大丈夫なのかも。

・チューナーが故障？

私の経験としては、録画ができない、recdvbでテストしてもビシーで動かなかったり、recdvbchksigで受信状況確認しても何も出てこない、0になる、220と0の交互になったり、といった状況が起こることも。でもOS再起動したりケーブル変えたりしたら直ることも。壊れたと思っても実は大丈夫だった。冷却は必要かと思ったが、やっぱり原則不要かも。

・dockerやosの再起動、停止等が面倒。ブラウザからできないか

やろうと思えば作るのも可能でしょうが、今のところ最適化した管理ツールは見たことないですね。誰か作ってくれｗ

・スポーツ中継などなどで放送時間がずれて録画が失敗する何とかしてくれ

理論上は30分間隔をデフォとしてEPG更新しているはずですが、なぜかうまくいかないことも多いですね。改善案を可能不可能織り交ぜて適当に書くなら、
・EPG更新間隔は地上波、BS、CSで別々に設定できるようにするべきでは、少なくともCSはそうそう番組表変えないでしょうし1日に数回程度で十分、逆に地上波は特に夜は頻繁に更新した方がいいでしょう。ここら辺、mirakurunの重大な改善ポイントな気がします。
・時間指定で録画する。ルールで設定済みのことも多いと思うので、番組表開いて直前の番組を詳細から時間指定にして前後余裕をもって指定するのが良いだろうか。
・1日に1回くらい、予約番組の数時間前～直前に「ジャンル：スポーツ」があるかどうかをチェックするスクリプトを作ってcronで自動実行し、結果をテキストファイルに吐き出すorライン通知する。
・そもそも中継で予定が狂うこと自体を規制するように法律改正するように持っていく。いや冗談でなくもうちょっと考えた方がいいでしょう(番組表変更自体を規制せずとも2時間前には変更を確定してそれ以降はよほどの緊急事態以外再変更を禁止する程度でよい)。でないと将来的にスポーツ中継自体に対するヘイトが起こる可能性あると思うぞー。

・それで、放送時間がずれる要因になりやすい番組ってなんだっけ

まず筆頭は野球。野球系統は所定の回の攻守をこなして勝負をつけるので決まった時間がない。延長なしという中継は(私が知らないだけの可能性もあるが)多分ない。
次に、サッカーやラグビー。どちらも試合時間が決まっていて、ロスタイム(今はアディショナルタイムか)の分長くなる可能性はあれどせいぜい5分程度なので通常は伸びない。ただし、引き分けの場合、延長戦もありうるので油断はできない。
相撲はおおよそタイムスケジュールに従っているはずなのでほとんどの場合中継の延長はない、が昔、武蔵丸の悲劇という事件があったとのことで千秋楽限定でしょうが10~30分くらい伸びる可能性を考えた方がベターか。
[メモ]中継で使われるキーワード。
試合開始、から中継、
[メモ]逆に、伸びないことが確定している場合。
録画
[局]スポーツ中継する可能性のある局は？
地上波全般、キー局のBS
あと、CSの専門チャンネルも中継自体はあるでしょうが、逆にそういうチャンネルで時間変更で困るような予約をする必要性は考えられなそう。
放送時間変更の可能性のある番組の自動抽出スクリプトはやっつけではあるが一応作ってみた。時間変更はまだまだ手動でお願いします。

・スポーツ中継等が無いはずなのに一部の番組が録画されない

原因はよくわからないですがそういうことが稀にあります。というか、ログを確認するか、ログに無い場合は録画予約のリストを覚えておいて後で見比べないとわからないと思う。そして予約リストは当然ながら時間を過ぎると表示されないので保存しておくべきでしょう、そのために保存するスクリプトがあるとよい。一応は作ってみた。

・設定ファイルがおかしくなった、デフォのファイルを教えろ

極稀でしょうが設定がおかしくなることはある模様。

channels.yml

バックアップファイルがなければ一度空にすればいいと思います。

server.yml

＊IPv6無効、epgインターバル900秒の場合↓
logLevel: 1
path: /var/run/mirakurun.sock
port: 40772
allowIPv4CidrRanges:
  - 10.0.0.0/8
  - 127.0.0.0/8
  - 172.16.0.0/12
  - 192.168.0.0/16
allowIPv6CidrRanges:
  - fc00::/7
disableIPv6: true
hostname: recordpi
epgGatheringInterval: 900000

tuners.yml

＊pxmlt5pe＆dockerの場合↓
- name: MLT5_4
  types:
    - GR
    - BS
    - CS
  command: recpt1 --device /dev/pxmlt5video4 <channel> - -
  decoder: arib-b25-stream-test
  isDisabled: false
- name: MLT5_3
  types:
    - GR
    - BS
    - CS
  command: recpt1 --device /dev/pxmlt5video3 <channel> - -
  decoder: arib-b25-stream-test
  isDisabled: false
- name: MLT5_2
  types:
    - GR
    - BS
    - CS
  command: recpt1 --device /dev/pxmlt5video2 <channel> - -
  decoder: arib-b25-stream-test
  isDisabled: false
- name: MLT5_1
  types:
    - GR
    - BS
    - CS
  command: recpt1 --device /dev/pxmlt5video1 <channel> - -
  decoder: arib-b25-stream-test
  isDisabled: false
- name: MLT5_0
  types:
    - GR
    - BS
    - CS
  command: recpt1 --device /dev/pxmlt5video0 <channel> - -
  decoder: arib-b25-stream-test
  isDisabled: false

・録画保存フォルダを途中で変更したいがどうすれば

先に説明した通り、普通にxmlファイルを編集する、録画ファイルも同様に移動、同時にSAMBA共有フォルダを変更してOS再起動すれば大丈夫なはず。
＊ここらへん後で実際に試してみます。

・録画Piもしくは保存ディスクが圧迫されてきた

基本的には自分でどうにかしろ！と言いたいものではあるが。
録画Piが圧迫されてきたら、見終わったものは削除、取っておくものはエンコして元を削除だが、どうしても一時的に忙しく見る時間もエンコする時間もないなら、自動エンコを検討してもいいかもしれない。
エンコ済み動画で圧迫されるなら、ディスクの容量を増やすのが手っ取り早いが、それ以外の手段としては、エンコの設定の見直し。運用実践編でも書いたが、好きなアニメやドラマならある程度解像度を高くしないと意味はないが、内容がわかればいいドキュメンタリーとかならDVDかそれ以下の画質にすることも検討するのはいかがでしょうか。サイズが小さければ容量も小さく、コピー、バックアップ時間も減るので納得できるならいいことづくめですよ。

・システムのディスク(SDやパーティションなど)が圧迫されてきた

基本的には十分な容量を最初から確保しておけばいいのではあるが、余計なファイルは削除したい。何が余計かは...いま調べている。

・バックアップしておきたい。何をバックアップすりゃいいんだ

録画したファイル。ただ、個人的には残しておきたいものはさっさとエンコしろとも言っておきたい。
録画のルール。録画する対象が定期なものしかなければ不要かもだが、多くの場合はキーワードをある程度登録しているはずなので結構重要です。
管理等で使っているシェルスクリプトがあれば。
mirakurunの設定ファイル。ネット上などで拾えるかもだが、チューナーやチャンネル設定はバックアップしている方が明らかに楽だと思う。
NAS的に使っている場合、そこに入れている各種ファイルも当然バックアップが必要。

あとは、環境全体。SDやHDD/SSDに問題が生じて再び構築しようとすると結構時間がかかる。予備のSDやUSBやらを準備しておくとダウンして使えない時間が大幅に減る。この辺りは私も時間のある時にまとめておきたいところ。
録画したファイルのサムネイルや履歴等の情報も一緒にバックアップできればいいが、優先度は低い。細かにやるのもいいが、それよりも優先度の高い上記を確実に行っておきたい。

・原因の究明手段,他

OSを入れなおす(別のSDにインストール)で試してみるのも場合によっては。問題が起こった際にどこに原因があるかの究明は意外と難しい。それをはっきりさせるための行為が必要になるのかも。

～～～～～～～～～～～～～～～～～～

市販レコーダーとの比較メモ

.	TS抜き	市販レコーダー
メンテ	×現状トラブル時面倒	〇基本トラブらない
コピフリ	〇やり放題	×ダビング９と低い自由度
録画の容易さ	△スマホ等からOKだがリモコン困難	△リモコンで誰でもできるがスマホからは不可か専用アプリ
設置の容易さ	△やろうと思えば場所を選ばないが形をまとめるのが意外と面倒	△設置しやすいが体積は意外とある
予約録画	〇登録可能数はかなり多い	△意外と制限がきついかも
容量の食い方	△ハードエンコも可能だが設定必要。ただ逆に言えばtsファイルを残して置けるということでもある。	〇エンコは自動で行われていて最適化されているはず
自由度	△むっちゃ自由度高い。...ただそれだけにどうすればいいのかわからないというぜいたくな悩みが発生する。	△正直全然高くはないな...
番組変更	△取得はできているはずだがEPGStationになかなか反映されない？	〇おおむね追従してくれる
失敗時	×現状の大きな短所。予約自体がなかったことにされることもある。	〇正直に表示してくれる
チューナー数	〇自由。ただし負荷のかけすぎには注意	×無駄に価格が上がる
テレビを増やす	〇同一ネット内スマホで簡単にテレビ見れる	×一部のモデル＋専用アプリなら？
アップデート	△アプデがあるのはいいことだが、反面依存関係等が崩れるトラブルが発生することも。対処法がわかればいいのだが情報提供する人が少ない	〇専用機だからかほぼアプデ無し。ただ、それってセキュリティ的に問題ないのか？
NAS機能	〇導入可能	〇あることが多いと思う

レコーダーとして欲しい細かい機能
・録画失敗を追跡できる(epgstationは失敗がなかったことにされることがある)
・スクランブル解除が失敗している時の通知
・温度のログと高温の警告
・再起動やシャットダウン等のコマンドをGUIから
・直近の予約等を含めもっと見やすい表示
・ルールでの予約のもっと簡単な個別解除
・epgstationのepg追跡が遅いような気がする
・mirakurunはbscsと地上波でepg更新の間隔を変えてほしい
・野球等の延長可能性が高い番組の後の予約リスト作成
・番組表と録画のfiretvアプリ

OSのバージョンメモ
・最新bookworm-64bit
　ある意味スタンダードか。問題が出ないか要チェック
・bookworm-32bit
　debianは結構32bitをサポートするのか？まだ32bitが残っている。しかしさすがに各アプリで問題出そうな気配がするが試してみないと何とも
　・bullseye-64bit
　・bullseye-32bit
　無難？
　・buster-64bit
　・buster-32bit
　サポート終了してなかったっけ？
とりあえずここら辺、実際にインストールして試しておいてもいいのかもしれない。