We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
最近この問題点に遭ってしまったのでご報告いたします。 仮に順にS0~S3の4つのチューナーがあります。 そして番組Aを2つ重複予約して、予約1をチューナー自動割り当てに指定、予約2をS1に強制指定します。 そしてS0のオープンが失敗する場合は、S1から2つのTSを出力することになります。
もしこの時にS1で何かドロップが発生する場合はまったく重複録画する意味(冗長性の確保?)がないので、 こういう形ではなく、S1とS2からそれぞれ1つのTSを出力する仕様に変えていただけますでしょうか。 つまり、チューナーがすでに同じ予約を入っているならチューナー候補リストから外す。
The text was updated successfully, but these errors were encountered:
EDCB的にはそもそも重複予約というものを想定していないように思います。 対応する場合は、自動予約登録のふるまいなど含めて、重複予約として正攻法で機能追加したほうが良いように思っています。
ただ、件の問題点については考え方による気がします。 例えば、S0の色々なトラブルに備えてS1も確保したのだから、(場合により他の予約をキャンセルする可能性もある)S2以降をさらに使うのは過剰な保険ではないか、などです。 また、予約2をS1ではなくS2に強制指定すればよいのではないか、とも思います。
Sorry, something went wrong.
ご返信ありがとうございます。修正する形を取るか新機能を追加する形を取るかはどっちでも構いません。 現在は一応臨時措置として二つとも「自動」に指定しています。
追記 二つとも「自動」にすると結局S0から2つのTSを出力することになる
No branches or pull requests
最近この問題点に遭ってしまったのでご報告いたします。
仮に順にS0~S3の4つのチューナーがあります。
そして番組Aを2つ重複予約して、予約1をチューナー自動割り当てに指定、予約2をS1に強制指定します。
そしてS0のオープンが失敗する場合は、S1から2つのTSを出力することになります。
もしこの時にS1で何かドロップが発生する場合はまったく重複録画する意味(冗長性の確保?)がないので、
こういう形ではなく、S1とS2からそれぞれ1つのTSを出力する仕様に変えていただけますでしょうか。
つまり、チューナーがすでに同じ予約を入っているならチューナー候補リストから外す。
The text was updated successfully, but these errors were encountered: