Webif crop feature stresses the processor

mihaid

Well-Known Member
I seem to have noticed that if the t2 is recording and you use the crop feature the ongoing recording turns out pixelated. I will check something else out.
 
I have no pixelated recordings in normal conditions. I have checked another recording made during the cropping and it was also pixelated. Perhaps it is time to put a warning on the cropping feature.
 
Perhaps you should run a disk check. Any data transfer slugging due to disk retries will cause a problem, but otherwise the auto-processes are set to low priority so that settop isn't compromised.
 
This thread should be titled "...stresses the disk bandwidth/latency". It's not to do with the processor.
 
Perhaps Crop and other potentially slow processes that have to read the entire ts file should be given add to Queue options so that they can be run serially at a time when there are no recordings in progress. Most of the OPT+ options were developed before the auto queue processing mechanism was created.
 
Surely that would make the detectads 'real time processing' (forgot what it's called) redundant?
 
Surely that would make the detectads 'real time processing' (forgot what it's called) redundant?
Detectads has had the options to run in realtime (chaserun) or deferred and to crop or just bookmark for a very long time now, it had queued processing long before auto processing did.
Do you want to be able to skip ads whilst a programme is still recording or are you prepared to wait and eliminate any potential interaction with other recordings?
 
I frequently watch a recording programme some time after it has started. As long as I delay the start long enough, the ads have been cropped. Of course, tidying up afterwards is a bit of a challenge. But it 'works for me'.
 
It happened again. Copy a recording, was not going very fast transfer, then as soon as the t2 started to record a programmed episode it froze/crashed.

All the queue transfers suggestions up this thread are not true.
 
it seems ok
Code:
Please select option: fixdisk

----------------------------------------------------------------------
Fix-disk run starting...
----------------------------------------------------------------------


Checking disk sda

Running short disk self test

No pending sectors found - skipping sector repair
Using superblock 0 on sda1
Using superblock 0 on sda2
Using superblock 0 on sda3

Checking partition /dev/sda3...
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
hmx_int_stor: 15/655776 files (6.7% non-contiguous), 219669/2622611 blocks

Checking partition /dev/sda1...
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
hmx_int_stor: 15/65808 files (6.7% non-contiguous), 16038/263064 blocks

Checking partition /dev/sda2...
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
hmx_int_stor: 13680/29860704 files (14.0% non-contiguous), 104995164/119209984 blocks
Removing extra swap space.
Are you having problems with a delete loop? [Y/N]: Are you having problems with a delete loop? [Y/N]: Skipped

Finished
fix-disk: session terminated with exit status 0
 
What about the SMART stats?

Query (for those who know): is there any means to access a count of retries?
 
This thread should be titled "...stresses the disk bandwidth/latency". It's not to do with the processor.
I did a trial some time ago when I had about half a dozen HiDef streams going on or off the HDD simultaneously. However, crop runs "while you wait", so it's obviously shovelling data much faster than a normal HiDef stream. Maybe it should be throttled back when not running from a live GUI click?
 
Back
Top