物理カードリーダー利用時のみ、CS でドロップする

[tsukumijima]

以前からの課題ですが、知らずに嵌まる人がいないとも限らないので Issue にあげておく…

https://twitter.com/TVRemotePlus/status/1753803412276478072

[tsukumijima]

v1.2.2 でもしかすると直っているかも・・・？
→ 調べてみたけどやっぱ直ってなさそう

[daisukekoba]

Rustに詳しくないので的外れかもしれませんが、
非同期I/Oの futures_util::io を tokio::io とか async-std::io へ変更すると高速化しませんか？

[kounoike]

デコードの処理速度の違いが関係あるということで、

kounoike@0996bdd

こんな感じでInnerDecoderのwriteの中のunsafeブロックの時間を取ってみたところ、地上波の場合でたいていは100usで終わるところがたまに65ms程度かかることが分かりました。

これを意図的にthread::sleepを入れて200ms程度になるよう（今のブランチではちょっと多めに250ms）にしてやると、地上波TSでもドロップが発生するのが確認できました。
CSのときに200msくらいかかるのかどうかは未確認ですが、もしそうだとしたらこのように意図的にsleepを入れておくことで問題に近い状況の再現が出来ると思います。

もし想定通りなら、writeが200msくらいかかってしまうので、チューナーデバイスから読む間隔も200ms以上開いて、ドライバ側のバッファとかが循環してパケットドロップになる、ということが起こっているのだと思います。
そうなると解決方法は何らかの手段でwriteが200msかかってもブロックせずに非同期で読み込み側の処理が回るような仕組みにすること、ですかね。例えばデコード処理を別スレッドに追い出すとか。

この方針でもうちょっと追いかけてみようと思います。

[kazuki0824]

ありがとうございます！！！
方針立てようにも難しく、手が出せずにいました...大変助かります。

[kounoike]

試しに👆の模擬再現したコードに加えて、ここを

inner: BufReader::with_capacity(204800usize, AllowStdIo::new(f)),

と書き換えてみたらドロップ出なくなりました（数値は適当に決めたので根拠ないです）。
某所でも書きましたが、CSが48Mbps（？）とすると65m詰まると400KBくらい流れていくので、8192Bじゃ全然足りずに消え去ってしまうということのようですね。

ちゃんとリリースするならコマンドライン引数辺りから渡せるようにすると良さそうですね

[Ukenn2112]

@kazuki0824 お疲れ様です。

最新の1.3.0版本を使用している際に、同じCSドロップの問題に遭遇しました。PR #147 で追加された環境変数機能を試してみましたが：

1. 環境変数でのテスト：RECISDB_INPUT_BUF_BYTES=2000000（デフォルト値の10倍）に設定しましたが、問題は解決されませんでした
2. ソースコード修正でのテスト：デフォルトのバッファサイズを直接修正して再ビルドしましたが、やはり問題が残っています

他に何か解決策やご提案はありますでしょうか？

よろしくお願いいたします。