Opened 20 years ago
Closed 17 years ago
#255 closed patch (wontfix)
Improved scheduling of consecutive programs with pre-roll/overrecord
Reported by: | Owned by: | gigem | |
---|---|---|---|
Priority: | minor | Milestone: | unknown |
Component: | mythtv | Version: | head |
Severity: | medium | Keywords: | |
Cc: | garfield_99999@…, Paul.Hampson@… | Ticket locked: | no |
Description
Hello devs,
Attached is a patch to improve MythTV's scheduling of consecutive programs. It's meant to help users in areas where TV stations tend not to broadcast shows at the advertised time (e.g. Australians), and who try to compensate for this with the global overrecord setting.
Current Behavior
When consecutive programs are scheduled, Myth will default them both to the same tuner and ignore the global pre-roll and/or overrecord settings -- even if a second (or subsequent) tuner sits idle.
This is problematic for users in areas where TV stations tend not to broadcast programs at their advertised time, as ignoring the overrecord usually means missing the end of the show. At present, such users need to manually extend the end time of every single recording, which is annoying and occasionally leads to creating unintended scheduling conflicts.
After Patch
Myth will attempt to honour the global pre-roll and overrecord settings by switching a program to a different card or showing, if this can be done without disrupting anything else.
Myth's behaviour is unaltered except when:
(a) there are scheduled programs that do not conflict, but are too close together to allow the pre-roll and overrecord settings to be honoured;
and
(b) one or more of these programs has an alternative showing available (e.g. free tuner card or other broadcast time) that could be recorded in full, including pre-roll and overrecord.
Please note that this means the patch does not alter MythTV's behaviour at all unless the user has set a positive pre-roll or overrecord.
Issues
If a user goes into Utilities/Setup -> Setup -> TV Settings -> General and changes his global pre-roll or overrecord setting, it'd be nice for a reschedule to be triggered. But I haven't coded this (because I have no idea how to). So if you turn pre-roll/overrecord on or off, it doesn't have any effect until the next reschedule (i.e. mythbackend restarts or a new program is recorded/scheduled).
Max.
Attachments (5)
Change History (21)
by , 20 years ago
Attachment: | smarter-scheduling.diff added |
---|
comment:1 by , 20 years ago
Owner: | changed from | to
---|
comment:2 by , 20 years ago
As requested by David, I've modified the patch to include a setting with which to control its behaviour.
In "Utilities/Setup" -> "Setup" -> "TV Settings" -> "General" there is now a dedicated OverTime page. A new setting on this page asks when the user would like MythTV to apply the OverTime buffers. Options are:
0) [Default] Apply unless it would create a conflict, require the use of an additional tuner card, or require MythTV to record an earlier or later showing. In other words, ignore pre-roll and overrecord unless they can be honoured without affecting anything else. This is MythTV's current behavior.
1) Apply unless it would create a conflict or require the use of an idle tuner. MythTV will, however, select an earlier/later showing if this enables it to honour the OverTime settings.
2) Apply unless it would create a conflict. MythTV will, however, assign programs to idle tuner cards or record earlier/later showings if this is necessary to capture the pre-roll/overrecord. [IMHO this should be MythTV's new default behaviour.]
3) Apply always. This turns OverTime into a hard setting, which MythTV will always obey even if this means creating a conflict.
Hopefully this makes everyone happy, by allowing users to employ the OverTime setting in whichever way works best for them.
Thanks to David for taking the time to discuss the issues with me and provide guidance!
Max.
comment:3 by , 20 years ago
Shouldn't there be an additional option - "Apply unless it would cause a conflict or require MythTV to record an earlier or later showing" - for people who don't mind tying up all their tuners briefly (e.g. because they don't use LiveTV mode anyway, all their tuners are equally good, etc) but don't want their recordings delayed?
comment:4 by , 20 years ago
I agree with anonymous (from Sep 24)'s comments. There should be another option, "Apply unless conflict or other showing.". That way every option would be covered. Some people don't mind using any tuner, but they don't want a later showing (sometimes the next showing is several days away).
comment:6 by , 20 years ago
Cc: | added |
---|
comment:7 by , 20 years ago
Milestone: | → 0.20 |
---|
comment:8 by , 20 years ago
Milestone: | 0.20 → unknown |
---|---|
Version: | head → 0.19 |
comment:9 by , 20 years ago
Milestone: | unknown → 0.20 |
---|---|
Version: | 0.19 → head |
comment:10 by , 20 years ago
Milestone: | 0.20 → unknown |
---|
Unless you're a Myth developer, please don't change milestone and version fields. If you are a Myth developer, please login before doing so.
comment:11 by , 19 years ago
I may be completely missing the point but isn't the original reason for this bug is to handle consecutive programs on stations that don't stick to the schedules?
I think it would be more efficient to have the recordings coalesed into one recording task and have that task record to the output files according to the individual schedules. This is probably a major change to the way recording works and during the overlap twice as much disk writing would be happening but it would only require one tuner.
Cheers, Tim.
comment:12 by , 19 years ago
Actually, the point is to allow the use of global pre-roll and overrecord settings to optionally select a different showing or use another tuner to meet the pre-roll/overrecord values requested.
I'm attaching a compile-tested forward port of smarter-scheduling.2.diff to 0.20, I'll be testing it over the next week or so.
by , 19 years ago
Attachment: | smarter-scheduling.2.020rediff.diff added |
---|
Rediff of smarter-schduling.2.diff against 0.20
comment:13 by , 19 years ago
Cc: | added |
---|
Hmm. Just realised that the patch doesn't update mythtv-setup, it still shows the pre-roll/overrecord values on the General(Advanced) page... That ought to be trivial to fix...
Once this is functionality-tested, I'll see about fixing that and posting a new patch.
comment:14 by , 19 years ago
There has been a softpad branch for a while that works pretty well. Unfortunately, as noted by David Engel in his mailing list post, it looks like will not be merged into trunk.
It would be nice however if some of the simpler, but more conflicty, parts of the patch were merged into trunk. That would allow a normal svn up
to keep the scheduler up to date, because it doesn't change much. The (simple) parts that do change, the myth protocol, would be kept up to do date in trunk, but unused by most people.
I'll attach a patch that just makes the programinfo and myth protocol changes. I trimmed my normal diff back to do this (and I'm not entirely confident of the mythweb part). It would be great if this could be applied.
by , 19 years ago
Attachment: | soft-sched-frame.diff added |
---|
A patch that implements the protocol changes of the softpad branch without the scheduler changes.
comment:15 by , 19 years ago
The mythweb part of that last patch was broken. I'll attach a new patch for just that part.
by , 19 years ago
Attachment: | mythweb-softproto.diff added |
---|
comment:16 by , 17 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Doesn't apply to trunk, will not be applied in current form.
Patch against r7110