Opened 19 years ago
Closed 19 years ago
#2459 closed defect (wontfix)
Mythcommflag catches up to 10 +- 2 seconds behind recording
Reported by: | Owned by: | cpinkham | |
---|---|---|---|
Priority: | minor | Milestone: | unknown |
Component: | mythtv | Version: | 0.20 |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
When running in real time catch up to about 10 seconds behind the recorder. This hopefully uses the disk buffer earlier which can be freed earlier.
Also widens the difference between changing usecSleep, which may smooth the processor demands.
Attachments (1)
Change History (2)
Changed 19 years ago by
Attachment: | commflag-catchup.patch added |
---|
comment:1 Changed 19 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
We've tried reducing the requiredBuffer down before and a bunch of users have had problems. It would be nice to put this down below the 30 seconds we use currently, but doesn't work as a general use case. See the following changelogs where we bumped it down then had to bring it right back up. [9237]. [9265], and [10167].
For the +- 2 seconds mod. With your mod, we would run 'slow' for 5 seconds, then run 'fast' for 5 seconds. So you spread the 'waves' out. With existing code we run 'slow' or 'fast' for a max of one second and then switch, so our overall cpu usage over a 10 second period is more consistent rather than having 5 seconds fast and 5 slow, we're more evened out. I'm not sure I like this part because of this. If you want to discuss, mention it on the -dev list and we can talk about it.
Going to close this ticket for now, but may reopen in the future if my logic above is flawed.
Patch