[質問] バッファーあふれに関連する実装上の質問 about mirakurun

[kanreisa]

こんばんは！

TSFilter._writeでhighWaterMarkを超えるとcallbackを呼び出さない
関連性の確認は出来ていませんが

恐れ入りますが、現状問題を把握していませんので、ご確認いただけますでしょうか？
ちなみに、タイムアウトすると以下が実行されます。

1. Mirakurun/src/Mirakurun/TSFilter.ts

   Line 214 in 6d68cb9

   this._close();

2. Mirakurun/src/Mirakurun/TSFilter.ts

   Line 754 in 6d68cb9

   this.emit("close");

3. Mirakurun/src/Mirakurun/Tuner.ts

   Line 422 in 6d68cb9

   tsFilter.once("close", () => decoder.stdin.end());

また、callback を呼び出していない件の理由はよく覚えていませんので、
わざと overflow させてみて、正常に動くようでしたらマージできます。

Program. findByNetworkIdAndReplaceが非同期処理になっていない

この機能のためだけに実装され、1箇所からのみコールされているメソッドですので、重要度がさほど高くなく、実装漏れというか適当やった結果なんだと思います。 async 無意味になっていますね。今気づきました。

良い感じに非同期にしてくださるのであれば非常にありがたいです。

Tuner. _getStreamでのasync common.sleep(1000)の意図

await common.sleep(1000); のことですね。

この sleep(1000) の意図は TunerDevice#getRemotePrograms() を連続で実行してしまうと、リモートの Mirakurun に一定の負荷がかかってしまうため、わざと間隔をあけているものです。長時間のブロックの件はそこまで遅い計算機を想定していなかったので特に考えていませんでした。

[masnagam]

おはようございます．
回答ありがとうございます．

タイムアウトすると以下が実行されます

私もここでcloseが送られてdecodeプロセス（arib-b25-stream-testを使っています）が終了すると考えていたのですが，なぜか終了せず残り続けるという現象に遭遇しました．

同じ問題に遭遇する人が他にもいるかも知れませんので，以下に構成を記述しておきます．

• epgstation (rock64 machine1)
  • version: 1.4.8 (master HEADを使用)
• mirakurun-master + arib-b25-stream-test (rock64 machine2)
  • version: 2.10.1 (master HEADを使用)
• mirakurun-remote + tuner device (rock64 machine3)
  • version: 2.10.1 (master HEADを使用)
  • GR/BSのみ

os/node/mpnはすべて同じで以下の通りです．

• os: armbian stretch (4.4.174-rockchip64)
• nodejs: v10.15.3
• npm: 6.4.1

すべてDockerコンテナとして実行しています．

 Version:           18.09.5
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        e8ff056
 Built:             Thu Apr 11 04:47:02 2019
 OS/Arch:           linux/arm64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.5
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.8
  Git commit:       e8ff056
  Built:            Thu Apr 11 04:11:17 2019
  OS/Arch:          linux/arm64
  Experimental:     false

mirakurun-masterでバッファーがあふれたときに，arib-b25-stream-testが残り続けます．まだ解析前なので詳細不明ですが，このelseブロックで期待しているイベントが何らかの理由で発生しないものと推測されます．

わざと overflow させてみて、正常に動くようでしたらマージできます。

了解しましました．試してみて意味ある修正であった場合は，PRを作成します．

良い感じに非同期にしてくださるのであれば非常にありがたいです。

配列のイテレーションを適当な長さで分割し非同期処理するようなライブラリなどがあった記憶がありますので，修正を検討してみます．

ブロッキングで実行していた処理を非同期にする場合，同時に動く可能性のある処理について確認が必要になりますので，わからないことが出てきたら，また質問させていただきます．

リモートの Mirakurun に一定の負荷がかかってしまうため、わざと間隔をあけているものです

Rock64+Docker環境で計測したので載せておきます．

$ curl -s http://mirakurun-remote:40772/api/programs?networkId=4 | jq .[].id | wc -l
    3980

$ curl -s http://mirakurun-remote:40772/api/programs?networkId=4 -o /dev/null -w '%{size_download}\n'
2406117  # 約2.4M

$ curl -s http://mirakurun-remote:40772/api/programs?networkId=4 -o /dev/null -w '%{time_starttransfer}\n'
0.596560  # 600ms程度．ばらつきがあるので，一番遅かった時間

ARIBを読んだことがないので間違った意見かもしれませんが，Network IDでプログラムを集めるのではなく，Service IDでプログラムを集めれば数が少なくなり，リクエストごとの負荷が下がる気がします．ただし，saveの回数が増えるので，mirakurun-masterの応答性は下がるかもしれません．

$ curl -s http://mirakurun-remote:40772/api/programs?serviceId=101 | jq .[].id | wc -l
     293

$ curl -s http://mirakurun-remote:40772/api/programs?serviceId=101 -o /dev/null -w '%{size_download}\n'
258249  # 約250K

$ curl -s http://mirakurun-remote:40772/api/programs?serviceId=101 -o /dev/null -w '%{time_starttransfer}\n'
0.442761  # 440ms程度．一番遅かった時間．全プログラムをサーチするのであまり減らないようです．．．

serviceIdはユニークみたいでした．

$ curl -sSL http://mirakurun-remote:40772/api/channels | jq .[].services[].serviceId | wc -l
      46

$ curl -sSL http://mirakurun-remote:40772/api/channels | jq .[].services[].serviceId | uniq | wc -l
      46

[masnagam]

arib-b25-stream-testが残る問題は再現条件が判明した時点で別途PRを送ります．

現時点でわかっていることは

• decoder.stdinでfinishイベントが起こらず，decoder.kill("SIGKILL")が呼び出されない
• Nodejsのドキュメントによると，stdinにデータが残っているとend()を呼び出してもfinishが発生しない

ひとまず，こちらの質問は閉じます．