Forum > Decoders > PVR Decoders > Some (non-technical) insights on recordings on Explora
Reply
Thread Tools Display Modes
  #1  
Old 2017-05-10 , 16:33
MC Marietjie's Avatar
MC Marietjie MC Marietjie is offline
MultiChoice
 
Join Date: Jul 2010
Location: Johannesburg, Gauteng
Posts: 7,974
Default Some (non-technical) insights on recordings on Explora

This thread has reference: http://forum.dstv.com/showthread.php...978#post343978

In investigating what went wrong with the series recordings on M-Net Binge this weekend, we got some interesting insights from the techies about how recordings on the Explora works. This specifically applies to back-to-back recordings on the Explora.

The Explora software is designed to automatically deal with back-to-back recordings. If you have a recording from 1:00-1:29 and then one from 1:30 onwards, it should discard your buffer settings to ensure that both recordings happen. In other words, your buffer will not apply as it is overridden by the back-to-back recordings.

On the M-Net Binge channel, the shows were scheduled back-to-back eg 1:00-2:00, 2:00-3:00. As there is then a one minute overlap in the middle, the Explora software sees that as a conflict and cancels the second recording.

This is why the rebroadcasts on Thursday and Friday, and this weekend's broadcasts will have a 5 minute gap in between the shows. So your decoder has the chance to ensure the series recording is successful.

