Recordings failing/cut short

[sub]

lol - 'please'

[yyeoh]

Oh sorry, meant to explain but somehow forgot. In the latest batch of recordings Charmed failed with a signal failed to lock error.

[AlanC]

I get something similar. I unchecked 'out-of-process digital recording' when it first happened. I still have the problem, do I need the patch for extra logging?
Activity happens on the end of attached NRecord.log. "UK Border Force" is 10 minutes long, first "Batman" is 12 minutes, second is zero length. "Deep Wreck Mysteries" and "How Clean is your house" are OK.
(I have three tuner cards: a Cinergy 2400i, a Nova-DT 500 and a PCTV 290e)

[sub]

Yes, please apply that patch from the last page for more logging, then next time it happens repost the logs. I'd probably prefer you re-enable the out of process digital recording aswell, since it makes it easy for me to track things down since each tuner effectively has it's own log.

[k1wi]

I might have the same issue here... If not accept my humble apologies. I have two TV tuners, which often concurrently record two channels from one frequency and one channel from a second frequency over several hours.

My issue is that the tuners seem to 'switch over' when moving from one show to the next, requiring them to swap frequencies. The result is that the first show on a given channel is cut short without any post-padding, and the next channel, on the other frequency, does not have any pre-padding. The same happening on the other TV tuner.

Ideally what they should do is each stay on the same frequency (and pre-pad and post-pad), but that doesn't seem to happen... I have the logs, which I can pm to you as I don't really want them in the public domain.

I wondered whether the issue might be having a total of 6 HD recordings at once during the pre/post-padding (four on one tuner and two on the second), but I can't imagine that would be an issue as that would only work out around 12MB/s. I don't know whether manipulating the prepadding, to suit priority of the tuners will solve the problem, but suspect that manually recording all three channels should work, possibly using the prepadding to engage the different tuners.

[sub]

Padding is considered optional. It'll try and do it when it can, but sometimes it cant because the (fairly basic) logic was unable to resolve a way for all recordings involved to get padding - even if you know that it could have been done by recordings being allocated in a different way. Its hard to find one approach that suits all situations.

[k1wi]

Okay, I guess I'll have to manually record the shows/channels so that the tuners record the entire block on the one frequency.

It's just odd that the tuners decide they have to swap frequencies - if they stayed on their respective frequencies there wouldn't be an issue (when one tuner is recording consecutive shows on multiple channels on one frequency there isn't a problem).

[johnsonx42]

it largely has to do with the order in which the recordings were created. let's say you have these recurring recording requests in the following order:

Please Record Channel A, 1-2pm
Please Record Channel B, 1-2pm
Please Record Channel B, 2-3pm
Please Record Channel A, 2-3pm

You have two tuners, so when it schedules the recordings after the EPG update, it puts the first recording on the first tuner, and then puts the second recording on the second tuner. Then when it comes to the next timeslot, it just keeps going in order... now the third recording will get scheduled on the first tuner, and the fourth recording on the second tuner, so the actual recording schedule looks like this:

Record Channel A, 1-2pm on Tuner 1
Record Channel B, 1-2pm on Tuner 2
Record Channel B, 2-3pm on Tuner 1
Record Channel A, 2-3pm on Tuner 2

So now at 2PM, no recording gets either pre or post padding, because both tuners are changing frequencies. To my understanding, padding is only considered when the recording is actually being made; the scheduler does not consider padding when allocating the timeslots.

The way to fix this is to cancel the recurring recording request for Channel B at 2pm, and then schedule it again. Now it will have a lower priority than the Channel A recording at 2pm, and after the next EPG update the tuner assignments of the 2PM recordings will be reversed. Then each tuner will stay on the same channel the entire time.

[mvallevand]

You have two tuners, so when it schedules the recordings after the EPG update, it puts the first recording on the first tuner, and then puts the second recording on the second tuner. Then when it comes to the next timeslot, it just keeps going in order... now the third recording will get scheduled on the first tuner, and the fourth recording on the second tuner, so the actual recording schedule looks like this:

I figured the scheduling uses JIT logic and the recording service sequentially "asks" each device if it is multi-rec capable and do you have my channel available starting at the pre-buffer time. The tuner either accepts the recording or rejects it right up to the first broadcast end time. Based on the logs it is actually look prettys smart and sound, I haven't really figured out why back-to-back multi-rec multi-tuner doesn't work in this scenario.

Martin

[johnsonx42]

sub has said that when the recordings are scheduled after each epg update, it assigns each recording to a tuner. the assignment is provisional rather than fixed, but it's not going to change it unless logic elsewhere causes it to do so.

I think the at-recording-time logic is smart enough about seeking out another tuner if the one it was planning to use isn't available for some reason, but there's nothing that would completely reallocate multiple recordings. In the scenario I described, assuming 5 minutes pre-padding, when the recording service wants to record pre-padding for channel B at 1:55pm, it's going to ask both tuners if they're available to record channel B from 1:55pm to 3:00pm. They both say no. Tuner 1 is on channel A at 1:55pm, and while Tuner 2 is on channel B now it's going to have to switch to channel A at 2:00pm. It's easy enough for us humans to make the obvious intuitive leap and say "ok, Tuner 1, stay on Channel A and record that show, Tuner 2, you stay on Channel B, and then everyone gets pre- and post- padding.", but putting in computer logic to achieve that is a little harder.

Then consider the fact that in many cases there will be multiple tuners with different sets of channels. Some channels may be available on every tuner, others on some but not all, others available on just one. If it goes re-assigning tuners all the time trying to accomodate padding, it can easily get into a situation where a program that was previously scheduled to record now can't because the only tuners left available don't have the needed channel.