EDCBで番組情報が保存できなくなったので対応した話

概要

xtne6f版 EpgDataCap_Bon (以降、EDCB) を使って録画をしてたら、いつの間にか録画情報ファイル(xxxx.ts.program.txt)が保存できなくなったので、その対応について書いています。

結論

EpgTimerSrv をLocal Serviceで動かしている場合、録画先のフォルダに Local Serviceの書込み権限を追加する。

環境

録画専用のサーバPCで運用
OS: Windows 10 Pro 64 bit
キャプチャボード: Plex PX-Q3PE
録画ソフトウェア: EDCB ver.0.10.0 32bit版※ ( つくみ島だより様ビルド版 )

※カードが古くて32bit版ドライバを使ってるので32bit版を利用している

事象

いつの頃からか、録画時に一緒に保存されるはずの番組情報を記録したテキストファイル(xxx.ts.program.txt)が保存されなくなっていた。ドロップ情報ファイル(xxx.ts.err)は保存される。
(本来は下図のように、ts、ts.err、ts.program.txt の3ファイルが保存される)

以前は記録されていたが、3ヶ月ほど前に途絶えて以降ずっと記録されていない。(気付くのが遅い)
その頃、録画環境の刷新とHDDの追加による保存先の変更を行っていた (これは後から気付いた)

調査過程と解決までの流れ

ネットで情報探す、見つからない ⇒ (あまりメジャーな問題では無い？探し方が悪かったせいかも)
録画ファイルは保存され、再生に問題は無い ⇒ 特に録画設定に問題は無さそう
現在放送中のEPG番組情報は閲覧できる ⇒ EPG番組表に問題は無さそう
チャンネル再スキャン&EPG再取得、チャンネルファイル差分無し&変化無し ⇒ ファイルが壊れているという訳では無さそう
EpgTimerSrvサービスの再起動、変化無し ⇒ サービスがおかしいというわけではなさそう
マシン再起動、変化無し ⇒ そもそもこれで直るならWindowsアップデートのタイミングで直ってる
ソフトウェアの更新、変化無し ⇒ ソフトウェアのバグでは無さそう
別のデスクトップ環境で録画しても問題無く記録される ⇒ 録画サーバ環境の問題と思われる
ログ探す ⇒ そもそもエラーログは何処？デバッグログは、録画の開始・終了しか記録されてないっぽい？良くわからず
よく見たら、EptTimerの録画済み一覧からドロップログが閲覧できていないことに気付く ⇒ .ts.errファイル自体は記録されているので、ファイルにアクセスできてない模様
適当な別フォルダに録画してみるが、変化無し ⇒ フォルダの問題では無い？
EDCB環境再設定したところ、番組情報が記録されたが、再起動したら元通り ⇒ 設定の問題では無さそう
サービスとして動いてるEpgTimerSrvをアンインストールして、EpgTimerを実行してから録画すると、番組情報が記録された ⇒ 起動方法に原因がありそう

ここまで色々調べて、ようやく「ということは、プログラムを動かしてる権限が問題なのでは？」という結論に辿り着いた。ここまで分かれば、録画先のストレージの権限を見直してみたところ、管理者等のユーザーにのみ権限が当たっている状態だったので、「LocalService」に録画対象のフォルダに書込み権限を付与したところ、無事番組情報が記録された。(下図参照)

原因の推測

EDCBの動作は恐らくこんな感じだろう、と次のように理解した。

予約を監視して録画を行う「EpgTimerSrv」プログラムを動かすにはいくつかのパターンがある。

EpgTimerSrv.exe をユーザーが直接起動する (ログインユーザーのバックグラウンドプロセス)
EpgTimer.exeを起動した際に、自動的に起動 (ログインユーザーのバックグラウンドプロセス)
EpgTimerSrv_Install.bat からローカルサービスとしてインストール (ローカルサービスのプロセス)
EpgTimerSrv_Install.bat からシステムサービスとしてインストール (システムサービスのプロセス)

1.2は権限的に同じ。ユーザーがログインした状態でのみ動作し、ログアウトすると終了する。権限はログインユーザーに準じるので、ログインしてるユーザーができるファイル操作が出来る。
3はWindowsのローカルサービスとして動作する。LocalServiceというユーザーに対して権限を与える必要がある。
4はWindowsのシステムサービスとして動作する。システムにアクセスする権限が与えられるので強力な権限を持つ。ただの録画ソフトには大きすぎる権限だと思うので、普通は使わない方がいいと思う。

自分は、EpgTimerSrvを3のローカルサービスで動作させていた、理由としては、必ずしもログインされた状態で録画が開始されるか分からないので。(ただ、Windows自体は常にログインされた状態で運用していた。自分以外触らないし、めんどくさいので。)

ところが、3ヶ月前にHDDの環境変更を行った際に、録画保存先にLocalServiceの書込み権限が付与していなかったために、番組情報の記録が失敗していた、というのが今回の原因と思われる。

よく分かっていないのが、録画自体は問題無く成功していた点で、恐らくこれは録画ファイルの保存自体はログイン中のユーザー権限によって行われていたものと思われる。ただ、EpgTimerSrvがどのように動いているのかよく分からないので、何故こんな中途半端な挙動になっているのかはよく分かってない。あと、以前はこんな問題が起こらなかった気もするが(実際、保存できていた時はファイル所有者がログインユーザーの名前になっているが、今回の対応で保存できたファイルの所有者はLOCAL SERVICEになっている)、原因がどこにあるのか分かってない。自分がどこか対応をミスっている可能性はある。

ちなみに、 EpgTimerSrv_Install.bat を使ってインストールする時、きちんと権限について注意書きが出ているが、私は華麗にスルーしていた…。

学び

自分は仕事でアプリ開発とかやる人なので、その観点からの学びを列挙。

ソフトが半端な挙動をすると原因究明に時間がかかるので、駄目なら駄目で最初からまともに動かない方が対応しやすい
ログやメッセージはあった方が良い
権限毎のアクセス制御は厄介
インストールメッセージはよく読む

Melog