Adding 'queue' option to schedule once tuner is free ?

[Spark]

While setting up some recordings, I noticed if channel has a show that ends at 9:05 and the next show on the same channel starts at 9:05, what happens is, it starts recording as expected on tuner 1, and when shows ends, instead of using tuner 1 again, it starts the next recording at 9:05 on a different tuner.
I believe this is because of the padding at the end (which I have set to 3 mins).

Now, if I wanted to record another channel, it wouldn't allow it at the start time (9:00), since it would conflict, since the other tuners are in use.
Fine.
However, I don't really care that the show will be recorded 5 mins into it, hence the request of adding a 'queue' option that means, start recording whenever a tuner is free.

The other option would be to set padding for each recording separately, which would also solve the issue, since, at 9:05, it would free tuner, and start using the same tuner again at that time, or have it automatically set padding to 0 for cases when you are doing sequential recordings on the same channel.
This would allow to have the program at 9-10 be recorded, and have the one that starts at 9:05 be recorded as well.

Hope that makes sense ?

[johnsonx42]

Recordings are always scheduled without any consideration for padding. Padding is added at recording time only if the tuner is available and unneeded for other recordings... recordings with pre-padding won't start until a tuner is free, while post-padding is simply truncated when the tuner is needed.

Also, what kind of tuner are you using? If you have back-to-back recordings on the same channel, you should get both recordings with overlapping padding on the same tuner.

[mvallevand]

I've been asking for this for a few years. For the specialty channels that need my HDPVR I run into problem creating recurring when there are back to back recordings on different channels when the times don't align exactly. The priority recording records the other won't be scheduled. In 3.2.9 it now gets added as a conflict but you still need to cancel the other recording. This scenario happens regularly and there some show that aren't 100% on the hour the network play with this a bit.

Show A 21:00-22:03
Show B 22:00-23:00

What I'd like to see is the priority recurring recording getting scheduled and the lower priority truncated either at the beginning or end. This could still be marked as a conflict, the resolution would swap the recording.

For one-off's the new recording should be scheduled and truncated, perhaps generating a conflict rather then saying tuner not available.

Martin

[Spark]

Recordings are always scheduled without any consideration for padding. Padding is added at recording time only if the tuner is available and unneeded for other recordings... recordings with pre-padding won't start until a tuner is free, while post-padding is simply truncated when the tuner is needed.

Also, what kind of tuner are you using? If you have back-to-back recordings on the same channel, you should get both recordings with overlapping padding on the same tuner.

Using a HDR PRIME.
While what you described was the case for QAM, that isn't the case for cable-card use.

This has been going on all summer season, since that is the way they scheduled the shows, and NPVR always picks a new tuner, instead of staying on the same one, then, when the first show ended + padding is done, then, that tuner is released, and I have to manually go to the guide, and click quick record.
A: ch 700 9-10:05
B: ch 700 10:05-11:15
C: ch 87 9-10
D: ch 95 10-11

A, B, and C are all set via 'quick record'. When I try to add D, it throws up a conflict.
So, I need to wait for A to finish +padding, then I manually add D via quick record.

[johnsonx42]

Yes, I am aware that HDHR Prime is one of the tuner types that can't do Multi-Record.

As to your specific scenario, I really don't see how that can generate a conflict, padding or not. I'm not saying you're not having a problem, only that the specific example you give couldn't result in a conflict knowing what I believe I know about the way the scheduler works. Or to put it in internet speak, "logs or it didn't happen"

[Spark]

Yes, I am aware that HDHR Prime is one of the tuner types that can't do Multi-Record.

As to your specific scenario, I really don't see how that can generate a conflict, padding or not. I'm not saying you're not having a problem, only that the specific example you give couldn't result in a conflict knowing what I believe I know about the way the scheduler works. Or to put it in internet speak, "logs or it didn't happen"

Logs of what ?
When you try to select D, it had the conflict screen, and that is NOT logged AFAIK.
Even checking the logs, nothings in it says conflict resolution :xxxxxxxxxx or whatever... so, how am I supposed to show what is going on in logs ?

[Spark]

For what it is worth...

Code:

2014-08-14 21:00:00.557    [DEBUG][9]    Executing: F:\Silicondust\hdhomerun_config.exe 13195C83 set /tuner1/vchannel 792
2014-08-14 21:00:00.816    [DEBUG][9]    Executing: F:\Silicondust\hdhomerun_config.exe 13195C83 set /tuner1/target rtp://192.168.1.14:36315
2014-08-14 21:00:00.834    [DEBUG][9]    Started recording (967:2:R:\shows\Spartacus Blood and Sand\Spartacus Blood and Sand_20140814_21002205.ts)

...

2014-08-14 22:04:01.353    [DEBUG][9]    Executing: F:\Silicondust\hdhomerun_config.exe 13195C83 set /tuner0/vchannel 792
2014-08-14 22:04:01.678    [DEBUG][9]    Executing: F:\Silicondust\hdhomerun_config.exe 13195C83 set /tuner0/target rtp://192.168.1.14:36317
2014-08-14 22:04:01.681    [DEBUG][9]    Started recording (968:1:R:\shows\Spartacus Blood and Sand\Spartacus Blood and Sand_20140814_22052309.ts)

As you can see, even though it is the same channel, it got a new tuner, instead of using the same tuner, so, I couldn't schedule D above, as I wanted because of the conflict.

[whurlston]

If the recording was from 9-10 (unclear since the channel -- 792 -- is not listed above in A, B, C or D), then I wouldn't expect it to get the same tuner from a recording that starts at 10:04.

Although nothing in the logs will actually say "conflict resolution", we would be able to track the progression of recordings: when the tuner is scheduled, allocated, released, etc. A zip of the full logs folder and an time frame of when the error occurred could be very useful.

[johnsonx42]

Ok, I see what's going on, you have other shows before and after the shows A-D you listed which affect the tuner assignments and create conflicts unseen when looking at just those 4 shows by themselves. Show B recorded on the first tuner because it's the highest priority tuner and was free at the time, whereas some prior recording pushed Show A onto the second tuner (i.e maybe you had a show recording from 8pm to 9:01pm or something like that). Yes, it is possible to produce a tuner conflict in that sort of scenario when you really should have a free tuner.

You're right, having the oft-requested ability to start a recording late (or 'queue' a recording as you described) would help with this, but wouldn't be the best solution for this exact scenario (and it all still has nothing to do with padding).

@sub: I think a refinement to the scheduling logic would be very helpful here: when scheduling a show on (physical) channel X, check if any tuner was last used on the same channel X and is still available, if so use it for the new recording; if not follow normal tuner priority. This bit of logic would more efficiently allocate tuners, make better use of multi-record (I do realize multi-record isn't a factor for Spark), and would result in Spark's show B (the second on in his log snippet) using the same tuner as the preceding show on the same channel, even though a higher priority tuner was available at the moment of scheduling.

[mvallevand]

@sub: I think a refinement to the scheduling logic would be very helpful here: when scheduling a show on (physical) channel X, check if any tuner was last used on the same channel X and is still available, if so use it for the new recording; if not follow normal tuner priority.

I hate it. If my first show is on a low priority analog tuner I wouldn't want that for all prime time.

Martin