Would anyone recommend using an SSD in place of a standard hard drive for their Humax?

[bottletop]

I've thought about it on occasions but after seeing this https://hummy.tv/forum/threads/ssd-lesson-learnt.10611/#post-162160 I'll be reluctant to try it out for myself as a long term solution.
There are some differences, eg drive noise (idle, seek, etc), capacity, speed but I wonder if anyone else has tried it for a good length of time eg over a year?
If so - did the the SSD cope ok? If it didn't were you able to reuse it again after a long stint on the Humax?
Would you recommended it?

 

[Black Hole]

I'm sure you are aware of previous discussion, but in summary the modern generation of SSDs supposedly has sufficient write cycles to last many years, even in a PVR, due to wear-levelling algorithms. I tried an early-generation SSD and buggered it up pretty quickly (although a lot less quickly than using a UPD - I'm talking HD-FOX).

[20/12/2015]
The SSD got installed, WebIF downloaded, packages added, etc etc straight after prpr's tip (thanks - it didn't occur to me to try the command without a path prefix). All running sweet at the moment (but so did the UPD to start with) - except I have put tape over the enclosure LED because it's blue and SOOOO F*****G BRIGHT!!!! (Maybe one made by a Taiwanese LED manufacturer called Kingbright - I'm not kidding, there is one, and I have previously joked that the name should have an initial apostrophe, or even first name Fu!)

[28/5/2017]
Oh bollox!

I had to disconnect power to HD3 to move it yesterday, and since then the SSD isn't being recognised. I tried it plugged into an HDR to check it's not the HD USB port that's dead, but still no go. I'll have a look around with a disk utility on PC when I get the chance, but I'm not hopeful. If I can't resurrect it I will move on to the metal-cased UPD purchased on af123's recommendation: https://hummy.tv/forum/threads/hd-fox-cf-host-upd.4511/page-6#post-90940

The coincidence with de-powering seems too great to ignore, so maybe the uncontrolled shutdown killed it rather than wearing it out in normal use.

17 months.

Since then I have installed a Crucial BX500, in July 2021. Still running...

However, byte-for-byte, SSDs are still pretty expensive compared with spinny disks, and (IMO) there's a better chance of extracting stuff from a flakey HDD than when a SDD goes tits up. If you don't care about any of that, then fitting a HDR-FOX with an SSD will mean silence because the fan will not have to run much (if ever).

 

[sine24]

Since then I have installed a Crucial BX500, in July 2021. Still running...

So not a year yet .....

 

[bottletop]

I'm sure you are aware of previous discussion, but in summary the modern generation of SSDs supposedly has sufficient write cycles to last many years, even in a PVR, due to wear-levelling algorithms. I tried an early-generation SSD and buggered it up pretty quickly (although a lot less quickly than using a UPD - I'm talking HD-FOX).....

So are the results of your SSD posts only in relation to an HD-FOX T2?
What are the results of the SMART details now, 9-10 months of usage?
Do you have the TSR live buffer on all the time? And is the TSR on a very low bit rate (eg BBC red button), SD, or HD channel?
Roughly how many hours of SD/HD recordings per week (or per month) gets written on the SSD in the HD FOX T2?

Any experience of using SSD on HDR-FOX T2? If so, same questions about usage. The responses may help other decide for their individual use case(s).

 

[Stummery]

Heres a thought. You are obviously not going to get your questions answered.
So why don't you buy and fit one...... then you can answer all your questions and provide valuable feed back to the rest of the forum.

 

[/df]

For HD Fox purposes I can't imagine anyone complaining about the noise of a 2.5" external HDD (about to be surprised?). In a different solution, a 64GB SD card has been working fine for TSR and emergency recordings (although smartctl doesn't know about the USB-SD interface so I can't get a health check).

For HDR it should be possible to put in a 2.5" HDD (the SSDs I've used have all been 2.5" SATA drives anyway) and it will be still less audible than an external HDD.

 

[Black Hole]

So are the results of your SSD posts only in relation to an HD-FOX T2?

Yes. So what?

What are the results of the SMART details now, 9-10 months of usage?

I'll have to get back to you on that. SMART isn't as easy to acquire on HD-FOX.

Do you have the TSR live buffer on all the time?

Yes, deliberately. 24/7.

And is the TSR on a very low bit rate (eg BBC red button), SD, or HD channel?

Various, but it spends most of its time on Quest.

Roughly how many hours of SD/HD recordings per week (or per month) gets written on the SSD in the HD FOX T2?

Not much, but is that relevant compared with the TSR hammering it gets?

Any experience of using SSD on HDR-FOX T2? If so, same questions about usage.

No, but again not relevant. The duty cycle is the same.

The responses may help other decide for their individual use case(s).

