Opened 5 years ago

Closed 5 years ago

#12075 closed Bug Report - General (Works for me)

"Early Start"-Setting + Two Recordings on the same channel follow directly each other => first recording is aborted too early

Reported by: t.brackertz@… Owned by:
Priority: minor Milestone: unknown
Component: MythTV - Recording Version: 0.27-fixes
Severity: medium Keywords: schedule recording start early recording aborted
Cc: Ticket locked: no

Description

If "Start Early" and "End Late" are for example set to 300s the following happens:

There are 3 scenarios: 1) Schedule a recording on channel A from 5 pm to 6 pm. Mythtv records channel A from 4.55 pm to 6.05 pm. - fine

2) Schedule a recording on channel A from 5pm to 6pm and another on channel B from 6 pm to 7pm. If you have two tuners available Mythtv records channel A from 4.55 pm to 6.05 pm and channel B from 5.55pm to 7.05 pm. If there is only one tuner available Mythtv records channel A from 4.55 pm to 6 pm and channel B from 6pm to 7.05 pm. - also fine

3) Schedule a recording on channel A from 5pm to 6pm and another recording also on channel A from 6 pm to 7 pm. Mythtv records channel A from 4.55 pm to 5.55 pm and from 5.55 pm to 7.05 pm. The first recording is aborted 5 minutes too early and the end of the first broadcast gets part of the second one. This also happens if there are some additional tuners free; only one tuner is used.

I suppose the following: In the third scenario the scheduling mechanism recognizes that both shows are on the same channel and applies the "Start Early"-setting (whereas in scenario 2 this setting is ignored by the scheduling mechanism). Hence it plans to record one show on channel A from 4.55 pm to 6.05 pm and the other show also at channel A from 5.55 pm to 7.05 pm. But the recording-mechanism isn't able to do that but aborts the first recording when starting the second.

Maybe https://code.mythtv.org/trac/ticket/12023 is related.

Change History (5)

comment:1 Changed 5 years ago by t.brackertz@…

MythTV-Version: 0.27/fixes

comment:2 Changed 5 years ago by Karl Egly

Resolution: Invalid
Status: newclosed
Version: Unspecified0.27-fixes

I think this is in part a duplicate of #12023, too.

Please set your recording rule to start 5 minutes early and end 5 minute late instead of using 300s early/late. The settings in seconds are for hardware bring up, like switching to the correct STB, turning a dish or antenna, etc.

For your case 3 there is a setting to avoid back-to-back recordings on the same recorder.

Your suggestion involves extending the code to support writing to two overlapping recordings from one recorder at the same time. While this would be appreciable someone has to add code for that new feature. I'm closing this ticket as feature request without a patch.

comment:3 Changed 5 years ago by t.brackertz@…

Resolution: Invalid
Status: closednew

Nevertheless if one uses the "start early"-feature to give time to the hardware or to compensate inexact broadcast-times the behaviour in scenario 3 is not desired.

Writing to two overlapping recordings from one recorder would fix the issue best. Another solution would be to change the scheduler to behave as in scenario *2*. Especially as in scenario 3 the hardware doesn't need additional time between the shows - in contrast to scenario 2.

Using the "prevent back-to-back recordings"-option is only a workaround if there are unused tuners.

Using recording rules is even worse in those situations as this cuases "hard paddings" i.e. one of the shows isn't recorded at all.

Last edited 5 years ago by Karl Egly (previous) (diff)

comment:4 Changed 5 years ago by Karl Egly

Now I'm with you. The 300s pre-roll of the second recording should not cut into the regular time of the first recording. Though, I don't think the workarounds are so bad in the days of DVB cards where you can enable additional virtual tuners.

PS: I replaced you comment:3 with the text from comment:4 (now deleted) to keep the ticket readable.

comment:5 Changed 5 years ago by gigem

Resolution: Works for me
Status: newclosed

I tested this multiple times today and it works exactly as expected, that is, as you describe in scenario 2. This feature is widely used and abused, so much so, that if it was as broken as you describe, many other people would be complaining too. I suspect you have something mis-configured on you system or you are doing something else you forgot or didn't know to mention. If you still feel there is a bug, you'll need to provide many more details to help someone else reproduce the problem.

Note: See TracTickets for help on using tickets.