Having said that, we do suspect in some instances (and don't yet know which ones), there is a bug that causes the software not to ignore the buffers and therefore not to record the back-to-back episodes. We don't have any details yet and many more tests need to be done.

This is not meant to be a technical discussion or technical guidelines - just wanted to share as I found the information very interesting.
Reply With Quote
  #2  
Old 2017-05-10 , 16:43
Optimist's Avatar
Optimist Optimist is offline
Changes remote batteries hourly
 
Join Date: Jul 2012
Location: N/E JHB , Orig. Join Date: Dec 2008
Posts: 13,581
Thanks for this.

As we've collectively often needed to record completely back-to-back (1st program end time is the same as 2nd program start time) it's been seen that there isn't (normally) a problem - both have always worked, and even a third program in the same fashion after this has always worked fine.

As mentioned, personally I had reset all "sandwiched" safety nets individually to 0 minutes and was still affected, so I'm not convinced that this is the problem.
What I think is happening is that when there's too many back-to-backs in a row then it somehow is creating software confusion.

I hope we'll hear more, thanks again :-)
Reply With Quote
  #3  
Old 2017-05-10 , 17:10
Optimist's Avatar
Optimist Optimist is offline
Changes remote batteries hourly
 
Join Date: Jul 2012
Location: N/E JHB , Orig. Join Date: Dec 2008
Posts: 13,581
Quote:
Originally Posted by Optimist View Post
As we've collectively often needed to record completely back-to-back (1st program end time is the same as 2nd program start time) it's been seen that there isn't (normally) a problem - both have always worked, and even a third program in the same fashion after this has always worked fine.
By saying normally, I'm also referring to the fairly recent reported incidents where both Mad Cat and myself experienced a conflict of the back-to-back we both had a conflict error with - in both cases (different days and programs) the conflict was supposedly impossible as there was no overlapping of times, and in my case I had then also reset the individual "sandwiched" safety nets to 0 minutes.
We're unaware of any recurrences (other than perhaps what happened with Twin Peaks).

So, if the same fault which looks likely, this suggests it may not be related to how many back-to-backs there are in a row after all and that it's of a nature not yet understood by anyone.

Hope this helps all involved, I'm done for now.
Reply With Quote
  #4  
Old 2017-05-10 , 17:16
MC Marietjie's Avatar
MC Marietjie MC Marietjie is offline
MultiChoice
 
Join Date: Jul 2010
Location: Johannesburg, Gauteng
Posts: 7,974
Thanks for all the insights, will pass it on. Think you've got a glimpse into the tough job the decoder guys face - was fascinating today how our insight evolved.
Reply With Quote
  #5  
Old 2017-05-10 , 20:13
Krugie's Avatar
Krugie Krugie is offline
Changes remote batteries daily
 
Join Date: Dec 2008
Location: Moreleta Park, Pretoria
Posts: 3,588
Quote:
Originally Posted by MC Marietjie View Post
On the M-Net Binge channel, the shows were scheduled back-to-back eg 1:00-2:00, 2:00-3:00. As there is then a one minute overlap in the middle, the Explora software sees that as a conflict and cancels the second recording.
This was never the case though. Scheduling has always been like this and back-to-back recordings were never an issue - even with my 10 minute buffers each side. Something changed with the most recent software update - I have no doubts regarding this.
__________________
Octo-LNB to 2 x 5.2 switches. Explora 1 (Primary) & HDPVR 2P (Secondary) in lounge, Samsung 55" UA55F8500 Smart 3D LED TV, HDMI picture and audio via Onkyo TX-NR626 receiver, Samsung BD-F7500 3D Blu-Ray player. Explora 1 in bedroom with HDMI picture & audio to Samsung 32" UA32F5500 Smart LED TV.
Reply With Quote
  #6  
Old 2017-05-11 , 10:04
Geoff D Geoff D is offline
Technical Myriad
 
Join Date: Nov 2008
Location: PTA
Posts: 16,224
Quote:
Originally Posted by MC Marietjie View Post

The Explora software is designed to automatically deal with back-to-back recordings. If you have a recording from 1:00-1:29 and then one from 1:30 onwards, it should discard your buffer settings to ensure that both recordings happen. In other words, your buffer will not apply as it is overridden by the back-to-back recordings.

On the M-Net Binge channel, the shows were scheduled back-to-back eg 1:00-2:00, 2:00-3:00. As there is then a one minute overlap in the middle, the Explora software sees that as a conflict and cancels the second recording.

This is why the rebroadcasts on Thursday and Friday, and this weekend's broadcasts will have a 5 minute gap in between the shows. So your decoder has the chance to ensure the series recording is successful.

Having said that, we do suspect in some instances (and don't yet know which ones), there is a bug that causes the software not to ignore the buffers and therefore not to record the back-to-back episodes. We don't have any details yet and many more tests need to be done.

This is not meant to be a technical discussion or technical guidelines - just wanted to share as I found the information very interesting.
Quote:
Originally Posted by Krugie View Post
This was never the case though. Scheduling has always been like this and back-to-back recordings were never an issue - even with my 10 minute buffers each side. Something changed with the most recent software update - I have no doubts regarding this.
I am sorry, I cannot see why the perception exists that the buffer settings are discarded in one instance and ignored in others. I accept that it appears to be what is happening but that just means that (as Krugie suggests), the latest sw update has broken the process that detects and eliminates buffer overlaps.

Let us look at the scenarios mentioned by MoM.

1. The first point is that IF there is a difference between the binge channel and other channel, then the very first item should be to ensure that the EPG for the binge channel is being set up exactly the same as the other channels. Even the smallest difference could be at the heart of this problem, which would then probably mean that nothing has gone wrong with the software.

2. Deliberately broadcasting items on the binge channel with a 5-minute gap between programs will completely eliminate any issues with the sw failing to cancel out buffer overlaps, provided the buffer settings are not >5 minutes each side. So this is an EPG "fix" for a problem with the software ( or another incorrect parameter in the Binge EPG), that makes the operation of the routine to detect and eliminate buffer overlaps unnecessary.

3. Assuming default buffer settings of 1 minute each.

This first scenario of item one ending at x:29 and the next starting x:30:

The sw would set the first recording end time at x:29 + 1 = x:30
The second setting would be set to start at x:30 - 1 = x:29. The result is a 1 minute overlap, which if the sw is working correctly would be eliminated and cancelled leading to the sw setting the final schedules as:
x:29 (1st recording end)
x:30 (2nd recording start) no overlap, not even back-to-back, but with a 1 minute gap between the recordings, giving the decoder sw plenty of time to process the settings and start each recording correctly.

4. The next scenario is the recordings are actually back-to-back by default.

End: x:30 + 1 = x:31
Start x:30 - 1 = x:29

which equals a 2-minute overlap!. BUT if the sw eliminates the buffer overlaps (as it has supposedly being doing all along) then the one would end at x:30 and the other would start at x:30.

Now all that would be an issue is does the processor work fast enough to process this and stop and start a recording in this scenario? If yes then what has changed is that some or other routine is hogging CPU time now with the new sw which causes the sw not to start the second recording causing it to fail, NOT because of a EPG conflict but because of something else going on.

In this case any amount of fiddling with the EPG and the overlap routine is pointless until someone works out what is keeping the CPU busy now that it was not doing before?

Any amount of playing around with the end and start times is not going to fix anything, but appears to be actually breaking the process instead. Instead of the recordings just failing ( or on the older decoders, simply starting late), the "gap" is now giving the sw enough time to actually record it as a conflict and posting a triangle and not scheduling the second recording at all.
__________________
Easyview, UEC 4T HD PVR, SD PVR, XV
Spare decoders: SD PVR(2), PACE HD PVR 4T, DSD 660, 1110, 1131, Explora 1
2 unmentionable FTA decoders
Win 10 Pro (64-bit) version 1703, build 15063.138
1.2m antenna, 8-way universal LNB, 2x6 MS, FSM permanently connected.
MS Edge 40 with MSEdge HTML 15

Last edited by Geoff D; 2017-05-11 at 10:11. .
Reply With Quote
  #7  
Old 2017-05-11 , 10:58
Optimist's Avatar
Optimist Optimist is offline
Changes remote batteries hourly
 
Join Date: Jul 2012
Location: N/E JHB , Orig. Join Date: Dec 2008
Posts: 13,581
Quote:
Originally Posted by Geoff D View Post
3. Assuming default buffer settings of 1 minute each.

This first scenario of item one ending at x:29 and the next starting x:30:

The sw would set the first recording end time at x:29 + 1 = x:30
The second setting would be set to start at x:30 - 1 = x:29. The result is a 1 minute overlap, which if the sw is working correctly would be eliminated and cancelled leading to the sw setting the final schedules as:
x:29 (1st recording end)
x:30 (2nd recording start) no overlap, not even back-to-back, but with a 1 minute gap between the recordings, giving the decoder sw plenty of time to process the settings and start each recording correctly.
I'm fairly certain this isn't exactly what happens, I think one of the recordings would hang on to its 1 min. buffer but wouldn't know which. Perhaps based on priority settings for the two programs.

The CPU busy theory makes sense, but may not be involved here - IF the other problem recordings Mad Cat and I experienced a few days earlier are related, those caused a conflict warning, so then the problem would then be occurring way in advance of the triggering periods and so could only be software related with the possibility of unseen other EPG data causing a mix up.

Whatever is going on, definitely nothing to do with the safety nets based on my taking the trouble to individually set ALL sandwiched ones to 0 minutes - I've been doing that without exception for quite a long time now to try get to the bottom of the related confusion that has been escalating.
Reply With Quote
Reply
« Previous Thread | Next Thread »
Thread Tools
Display Modes
Posting Rules
You may not post new threads  | You may not post replies  | You may not post attachments  | You may not edit your posts
BB code is On  | Smilies are On  | [IMG] code is On  | HTML code is Off
Similar Threads
Thread Thread Starter Forum Replies Last Post
Help Please -- I have a non-MC technical problem to solve. Sandtonman Satellite & TV Technology 3 2014-03-03 14:02
Some questions about Non Premium Packages Geoff D General 11 2011-11-11 09:21
HD PVR + 1110: after re-install, some channels work, some don't dillon HD PVR 10 2010-09-02 16:06
Some Technical Questions (Living in a complex) poolmania HD PVR 9 2009-02-17 14:33