Recordings cut-off due to improper use of multiple tuners

[Handy.Man]

Monday night again it switches tuner at 21h00 and aborted the existing recording on that tuner ... instead of using the the other tuner already on the right channel.
It say the tuner was used for live tv ... I never 'watch' Live TV !

Thursday night it did the same at 21h00. Just wonder why it sometimes switch tuner instead of using the tuner that has the required channel to record.

Could the padding be split to 30sec when there is a conflict with padding?

[totallhavoc]

I found my issue from last night. The CW was not listed as a channel on 2 of my tuners so it limited what tuners it could use. I re-enabled that channel on the other 2 tuners. I will keep an eye on it and provide an update if needed.

[Handy.Man]

For the second time in a week, NextPVR will send two different channels on the same tuner even when two others tuners are available to take the recording at 20h00

At 19h29 Recording Infoman on channel 2 Tuner 2
At 19h59 Recording The Nature of Things on channel 6 should have started on Tuner 1 or 3 but instead, at 20h00 it started on Tuner 2!! :confused:

I installed March 4, 2013 - NPVR 2.5.9 Post-R2 Rollup 2 yesterday pm
I had Installed all patches up to #39 before that.

[johnsonx42]

It looks like it is considering the pre-padding of the following recordings when calculating whether the recording to be moved will overlap the following recordings. I don't think it ought to include the pre-padding in that calculation. One, padding has always been first-come, first-served; two, the user may cancel a recording in the interim, allowing the desired pre-padding to take place.

also sub, while I applaud the valiant, near-heroic effort of NRecord trying several times per second for an entire minute to move the recording, it seems a bit much... NRecord does everything else on a minute-basis, what does it think is going to change in the next 200ms? Maybe check just once per minute, or every 20 seconds at most?

Code:

2013-03-07 19:08:41.886    [DEBUG][7]    Requesting wake up for 'RecordingOID28770' at 2013-03-07 20:57
2013-03-07 19:08:41.886    [DEBUG][7]    Requesting wake up for 'RecordingOID28850' at 2013-03-07 20:57
...
2013-03-07 19:59:00.260    [DEBUG][7]    Checking possible candidate:: 24
2013-03-07 19:59:00.287    [DEBUG][7]     - overlaps with: [28850] Enquête
2013-03-07 19:59:00.287    [DEBUG][7]     - multirecord not possible (different locator)
2013-03-07 19:59:00.287    [DEBUG][7]    Checking possible candidate:: 20
2013-03-07 19:59:00.301    [DEBUG][7]     - overlaps with: [28770] Bazzo.tv
2013-03-07 19:59:00.301    [DEBUG][7]     - multirecord not possible (different locator)
...
2013-03-07 20:00:00.216    [DEBUG][7]    Recording not moved. No other available tuner could be found.
2013-03-07 20:00:00.233    [DEBUG][7]    allocating recording target filename: P:\Utilisateurs\Public\TV enregistrée\The Nature of Things\The Nature of Things_20130307_20002100.ts

[Handy.Man]

Yup it looks like it went in a loop trying to find the 'worst' solution looking two recordings ahead ... overlaps with: [28850] Enquête this one is 1 hour later and "was not in conflict" as there is only one recording to do next at 20h00

In the end I didn't loose anything on any recording so it's not a big concern, same thing last week in a similar situation.

I saw a workaround earlier stopping NextPVR service, modifying nprv.db3 to move consecutive recordings for a channel to 'one' tuner. Could that kind of 'workaround' be done before scheduling the next recording by NextPVR itself?

[johnsonx42]

Yup it looks like it went in a loop trying to find the 'worst' solution looking two recordings ahead ... overlaps with: [28850] Enquête this one is 1 hour later and "was not in conflict" as there is only one recording to do next at 20h00

That's not what your log says. As I quoted in my post, 28850 Enquête was scheduled for 2100, with a 1 minute pre-pad it was set to begin at 2059 (the wakeup being set for 2057). Hence NRecord calculated it would overlap with the Nature of things which was set to run until 2100.

I don't see anything going wrong at all. I'm just suggesting to sub that NRecord shouldn't consider the padding of future recordings when trying to move current recordings.

Edit: sorry, I misunderstood what you said. Yes, there was no real conflict at 2000 or 2100... I'm just explaining why nrecord calculated that there was.

[Petrovski]

Just a thought on all this - I seem to recall having a similar issue and resolved it by using "Auto-merge channels with same name" so that channels are in my case shown as having two sources [since I have a dual tuner]. This may be of no help but I thought I'd post just in case.

[Handy.Man]

Just a thought on all this - I seem to recall having a similar issue and resolved it by using "Auto-merge channels with same name" so that channels are in my case shown as having two sources [since I have a dual tuner]. This may be of no help but I thought I'd post just in case.

Where is that 'option'?

[Reddwarf]

Where is that 'option'?

Settings->Channels->Bulk Map (I think)

[Handy.Man]

Settings->Channels->Bulk Map (I think)

Yes your are right ... never been there before ! Will do it when NextPvr becomes idle as it suggest to backup npvr.db3