Opened 18 years ago
Closed 14 years ago
#1791 closed patch (Won't Fix)
Stop transcode/commflag from hogging the CPU while recording/playback is in progress.
| Reported by: | Owned by: | cpinkham | |
|---|---|---|---|
| Priority: | minor | Milestone: | unknown |
| Component: | MythTV - Mythcommflag | Version: | head |
| Severity: | medium | Keywords: | |
| Cc: | Ticket locked: | no |
Description
When two consecutive programs are scheduled to be recorded, back to back, after the first recording finishes, the backend begins recording the second program. Meanwhile, commflag begins scanning the first recording, pegging the CPU and making a general mess of the second recording.
The following patch causes mythtranscode and mythcommflag to wait if something is being recorded or played back. This patch makes myth much more usable on less-than-blazing fast hardware.
Attachments (4)
Change History (16)
Changed 18 years ago by
| Attachment: | mythtv-0.19.jobhibernate.patch.txt added |
|---|
comment:1 Changed 18 years ago by
| Owner: | changed from Isaac Richards to cpinkham |
|---|
comment:2 Changed 18 years ago by
| Milestone: | → 0.21 |
|---|
With the JobQueue? CPU usage setting set to LOW, the commercial flagging shouldn't be hogging all the CPU. Even though this is the case, I still have considered adding a feature like this. I'm pushing this off till 0.21 so I can figure out if this is how I'd like to implement it or how it might integrate with some other changes I have planned.
comment:3 Changed 18 years ago by
| Type: | enhancement → patch |
|---|
comment:4 Changed 18 years ago by
| Version: | → head |
|---|
comment:5 Changed 18 years ago by
FWIW, I believe I've succesfully updated the patch against mythtv-0.20 release, and after a few hours of banging at it, it appears to be working.
I'm uploading the revised patch in two parts. They're not really independent, both parts need to be applied against 0.20 release.
The revised 0.20 patch also puts mythfilldatabase on hold if something is being played or recorded.
In the future, as time permits, I hope to clean up this patch and chop it up into independent chunks.
Changed 18 years ago by
| Attachment: | mythtv-0.20.jobhibernate-filldatafix.patch.txt added |
|---|
0.20 patch, part II
comment:6 Changed 16 years ago by
| Milestone: | 0.21 → unknown |
|---|
comment:7 Changed 16 years ago by
I'm going to maintain this patch, for now. Ping this ticket whenever you decide to revisit this issue. The current version of the patch that I'm running now is actually much smaller, neater, and less invasive than my first version, and I look forward to working, in the future, to help Myth be functional on modest hardware.
Changed 16 years ago by
| Attachment: | mythtv-0.20.2.jobhibernate.patch.txt added |
|---|
New, refactored patch, against 0.20.2
comment:8 Changed 16 years ago by
I got some requests to see the refactored patch, here it is.
Only one hook is necessary: MSqlQuery::prepare -- everything that hits the database goes through here, it's a natural place to add a hook to check the job queue, and spin if somebody else is chewing a record (and provide a bypass for the users that update the job queue). Done.
comment:9 Changed 15 years ago by
| Status: | new → assigned |
|---|
comment:10 Changed 15 years ago by
| Component: | mythtv → MythTV - Mythcommflag |
|---|
comment:11 Changed 14 years ago by
Are we gonna keep this one around? If so, maybe the patch should be rebased off 0.23-ish so cpinkham will have something recent to look at...
comment:12 Changed 14 years ago by
| Resolution: | → Won't Fix |
|---|---|
| Status: | assigned → closed |
Going to close this as a "won't fix" for now. I think there are better ways to do this and any solution will need to be cross-platform on at least Linux, Windows, and OS/X before being considered. Feel free to discuss this on the -dev mailing list if someone wants to pick this up and discuss how we could accomplish this in the current version of MythTV.
Patch to myth 0.19