Can't record back-to-back

Beta Community DVR Beta
#1

This is probably the biggest actual issue I’ve found with the DVR, after spending some quality time with it.

The simplest version of this issue is this. Suppose I have one tuner available (say I have a Connect, and one tuner is being used for live TV). If I record two shows:

2:30 - 3:00pm (30 min), channel 12.1 - Show A
3:00 - 3:30pm (30 min), channel 12.1 - Show B

At 3:00, the second recording will fail to start, with an error like

2017/01/21 15:00:00 [ERR] Failed to start stream on channel 12.1 via 10484E44: got http response code 503
2017/01/21 15:00:00 [DVR] Error running job 1485036000-ch12.1: could not start stream on channels=[12.1]: got http response code 503

Then, 30 seconds later, it will try to start again, and this time succeed:

2017/01/21 15:00:30 [DVR] Starting job 1485036000-ch12.1 A Craftsman’s Legacy on ch=[12.1]
2017/01/21 15:00:30 [DVR] Recording for job 1485036000-ch12.1 from 10484E44 ch12.1 into “TV/A Craftsman’s Legacy/2017-01-21-1500 A Craftsman’s Legacy 2016-10-29 S03E09 The Cooper.mpg” for 29m29.873814401s

Presumably the 503 error is because it can’t get the tuner. So, two thoughts:

  • first, it seems like if the DVR already owns the tuner, and it’s already on the right channel, ideally it would be able to continue using it and start recording show B immediately. But I can imagine if jobs don’t know about each other, this could be tricky.

  • another idea is, if the DVR knows it just released a tuner, then maybe have Show B retry a little sooner (e.g. 5 seconds), once, just to see if it can re-acquire a tuner that was just given up.

30 seconds is a pretty long time to miss out of the start of a recording - it would be nice to avoid this, and have recordings start on time, or as close as possible…

1 Like
#2

Thanks for the detailed report. Definitely room for improvement here.

#3

Just for clarity’s sake, I should add that it doesn’t matter if Show B is on the same channel, or a different channel, than Show A - the behavior is consistently the same.

#4

Ya know, I thought of a potential (super hacky) workaround…which might be easy to implement.

I’m assuming that when a recording job stops, the tuner is “released” within a few seconds. If that’s not true, then never mind. But if it is (usually) true, then…

Right now there are record options to e.g. start 1 minute early, or stop 1 minute late. If there was a new option to stop 5 seconds early, or start 5 seconds late, it seems like that would mostly work around this problem for end users (albeit in a pretty hacky manner!), while it gave you time to consider any potential longer term solutions. It would pull the back-to-back “dead” time down from 30s down to 5s…

#5

No need for hacks. Will make sure this gets fixed correctly on Monday.

1 Like
#6

Ooh - awesome! Thanks!

#7

I do hope the fix also works for the case where one show after another is being recorded on the same channel. My tvheadend set up is smart enough to just use the same stream in these cases. One stream to two files.

Mark W.

#8

This issue has been fixed in DVR v2017.01.23.2004. Recordings scheduled back-to-back should no longer miss the first 30s.

Agree this would be a nice optimization, but it’s not something we’re going to get to until after the beta.

1 Like
#9

Good to know it’s in the pipeline.

Mark W