config.jsonのパラメータについて

[advancedbear]

お世話になっております。

ここ最近のIssues投稿を見たりしていると、そもそもコンフィグファイルの解説に用意されている doc/config.md では把握できていない利用者も増えてきたのではないかなと感じます。 そこで、（余計なお節介かも知れませんが）逆引きマニュアルを作成中です。

改めて用途別にconfig.json用のパラメータを整理したりしている中で、用途が分からないパラメータが幾つかあったのでまとめて質問させていただきます。

1. readOnlyOnce config.json の読み込みを1度だけに制限するとありますが、デフォルト値がfalseということはデフォルトではconfig.jsonは事あるごとにリロードされているということでしょうか。
2. gid, uid このgid/uidはEPGStationが実行されるgid/uidではないですよね。EPGStationが作成するファイル群（録画ファイル、ログ、jsonなど）のオーナー権限に適用されるということでしょうか。
3. subDirectory 元のマニュアルにサブディレクトリとしか書かれておらず本格的に意味不明なのですが、どの場合に参照されるサブディレクトリでしょうか
4. recordedHistoryRetentionPeriodDays ルール予約時の番組名とは具体的に何でしょうか。ルール予約時の録画済みファイルの重複排除に利用される、すでに録画された番組名のことでしょうか。
5. maxStreaming, streamingPriority デフォルト値には0が指定されていますが、この場合はmaxStreamingではチューナーと同じ数、streamingPriorityではrecPriorityと同じ値が指定されるという認識でよろしいでしょうか。

畳み掛けるようで申し訳ありませんが、ぜひご回答をよろしくお願いします。

[l3tnun]

（ 余計なお節介かも知れませんが）逆引きマニュアルを作成中です。

いえいえ、ありがとうございます。現状非常に分かりにくいため助かります。

• readOnlyOnce

config.jsonは事あるごとにリロードされているということでしょうか。

そのとおりです。そのため config.json の読み込み回数を抑えるために用意したオプションとなります。 encode, mpegTsStreaming, recordedViewer など一部の項目は書き換えるたびに EPGStation を再起動する事は不便なのでそのような仕様になっています。 ただし、serverPort や mirakurunPath 等起動後に変更があっても反映されない項目もあります。 エンコード等の設定が煮詰まったら readOnlyOnce を true にして config.json の無駄な読み込みを抑えるといった使用方法を想定しています。

• gid, uid

このgid/uidはEPGStationが実行されるgid/uidではないですよね。

root ユーザで EPGStation を起動し、これらの値がセットされていた場合は EPGStation の gid, uid をその値へ変更します。 これは主に pm2 で起動する場合のことを考えて設定されています。 通常 Linux 環境で Mirakurun をインストールした場合、pm2 の起動は root ユーザになっているため Mirakurun 等の pm2 に登録されたアプリは root 権限で起動します。 このような状態の pm2 に EPGStation を登録した場合 root 権限で起動するようになりますが、指定した uid, gid で実行できるようにするため用意されたオプションとなっています。 Chinachu でも同じオプションが存在していて pm2 で起動後 uid, gid が指定値に変更されます。 また、プロセスの uid, gid が変更になるので EPGStation で生成されるファイルの権限もそれに基づいたものになります。

• subDirectory

これはリバースプロキシを使用してサブディレクトリ下で EPGStation 公開することを想定し用意されたオプションです。 通常 EPGStation にアクセスする URL は http://<host-ip>:port/ となりますが、subDirectory を以下のように設定した場合

"subDirectory": "hoge",

EPGStation にアクセスする URL は以下のように変わります。

http://<host-ip>:port/hoge/

リバースプロキシを使用しサブディレクトリ下で公開する場合に EPGStation 側でサブディレクトリが把握できないと正常に処理できないためこのようなオプションが用意されることになりました。 ただし、私個人として認証等を設定せずに EPGStation を可動させたサーバを外部に公開することを推奨するものではないです。

• recordedHistoryRetentionPeriodDays

ルール予約時の番組名とは具体的に何でしょうか。

番組表や予約等で表示される番組タイトルですね。 ルール予約で録画した番組の番組タイトルを recordedHistoryRetentionPeriodDays で指定した期間データベース上に記録しておきます。

• maxStreaming, streamingPriority

デフォルト値には0が指定されていますが、この場合はmaxStreamingではチューナーと同じ数、streamingPriorityではrecPriorityと同じ値が指定されるという認識でよろしいでしょうか。

いえ、両方 0 となります。そのため、maxStreaming の記述がされていない or 0 の場合はライブ視聴等は動きません。 streamingPriority は recPriority, conflictPriority を上回らないよう 0 に設定されています。

