Long delay when accessing recordings with screen message - 'Processing...'

bottletop

Active Member
I seem to have an intermittent issue where I get a message across the middle of the screen trying to access the recordings.
Symptoms
  • Accessing recordings i.e. Media - Video, either via MENU/Video or MEDIA button
  • Centrally across the screen single (half) line white highlight/background with black letters Processing...
Usually the words 'Processing...' only appears for a second or less, but sometimes it stays stuck there for what seems like 30-60 seconds. Subjectively think it may be worse when it is background recording with DetectAds (chaserun). I'm usually ok with a small delay but am growing tired of it when it takes more than 15 seconds. Anyone else affected with this odd issue? How can I reduce the delay?
 
I get this regularly on my 3TB T2. The drive is about 95% full though (yes I know I'll never watch most of it) and I have assumed that this is the cause and learned to live with it.
 
Anyone else affected with this odd issue? How can I reduce the delay?
I expect you've discovered that impatiently pressing buttons on the remote when 'processing' is seen often results in a crash and reboot. I soon learned to touch nothing until the message disappears.

You can reduce the problem somewhat by restricting 'auto processing' to a slot in the wee small hours, waking the box up with a reminder. Its not a complete solution but I have found that it helps.
 
Running fix-disk to ensure there are no underlying disk issues is first thing to attempt - even a single faulty sector in critical file can cause major slow downs.

You can also control when auto processing runs and defer it to non-prime time including detectads if you switch from chaserun.
 
Thank you all for help and suggestions.
One thing I have adopted - set Menu/Preferences/Screen Display/Transparency set to 50% or 75%.
This allows me to see something else (other than a blank screen with message) when waiting for the unit to respond.

I presume you've run fixdisk, and made sure there is adequate spare capacity?
Running fix-disk to ensure there are no underlying disk issues is first thing to attempt - even a single faulty sector in critical file can cause major slow downs.
I do run fixdisk regularly and haven't noticed any errors on previous runs at all. I've run one again just to make sure - no errors. There is ample free space.

Yes. It takes longer when the machine/disk is busy doing something.
That was my thought as well - from my observed interactions. The odd thing is when I try testing the load - eg by recording 2 things simultaneously (non BBC channels so that it tries to invoke DetectAds) - it doesn't always slow the unit down. I am confused.

I get this regularly on my 3TB T2. The drive is about 95% full though (yes I know I'll never watch most of it) and I have assumed that this is the cause and learned to live with it.
You can't, other than deleting lots of stuff.
It's another particularly annoying code inefficiency from those Humax programmers.
I didn't think the amount of used space slowed the unit down (except during startup and media scans for normal shutdowns). Although I notice the Processing... appears for a few seconds if I try to navigate to directories with, say, over 45 entries (background DetectAds was also running at the time).

I expect you've discovered that impatiently pressing buttons on the remote when 'processing' is seen often results in a crash and reboot. I soon learned to touch nothing until the message disappears.
I agree, I've told the household to stop pressing buttons when the unit becomes unresponsive - otherwise it will likely crash/reboot.

You can reduce the problem somewhat by restricting 'auto processing' to a slot in the wee small hours, waking the box up with a reminder. Its not a complete solution but I have found that it helps.
You can also control when auto processing runs and defer it to non-prime time including detectads if you switch from chaserun.
That's a fair point. I use to do this over a year ago. I ran the Decrypt. DetectAds and Shrink overnight (ie non chaserun) to keep the unit responsive.
Although this means I need to keep the unit running overnight, and I'll need to watch recordings the next day instead of just after recording completion.
 
Last edited:
That was my thought as well - from my observed interactions. The odd thing is when I try testing the load - eg by recording 2 things simultaneously (non BBC channels so that it tries to invoke DetectAds) - it doesn't always slow the unit down. I am confused.
I suspect the recording pathway is pretty much implemented in hardware and autonomous, requiring little input from the general purpose processor. Anything implemented by CF will put demand on the processor, but is set at a lower multitasking priority than the native Humax processing, so shouldn't slug the UI too much unless there is a pending operation which does not release the thread.

I'm sure there are counter-examples, but I like to finger HDD retry operations as a reason for slugging the processing. These wouldn't necessarily show up as file system errors or reallocations in fixdisk, but the SMART stats should show something.
 
...
I'm sure there are counter-examples, but I like to finger HDD retry operations as a reason for slugging the processing. These wouldn't necessarily show up as file system errors or reallocations in fixdisk, but the SMART stats should show something.
Nothing in the SMART attributes stand out to me. They currently show:
Code:
Attributes
ID   Name                            Flags       Raw Value    Value   Worst    Threshold    Life Left    Notes
1    Raw_Read_Error_Rate             POSR-K      0            200        200        051                  -
3    Spin_Up_Time                    POS--K      6691         166        164        021                  -
4    Start_Stop_Count                -O--CK      1634         099        099        000     99%          -
5    Reallocated_Sector_Ct           PO--CK      0            200        200        140                  -
7    Seek_Error_Rate                 -OSR-K      0            200        200        000                  -
9    Power_On_Hours                  -O--CK      25296        066        066        000     66%          -
10   Spin_Retry_Count                -O--CK      0            100        100        000     100%         -
11   Calibration_Retry_Count         -O--CK      0            100        100        000     100%         -
12   Power_Cycle_Count               -O--CK      1634         099        099        000     99%          -
192  Power-Off_Retract_Count         -O--CK      1631         198        198        000                  -
193  Load_Cycle_Count                -O--CK      2            200        200        000                  -
194  Temperature_Celsius             -O---K      32           118        103        000                  -
196  Reallocated_Event_Count         -O--CK      0            200        200        000                  -
197  Current_Pending_Sector          -O--CK      0            200        200        000                  -
198  Offline_Uncorrectable           ----CK      0            100        253        000                  -
199  UDMA_CRC_Error_Count            -O--CK      0            200        200        000                  -
200  Multi_Zone_Error_Rate           ---R--      0            200        200        000                  -
These were the attributes a while ago:
Code:
Attributes
ID    Name                       Flags     Raw Value    Value  Worst  Threshold    Life Left    Notes
1     Raw_Read_Error_Rate        POSR-K    0            200    200    051                       -
3     Spin_Up_Time               POS--K    6675         166    164    021                       -
4     Start_Stop_Count           -O--CK    1078         099    099    000          99%          -
5     Reallocated_Sector_Ct      PO--CK    0            200    200    140                       -
7     Seek_Error_Rate            -OSR-K    0            200    200    000                       -
9     Power_On_Hours             -O--CK    13781        082    082    000          82%          -
10    Spin_Retry_Count           -O--CK    0            100    100    000          100%         -
11    Calibration_Retry_Count    -O--CK    0            100    100    000          100%         -
12    Power_Cycle_Count          -O--CK    1078         099    099    000          99%          -
192   Power-Off_Retract_Count    -O--CK    1075         199    199    000                       -
193   Load_Cycle_Count           -O--CK    2            200    200    000                       -
194   Temperature_Celsius        -O---K    35           115    103    000                       -
196   Reallocated_Event_Count    -O--CK    0            200    200    000                       -
197   Current_Pending_Sector     -O--CK    0            200    200    000                       -
198   Offline_Uncorrectable      ----CK    0            100    253    000                       -
199   UDMA_CRC_Error_Count       -O--CK    0            200    200    000                       -
200   Multi_Zone_Error_Rate      ---R--    0            200    200    000                       -
I don't think it is a hardware or drive issue by itself. It is probably something I've set or just over taxing the unit a little.
 
I seem to have an intermittent issue where I get a message across the middle of the screen trying to access the recordings.
Symptoms
  • Accessing recordings i.e. Media - Video, either via MENU/Video or MEDIA button
  • Centrally across the screen single (half) line white highlight/background with black letters Processing...
Usually the words 'Processing...' only appears for a second or less, but sometimes it stays stuck there for what seems like 30-60 seconds. Subjectively think it may be worse when it is background recording with DetectAds (chaserun). I'm usually ok with a small delay but am growing tired of it when it takes more than 15 seconds. Anyone else affected with this odd issue? How can I reduce the delay?
I noticed this more often since I connected the PVR and TV to a sound-bar via HDMI cables.

When the TV input is from the Humax and 'Processing' appears when accessing the recordings sometimes it appears frozen.

However using the remote 'AV' button and toggling the TV input to aeriel/Freeview and waiting until all screen messages go, then changing back the 'AV' input to the Humax/PVR seems to speed up the 'Processing'.

I also have a usb drive connected to the front panel .

I don't know if it is coincidence or just PVR overload.

Have you timed, with doing nothing, how long 'processing occurs' before it disappears and allows next choice in the menu ?
 
If you look at in a different way, when you select 'Menu' on the remote the menu options appear over what you are viewing for exactly 3 minutes (unless you change options e.g. press 'TV Guide' in which case the 3 minute timer resets )

Does the 'processing' message lasts exactly 3 minutes ?, I have never waited that long or timed it.

But a question to ask would be is there any part of the hard drive or memory that changes for 3 minutes and then reverts to default, unless there are other remote control presses to reset the 3 minute 'processing' wait.

I.e. when you press the menu button is there a super imposed browser / web type page that has photos,links and options that the remote can move through (channel list, TV guide, Video,,, etc) . And is this the same process that shows up the 'Processing'?

Thankfully the 'Processing' delay hasn't been too much an issue, or I would have to look at a different device.
 
If you look at in a different way, when you select 'Menu' on the remote the menu options appear over what you are viewing for exactly 3 minutes (unless you change options e.g. press 'TV Guide' in which case the 3 minute timer resets )

Does the 'processing' message lasts exactly 3 minutes ?, I have never waited that long or timed it.
...
Not sure if there is a misunderstanding there somewhere - I'm only bothered by the 'Processing..' message delay when accessing recordings.
See post #1

I have the issue on more than one HDR, the HDRs in question have
  • either Western Digital or Seagate drive
  • have ample free space (60% used or 20% used)
  • do not have active/potential SMART errors
  • do not have any filesystem errors - ran fixdisk to make sure
Things I have tried that made no difference
  • setting a cpu usage limit for DetectAds
  • remove and reinstall DetectAds
  • reinstall custom firmware
Things that I tried that helps
  • using DetectAds(traditional) overnight instead of DetectAds(chaserun) #6
So now if I wish to watch recordings on the day I'll have to put up with adverts or manually set up the bookmarks myself!
It's a shame as DetectAds(chaserun) use to work fine in that the overhead was not noticeable. Subjectively, the delays just got gradually worse but I can't fix the issue, only work around it.
 
Back
Top