I wouldn't have thought there's anything above which couldn't be gleaned from the existing conversations. For maximum longevity: don't run 24/7, or disable TSR. Longevity and cost vs HDD are the only considerations.

For HD Fox purposes I can't imagine anyone complaining about the noise of a 2.5" external HDD (about to be surprised?).

Well, considering the fanless and HDD-less HD-FOX is an ideal media client for the bedroom...

In a different solution, a 64GB SD card has been working fine for TSR and emergency recordings (although smartctl doesn't know about the USB-SD interface so I can't get a health check).

How long for? SD cards are not specified for large numbers of write cycles, and have no wear levelling.

For HDR it should be possible to put in a 2.5" HDD

Of course it is. Same as a 2.5" SSD: the HDD chassis needs a couple of holes drilled, or just fix it in place with double sided foam tape.

 

[/df]

How long for? SD cards are not specified for large numbers of write cycles, and have no wear levelling.

But are a lot cheaper than SSDs ...

Since https://hummy.tv/forum/threads/hd-fox-with-usb-hub-gadget-usb-drive-not-candidate-for-r-a-g.8616/.

 

[Black Hole]

SMART isn't as easy to acquire on HD-FOX.

Apologies, it seems that (at least in my case, with a USB-SATA adapter from a 2.5" HDD external enclosure) it is in fact easy: WebIF >> Diagnostics >> Disk Diagnostics did the trick.

SMART Status        PASSED   
Device Model        CT240BX500SSD1
Serial Number       2117E59BCC9F
LU WWN Device Id    5 00a075 1e59bcc9f
Firmware Version    M6CR052
User Capacity       240,057,409,536 bytes [240 GB]
Sector Size         512 bytes logical/physical
Rotation Rate       Solid State Device
Form Factor         2.5 inches
ATA Version is      ACS-3 T13/2161-D revision 4
SATA Version is     SATA >3.2 (0x1ff), 6.0 Gb/s (current: 1.5 Gb/s)
Local Time is       Sat May 28 11:07:08 2022 BST
SMART support is    Available - device has SMART capability.
SMART support is    Enabled


ID   Name                     Flags   Raw Value    Value  Worst  Threshold  Life Left  Notes
1    Raw_Read_Error_Rate      POSR-K  0            100    100    000                   -
5    Reallocated_Sector_Ct    -O--CK  0            100    100    010        100%       -
9    Power_On_Hours           -O--CK  6955         100    100    000        100%       -
12   Power_Cycle_Count        -O--CK  104          100    100    000        100%       -
171  Unknown_Attribute        -O--CK  0            100    100    000        100%       -
172  Unknown_Attribute        -O--CK  0            100    100    000        100%       -
173  Unknown_Attribute        -O--CK  214          079    079    000        79%        -
174  Unknown_Attribute        -O--CK  102          100    100    000        100%       -
180  Unused_Rsvd_Blk_Cnt_Tot  PO--CK  29           100    100    000        100%       -
183  Runtime_Bad_Block        -O--CK  0            100    100    000        100%       -
184  End-to-End_Error         -O--CK  0            100    100    000                   -
187  Reported_Uncorrect       -O--CK  0            100    100    000                   -
194  Temperature_Celsius      -O---K  38           062    051    000                   -
196  Reallocated_Event_Count  -O--CK  0            100    100    000        100%       -
197  Current_Pending_Sector   -O--CK  0            100    100    000                   -
198  Offline_Uncorrectable    ----CK  0            100    100    000                   -
199  UDMA_CRC_Error_Count     -O--CK  7            100    100    000        100%       -
202  Unknown_SSD_Attribute    ----CK  21           079    079    001        79%        -
206  Unknown_SSD_Attribute    -OSR--  0            100    100    000                   -
210  Unknown_Attribute        -O--CK  0            100    100    000        100%       -
246  Unknown_Attribute        -O--CK  28863711046  100    100    000        100%       -
247  Unknown_Attribute        -O--CK  901990970    100    100    000        100%       -
248  Unknown_Attribute        -O--CK  3044965840   100    100    000        100%       -
249  Unknown_Attribute        -O--CK  0            100    100    000        100%       -
250  Read_Error_Retry_Rate    -O--CK  0            100    100    000        100%       -
251  Unknown_Attribute        -O--CK  4006809410   100    100    000        100%       -
252  Unknown_Attribute        -O--CK  11           100    100    000        100%       -
253  Unknown_Attribute        -O--CK  0            100    100    000        100%       -
254  Unknown_SSD_Attribute    -O--CK  325          100    100    000        100%       -
223  Unknown_SSD_Attribute    -O--CK  1            100    100    000        100%       -

 

[Black Hole]

I looked up Crucial's definition of the SMART attributes, who caution that third-party interrogators might not label the attributes correctly or assign the correct thresholds and life percentages... in particular resulting in invalid warranty claims. They are pretty tight-lipped about the interpretation, maybe to make people used their proprietary SMART interrogator software (Windows only) and not provide the interpretation for third-party software. From https://uk.crucial.com/support/articles-faq-ssd/ssds-and-smart-data:

Attribute 5: Retired NAND Blocks / Superblocks (current value: 0)

Crucial say that whether blocks or superblocks are counted depends whether the SSD is an older or newer model, without specifying which are the newer models! Many NAND blocks can be retired before a superblock is retired.​

Attribute 174: Unexpected Power Loss Count (current value: 102)

No warning from the host system of impending power loss. I guess that's when I force a reboot.​

Attribute 180: Unused Reserved Block / Superblock Count (current value: 29 so I guess that's superblocks)

When the unused reserved block count reaches zero, Crucial says the SSD will be made read-only. As I have not lost any superblocks yet, I have no handle on the lifetime percentage.​

Attribute 210: RAIN Successful Recovery Page Count (current value: 0)

Apparently RAIN stands for "Redundant Array of Independent NAND" and can be thought of as internal RAID. Meh.​

I'm interested in attributes 246, 247, 248, 251 - the article doesn't say what they are, maybe I'll connect the drive to Windows and see what the Crucial tool says. The figures seem too low to be byte read/write counts, but could be in kB. 28G / 7000 hours = 4M/hour, so that could easily be 2 GB written and 2 GB read (is the timeshift buffer read as well as written?).

As of today: Attribute 9 = 7213, Attribute 246 = 29709259902

7,213 - 6,955 = 258 = 10 days 18 hours (about right). 29,709,259,902 - 28,863,711,046 = 845,558,856 = 3,277,359 somethings per hour.

 

[prpr]

is the timeshift buffer read as well as written?

Obviously it is if you're timeshifting. And write only if you're not. Doesn't seem that hard to infer...

 

[/df]

The /mod/bin/status Jim script now does some checks in this area using the lsof output for the settop program. If it has no open file descriptors on the timeshift buffer, timeshift is off; if there are twothree, the unit is playing delayed timeshift; if onetwo it's just saving the live content.

 

[Black Hole]

Doesn't seem that hard to infer...

Yes I can infer, but I wasn't looking for inference. I was looking for hard data to support or deny my inference.

The /mod/bin/status Jim script now does some checks in this area using the lsof output for the settop program.

What version is that (what does "now" mean)? It gives me nothing useful (HD-FOX) other than tell me I'm watching "delayed" if via the TSR.

I tried lsof | grep "0.ts" but even that gave me loads of output with no clear interpretation. Sample:

humaxtv     270         root   20w      REG        8,1 18924699648    2260995 /media/drive1/.tsr/0.ts                                                                                                 
humaxtv     270   630   root   20w      REG        8,1 18924699648    2260995 /media/drive1/.tsr/0.ts                                                                                                 
humaxtv     270   631   root   20w      REG        8,1 18924699648    2260995 /media/drive1/.tsr/0.ts                                                                                                 
humaxtv     270   638   root   20w      REG        8,1 18924699648    2260995 /media/drive1/.tsr/0.ts                                                                                                 
humaxtv     270   639   root   20w      REG        8,1 18924699648    2260995 /media/drive1/.tsr/0.ts                                                                                                 
humaxtv     270   640   root   20w      REG        8,1 18924699648    2260995 /media/drive1/.tsr/0.ts                                                                                                 
humaxtv     270   641   root   20w      REG        8,1 18924699648    2260995 /media/drive1/.tsr/0.ts

 

[/df]

What version is that (what does "now" mean)?

I thought it would be helpful to use the word in the generally accepted sense of "at the present time" with the implication that the situation was different at an earlier time. If I use "now" to mean something like "the year 2525", that will be clear in the context.

Specifically, in versions of WebIf from some point after 1.4.0 (webif/cgi-bin/status.jim is also installed as /mod/bin/status.jim):

# git remote -v | grep masterH
masterH https://git.hpkg.tv/hummypkg/webif.git (fetch)
masterH https://git.hpkg.tv/hummypkg/webif.git (push)
# git blame -L 329,337  masterH/master webif/cgi-bin/status.jim
5d3b046c (df 2020-10-22 11:39:37 +0000 329)              # 0 => no TSR; >=2 => TR
5d3b046c (df 2020-10-22 11:39:37 +0000 330)           if {$tsrcnt == 0 || $tsrcnt == 2} {
5d3b046c (df 2020-10-22 11:39:37 +0000 331)                   set s "Watching"
5d3b046c (df 2020-10-22 11:39:37 +0000 332)           } elseif {$tsrcnt == 3} {
5d3b046c (df 2020-10-22 11:39:37 +0000 333)                   set s "Watching (delayed)"
5d3b046c (df 2020-10-22 11:39:37 +0000 334)           } else {
5d3b046c (df 2020-10-22 11:39:37 +0000 335)                   debug "tsrcnt=$tsrcnt"
5d3b046c (df 2020-10-22 11:39:37 +0000 336)                   set s "Not watching"
5d3b046c (df 2020-10-22 11:39:37 +0000 337)           }

So perhaps it's old news.

>... lsof output for the settop program.

That's the key. The command /mod/webif/lib/bin/lsof -Fnsa -p $pid is run where $pid is the process id of the settop program. The script is mainly reporting on the status of that program, ie the OEM PVR functions, although CF background packages are also hooked in via lock files of known names in /tmp.

 

[Black Hole]

I had some glitches last night, but the stats don't look different in any material way and the USB-SATA caddy I'm using has been troublesome before (or maybe the cable, or the USB port on the HD-FOX).

 

[Black Hole]

maybe I'll connect the drive to Windows and see what the Crucial tool says.

Tortuous! First, a 240MB download (@ 2.5 Mbps), then a Windows install (taking a roll-back snapshot first, and the "Crucial Storage Executive" [CSE] is only available for Win64, by the way), then the firewall wanted to block it. It took ages to start up (on my over-worked Win7 system), but at least gave accurate-looking information about my system memory and the installed WD HDD (Crucial want to sell you memory and SSDs!).

Then I plugged in the HD-FOX's SSD-in-caddy, and followed a lengthy wait while it first installed a driver for the adapter and then a driver for the Crucial SSD. But, after all that, I am gratified that a refresh on the CSE control panel showed the SSD's details (but with zero capacity used, because of course it's Ext3 - that seems like a defect to me).

 ID    Description                                      Attribute Data    Units
  1    Raw Read Error Rate                                           0    Errors/Page
  5    ReAllocated NAND Block Count                                  0    NAND Blocks
  9    Power-On Hours Count                                       7352    Hours
 12    Power Cycle Count                                           113    Power Cycles
171    Program Fail Count                                            0    NAND Page Program Failures
172    Erase Fail Count                                              0    NAND Block Erase Failures
173    Average Block Erase Count                                   229    Erases
174    UnExpected Power-Loss Count                                 111    Unexpected Power Loss events
180    UnUsed Reserve NAND Blocks                                   29    BLocks
183    Sata Interface Downshift                                      0    Downshifts
184    Error Correction Count                                        0    Correction Events
187    Reported UnCorrectable Errors                                 0    ECC Correction Failures
194    EnClosure Temperature                                        30    Current Temperature (C)
196    ReAllocation Event Count                                      0    Events
197    Current Pending ECC Count                                     0    ECC Counts
198    Smart Offline Scan UnCorrectable Error Count                  0    Errors
199    Ultra-DMA CRC Error Count                                     7    Errors
202    Percent Lifetime Remaining                                   78    % Lifetime Remaining
206    Write Error Rate                                              0    Program Fails/MB
210    Successful RAIN Recovery Count                                0    TUs successfully recovered by RAIN
223    Total Background Scan Ecc Fail Count                          1    Count
246    Cumulative Host Sectors Written                     29997712302    512 Byte Sectors
247    Number of NAND Pages of data Written by the Host      937428509    NAND Page
248    Number of NAND Pages Written by The FTL              3300669904    NAND Page

So line 246 is cumulative writes in units of 512 byte sectors (allowing that some sectors could be under-occupied), and that brings it vaguely into line for the expected traffic over a lifetime of buffering StDef 24/7 (but maybe still about double):

30x10^9 x 0.5x10^3 / 7x10^3 = 2x10^9 Bytes/hour.

Notice the Crucial tool doesn't express any limits or worst case values, and I wonder how they come to the "78% Lifetime Remaining" figure!

 

[Black Hole]

Notice the Crucial tool doesn't express any limits or worst case values, and I wonder how they come to the "78% Lifetime Remaining" figure!

Hmm. The warranty is 3 years / 80TB, and it's been running for 7352 hours and (apparently) 15TB. 15/80 = 19%, 7352 / 3 x 365.25 x 24 = 7352 / 26400 = 28%.

Nonetheless, it seems I still have all my reserve blocks remaining, so I say the remaining lifetime is indeterminate. I guess once any block fails they'll all start failing.

 

[prpr]

7352 / 3 x 365.25 x 24

7352 / (3 x 365.25 x 24)
What you wrote is just wrong.

 

[Black Hole]

What you wrote is just wrong.

Not wrong, just using a different convention than yours.

 

[prpr]

Not wrong, just using a different convention than yours.

It's non-standard and you didn't tell anybody that you were using it or what it was.
It's wrong.