こんなところでしょうか。 他にもなにか分かりにくい箇所があれば教えてください。

[advancedbear]

ルール予約で録画した番組の番組タイトルを recordedHistoryRetentionPeriodDays で指定した期間データベース上に記録しておきます。

これは、データベース上のrecordedhistoryテーブル内に保存される情報ですよね。 該当テーブルの利用用途がいまいち分からないのですが、これは番組表や予約一覧でどのように利用されるのでしょうか。 テーブル内には1から始まるユニークな連番、番組名、番組終了時刻だけが記載されていますが、このデータはどこかで参照されるものなんでしょうか。 そして、期限が超過するとどのような点で変化が発生するのでしょう。

追加の質問になりますがconflictPriorityが適用されるのはどのような場合でしょうか。 例えば、0:00開始の番組が2番組ある場合、recPriorityとconflictPriorityのどちらになるかはProgramID順でしょうか？ また、デフォルト値ではrecPriority < conflictPriorityとなっていますが、この場合後から始まる番組が優先度上になり、チューナー数上限だった場合は先に始まった番組のチューナーを奪うという認識で合っているでしょうか。 そのような場合、1チューナーで①0:00～0:30、②0:10～0:40、③0:15～0:30というような録画予約時には①にrecPriorityが、②と③にconflictPriorityが割り当てられるのでしょうか。 すると②と③はpriorityが同じ値になるかと思いますが、動作としてはどのようになるのでしょうか。

[advancedbear]

すみません、更に追加なのですが、パス名を指定するタイプのオプションにおいて

フルパスで指定する

という表記があるものと無いものとありますが、基本的には全てフルパスで指定するべきでしょうか？ 例えば、EPGStationフォルダ下に新規フォルダを作成して配置する場合などは相対パスで

"thumbnail": "./thumbs"

というようなことをしても大丈夫なんでしょうか？

[l3tnun]

これは、データベース上のrecordedhistoryテーブル内に保存される情報ですよね。

そのとおりです。これは #102 のために追加されたテーブルとなっています。 version 0.9.9 からルール追加時のオプションに 重複 が追加されていて、その中の 録画済み番組を排除 にチェックを入れ日数を指定すると有効化されます。 (日数を 0 に設定すると期間なしとなります)

肝心の利用用途ですが先程の重複オプションが有効な場合、ルール予約は以下のように更新されます。

1. ルール条件に基づき該当する番組を検索
2. 1 で検索された番組のなかに RecordedHistory テーブル上に記録された番組タイトルと同じ番組名が存在するかチェックする
3. 同じ番組名が存在した場合、その番組は重複したものとみなし録画しない

この画像の中の色が灰色で番組情報が取り消し線で表示されている番組が重複した番組です。 7/19 に 所さん!大変ですよ「お城が大ピンチ 消える!?壊れる!?」[字] という番組が録画されたので重複したものであると判定されています。

期限が超過するとどのような点で変化が発生するのでしょう。

期限が超過すると RecordedHistory テーブル上から消えます。

---

追加の質問になりますがconflictPriorityが適用されるのはどのような場合でしょうか。

番組が競合した場合適応されます。

この画像のような背景が黄色で赤の点線で囲われたチューナーが不足している場合に適応されます。

0:00開始の番組が2番組ある場合、recPriorityとconflictPriorityのどちらになるかはProgramID順でしょうか？

使用可能チューナが 1 つ、2 つの番組を番組 A, 番組 B とし、それぞれルール A (ruleId = 1), ルール B (ruleId = 2) によって予約されたものと仮定します。 この場合はルール A, ルール Bの ruleId が小さい方を優先的に予約するため、番組 A が通常の予約、番組 B が競合した予約として処理されます。 実際にその時刻になったときは番組 A を recPriority で、番組 B を conflictPriority で録画します。 Mirakurun 側で優先度の低い番組 B の録画は弾かれ番組 A だけが予約されます。

手動予約の場合では手動予約実行時の時刻を元に優先度を決定しています。 つまり 番組 A が 番組 B よりも早く予約されていれば番組 A を優先します。 通常の場合番組 A -> 番組 B と予約する時チューナーが不足していることが予約前にわかるため番組 B は予約エラーになります。 終了時刻が延長されたり、programId が同じまま別の時間帯に移動したりしない限り手動予約で競合は発生しないはずです。

あと、手動予約とルール予約が競合された場合は手動予約が優先されます。

デフォルト値ではrecPriority < conflictPriorityとなっていますが

いえ、recPriority が 2, conflictPriority が 1 なので逆です。

そのような場合、1チューナーで①0:00～0:30、②0:10～0:40、③0:15～0:30というような録画予約時には①にrecPriorityが、②と③にconflictPriorityが割り当てられるのでしょうか。

