Repository navigation
fix(dvr): start a recording's write rate watch from the channel's best window - #624
Merged
Merged
Conversation
…t window The rate watchdog's clean runs on 10-31 kept 73% and then 56% of a 20 minute window: in the second, the recording's first read ran 8.9 minutes at 80 KB/s on a 326 KB/s stream, and a first read slow from its first byte has no earlier window in its own recording to show it up. The recorder now remembers each channel's best window while the server runs and starts the channel's next recording from it. A recording of a channel the server has not recorded since it started is unprotected for its first read.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The rate watchdog (#622, #623) kept 73% of a 20-minute window in its first clean run on the live server and 56% in the repeat (10-31, VH1). In the repeat, the recording's first read ran 8.9 minutes at 80 KB/s on a 326 KB/s stream and ended on its own: a first read slow from its first byte has no earlier window in its own recording to show it up. The recorder now remembers each channel's best write window while the server runs and starts the channel's next recording from it (
WriteRate(initialPeak = ...)).Limits: the memory is lost on restart, so a channel's first recording after one is unprotected for its first read; and a stream whose bitrate legitimately drops to under a third of an earlier recording's best would be reopened once. Four runs so far read 61%, 65%, 73% and 56%, so the gain needs repeating at other hours before it counts as a rate.
Testing Performed: new
WriteRateTestcase (80 KB/s from the start is slowed against a remembered 326 KB/s window, and is not with no history);spotlessCheck detekt,WriteRateTestandRecorderLapseTestpass locally.