Options
Some new behaviour in .08
![[Deleted User]](https://w5.vanillicon.com/v2/5b29f224e10fee07a727e115b6dec7c1.svg)
[Deleted User]
Posts: 237 Forum Member
✭
I discovered another interesting behaviour last night when I set a few recordings that ran sequentially. What was different about this occasion was that both tuners were needed for two lots of simultaneous consecutive recording.
This is what I set up to record (with 1 min pre and 3 min post autopadding):
Rec 1. 20.00-21.00 Ch 4
Rec 2. 20.30-2100 BBC4
Rec 3. 21.00-22.00 BBC1
Rec 4. 21.00-21.30 BBC2
The big crunch point was clearly 21.00 (a 4 recording intersection!!), and I did wonder what was going to happen...!
What actually happened was that at 20.59 the box came up telling me that there was a clash and asking me what I wanted to do/cancel. At this point, I stopped one of the earlier recordings. Surprisingly, it then came up again asking me what I wanted to do about the remaining conflict (which doesn't happen if you have scheduled only one recording that clashes with the end/start of two others, where it now seems to drop autopadding automatically in .08).
So, the behaviour I thought we now had (of dropping autopadding) does not seem to be true if two tuners are impacted. If I had not been around to respond to the box, I would, presumably, have lost both recordings 3 & 4 - which would have been dropped.
Just thought I'd share the discovery! Presumably, the way to avoid this in the future is to cancel autopadding if such a clash happens again...is it?!
This is what I set up to record (with 1 min pre and 3 min post autopadding):
Rec 1. 20.00-21.00 Ch 4
Rec 2. 20.30-2100 BBC4
Rec 3. 21.00-22.00 BBC1
Rec 4. 21.00-21.30 BBC2
The big crunch point was clearly 21.00 (a 4 recording intersection!!), and I did wonder what was going to happen...!
What actually happened was that at 20.59 the box came up telling me that there was a clash and asking me what I wanted to do/cancel. At this point, I stopped one of the earlier recordings. Surprisingly, it then came up again asking me what I wanted to do about the remaining conflict (which doesn't happen if you have scheduled only one recording that clashes with the end/start of two others, where it now seems to drop autopadding automatically in .08).
So, the behaviour I thought we now had (of dropping autopadding) does not seem to be true if two tuners are impacted. If I had not been around to respond to the box, I would, presumably, have lost both recordings 3 & 4 - which would have been dropped.
Just thought I'd share the discovery! Presumably, the way to avoid this in the future is to cancel autopadding if such a clash happens again...is it?!
0
Comments
I set the recordings on different days, the last one being rec 2, which I set a few hours before transmission.
The order I think I set them in was 1, 3, 4, 2.
It should be a fairly easy thing to replicate. You need two recordings ending at the same time, and then two new recordings starting at that end point. To get precise duplication, some autopadding should also be set.
I would be interested to know if you or other members get the same result if you try to do the same thing...
Thanks Lancer. I dont think its all that easy to replicate because if I set up 4 recordings with autopadding on (2at the same time then 2 same time consectutive recordings) autopadding just drops padding overlaps caused by autopading. The trick is finding out what is the circumstance that make autopadding not 'auto-manage' the recordings and instead bring up this notice for manual intervention.
If this isn't so, are u suggesting that if the recordings are put in in a certain order, this won't happen? If so, could you say what the 'proper' order is, so I can avoid this happening again in a similar situation!!
From the EPG yes they did but this is a seporate issue. Lets try to figure it out.
Lancer I was hoping you could eventually tell me/us after doing some tests.
Yes I know or this is what I assumed. I mentioned the autopadding bug fix that hapened to be in the .08 (blanking problem and TIR problem solved) because its a partial fix - i.e. it fixes the autopadding problem when selecting consecutive programmes in non-chronological order from the EPG; but you can have the same bug strike if the last of the consecutive recordings is selected from the EPG initially and the first programme is an instant record nearer the time.
My advise is to temp forget about the autopadding bug for now and whether or not it is fixed and concentrate on how to get this pop up that you discovered. It could be related it might not be but they are different issues. As per your title lets say its some new behaviour we are trying to establish as a bug.
Maybe it's MUX related (i.e. how many different MUXes one is recording from), or (as Marc suggests) related to the order in which the reservations are made (but I don't recall the reservation order that caused the problem originally).
-- from Cy in the UK