そのとおりです。

すると②と③はpriorityが同じ値になるかと思いますが、動作としてはどのようになるのでしょうか。

② 開始時に Mirakurun にストリームを要求しますがチューナーの空きが無いためエラーが帰ってきて何も録画されません。③ も同様です。

---

基本的には全てフルパスで指定するべきでしょうか？

はい、混乱を避けるため基本的にはすべてフルパスでするべきですね。 相対パスで記述しても動く場合もあると思いますが、そのことを想定していないため正常に動作するかは保証しません。

[advancedbear]

録画済み番組を排除 にチェックを入れ日数を指定すると有効化されます。

ということは、

• recordedHistoryRetentionPeriodDaysはデータベースに保管する期間
• Webインターフェイス上の日数項目はデータベースと比較して一致したと判断する期間

という認識であっていますでしょうか。

---

ちなみになのですが、recordedHistoryRetentionPeriodDaysのデフォルト値は30日のようですが、値を未設定にしている私の環境では

MySQL [epgstation]> select id,name,from_unixtime(endAt/1000) as endAt from recordedhistory where id < 4 or id > 65;
+----+----------------------------------------------------+--------------------------+
| id | name                                               | endAt                    |
+----+----------------------------------------------------+--------------------------+
|  1 | はねバド!第1話「スッゴい才能!」                    | 2018-07-02 00:30:00.0000 |
|  2 | 劇場版「進撃の巨人」前編~紅蓮の弓矢~               | 2018-07-02 02:35:00.0000 |
|  3 | ヤマノススメ サードシーズン#1「筑波山で初デート?」 | 2018-07-03 02:45:00.0000 |
| 66 | ハイスコアガール ROUND2                            | 2018-07-21 01:00:00.0000 |
| 67 | 京都寺町三条のホームズ 第二話『葵の頃に』          | 2018-07-21 01:43:00.0000 |
| 68 | ちおちゃんの通学路 「第3話:カバディー・フォー」    | 2018-07-21 01:50:00.0000 |
| 69 | ルパン三世 PART5 #15                               | 2018-07-21 02:29:00.0000 |
+----+----------------------------------------------------+--------------------------+
7 rows in set (0.00 sec)

といった感じで20日分しか確保されていないようなんですよね。 私自身はこの機能を利用していないので困っているわけではないのですが、今回確認していてふと気になったので一応ご報告を……。

[l3tnun]

• recordedHistoryRetentionPeriodDaysはデータベースに保管する期間
• Webインターフェイス上の日数項目はデータベースと比較して一致したと判断する期間

という認識であっていますでしょうか。

そのとおりです。

---

といった感じで20日分しか確保されていないようなんですよね。

version 0.9.9 以降にアップデート後にルール予約で録画されたものが順次記録される (それ以前に録画したものは反映されない) ため、その様になっているのだと思います。

[advancedbear]

version 0.9.9 以降にアップデート後にルール予約で録画されたものが順次記録される

あぁぁすみません、0.9.9のリリースからそもそもまだ30日経ってなかったんですね…。 合点がいきました、いろいろありがとうございました。

---

逆引きマニュアルは現時点で
EPGStation/conf-manual.md at document-improve · advancedbear/EPGStation
こんな感じになる見込みです。
もうちょっとスマートな作り方がアレば良いですが、Githubのマークダウンだとコレが限界な感じもしますね。

この他に、初期セットアップ時のOS別マニュアルなどを再編成したいなと思っています。
Readme.mdには

データベースの設定が済んでいれば mirakurunPath, ffmpeg, ffprobe の設定をすればとりあえず動きます

と記載がありますが、実際にはその下に記載されているlogの設定をしなければエラーを吐いて動作しませんし、そもそもDB作成に至ってはWindowsマニュアルには記載がありますがLinux向けには記載がないですし、そのあたりも含めて包括的なセットアップマニュアルを作りたいと思っています。

[l3tnun]

おお素晴らしいですね。 config.md が将来的に不要になりそうです。

と記載がありますが、実際にはその下に記載されているlogの設定をしなければエラーを吐いて動作しませんし

これは log の設定を先頭に移動させたほうがいいですね。あとで修正します。

そのあたりも含めて包括的なセットアップマニュアルを作りたいと思っています。

現状ある程度わかっている人向けに雑に書いてあるだけですので助かります。

[advancedbear]

まぁ、正直なところこの手のソフトウェアは

パーソナルコンピュータ上において、デジタル放送の視聴を行うプログラムの実装を研究する目的で頒布される研究資料です。 https://github.com/DBCTRADO/TVTest

的な決まり文句で「あくまで実験目的ですよ～」と断り書きを入れたうえで「理解ある人だけ使ってくださいね」というスタンスでいることが求められがちでもありますし、市販製品のように懇切丁寧なマニュアルを作るメリットがどこまであるかと言われると微妙なんですよね。

逆引きマニュアルに関しては、自分が欲しいと思ったから作っていますが、セットアップマニュアルに関しては「どの層をターゲットにするか」というのに悩ましさを感じています。

それこそ、AmazonやYahoo!ショッピングで、PLEX製チューナーに「使い方がわからない」と☆1を付けるようなユーザー層までターゲットにするのか、マニュアルなしでもSQLのクエリを書けるようなユーザー層をターゲットにするのか……。

その辺り、作者であるl3tnunさんの中でイメージがあれば教えていただきたいなと思っています。

[l3tnun]

ああ、それって難しい問題ですよね。

的な決まり文句で「あくまで実験目的ですよ～」と断り書きを入れたうえで「理解ある人だけ使ってくださいね」というスタンスでいることが求められがちでもありますし

Chinachu も Mirakurun もそのようなスタンスですね。著作権法のことがありますし、このようなスタンスになるのはほぼ必然ですからね。

私としてはまるっきりの初心者までは対象に含める必要はないと思います。上記のような建前を理解していない方も多いと思いますし、多少は DTV について理解がないと対応することも大変ですので。

Chinachu, EDCB, TVRock などの録画ソフトのセットアップ方法について色々な方々がブログの記事にしたりして公開されていますが、 間違っていたり記事が古くなっていたりするものも多く見受けられるので、公式でセットアップ方法方法を解説することはあってもいいかなと思います。 (まあ、チューナーはこれを買って、あれをこれをこのようにセットアップしてといった何から何まで全て解説する必要はありませんが。)

マニュアルを書くだけても大変だと思いますので、書くのであれば程々にといったところでしょうか。

[advancedbear]

こんばんは。 Readme.mdの編集という、一介のコミッターが手を出して良いのか微妙なラインの部分の編集に乗り出しているのですが、対応OSについて質問があります。

1. Windowsについて実験的の表記がありますが必要でしょうか 動作確認をしていないという意味かもしれませんが、私含めIssues内でも動作実績が結構ある気がしますが……

2. Mac OSは動作可能でしょうか 私自身Mac OSで動くデバイスを所持していないのですが、Mac OSで動作させる場合のインストール手順はLinuxと同様でしょうか？ Nodeさえ入ってしまえばnpmで呼び出してnodeを叩くだけなので同じ手順でも動きそうですが、Gatekeeper周りとかどうなっているのか不明なので……。 もっと言えば、こちらは実験的の表記がないですが動作確認済みということで良いのでしょうか？

よろしくお願いします。

[l3tnun]

1. Windowsについて実験的の表記がありますが必要でしょうか

一応必要だと考えています。 というのも私自身 Windows 環境で常用しているわけではないので動作の保証が出来ないこと、今後の変更で動作しなくなる可能性も有り得なくはないからですね。 MIT License なのでもともと無保証ですが、Windows の場合さらに注意が必要という意味合いもあります。

2. Mac OSは動作可能でしょうか

はい、動作します。 私の開発環境が基本 Mac であるため一番動作確認が取れている環境ですね。 インストール手順は Node, Python 2.7, GCC 等がインストール済みであれば Linux と同じです。 Gatekeeper 周りは特に問題ありません。 動作すると言っても対応チューナーが私が知る限り存在しないため、わざわざ動かす人はいないと思いますが。

[advancedbear]

動作の保証が出来ないこと、今後の変更で動作しなくなる可能性も有り得なくはない

こちらの点、承知しました。 現時点では動作確認をしているのはMacとLinuxのみで、Windowsは動くはずだというスタンスですね。

Macに関しては、あり得るパターンとしては激安SBCにチューナー挿してMirakurunだけ動かしておいて、ヘビーな録画管理ソフト類だけMacで……という感じでしょうか。 とりあえず、Linuxと同様ということで承知しました。

ログ周りについての質問なのですが、 OperatorはEPGStationの録画管理機能が能動的に実施した動作のログ、ServiceはEPGStationのWebGUI機能が受動的に実施した動作のログという認識で大丈夫でしょうか。 Operatorフォルダ内にもaccess.logとstream.logが生成されていますが、上記認識の場合（Webアクセスや配信を司るのはService側なので）これらは基本的に空ファイルになるかなと思うのですが合っていますでしょうか？

[l3tnun]

ログ周りの認識はそれで ok です。

[l3tnun]

修正後 master に反映したため閉じます