@Wilson.Wang Perhaps the developer will find a way in Streamfab 6 or 7 to optimize the processing or remuxing so that fewer disk writes occur. My Streamfab hard drive is now dead. [upl-image-preview uuid=a494316c-2e75-433f-bd24-5f6966e32b38 url=https://forum.dvdfab.cn/assets/files/2025-11-16/1763306001-223600-image.png alt={TEXT?}]

SSD Bad

Sebastian001

@Wilson.Wang Perhaps the developer will find a way in Streamfab 6 or 7 to optimize the processing or remuxing so that fewer disk writes occur.

My Streamfab hard drive is now dead.

0xFeedBeef

Sebastian001 isn’t 512GiB Intel Pro 6000p rated for something stupidly low like 72TB of lifetime writes? and it looks like the firmware in it was never updated (I doubt HP is still on firmware release 1 for that, and do they still think that trim is overrated? I was so done with them when they proudly stated that their enterprise SAS SSDs didn’t do unmap)

TL;DR: cheap TLC SSD, rated as READ-intensive, not expected to last by any measure. 🤷‍♂️

0xFeedBeef

Wilson.Wang just tried with a 4K download from D+, download, remux, and playback seem absolutely fine! Now I can move away from my 500GiB RAM disk 😏

Sebastian001 provided that “available spare” and “available spare threshold” are reported correctly, you can safely ignore the “percentage used” that’s no more than a “best before” date for gullible customers- it’s not like the SSD is gonna turn into a pumpkin at the turn of midnight 😉 It’s just a value based on statistical modelling…

The problem with SSD drive wear is that you lose ability to program a cell, not read its value (well, within limits). So when you fail to program a cell, you just use a spare block, so so long as you have those to go (recall that the SMART-reported values are normalised (100%)), you’re fine; it’s when you start eating into them and they get close to the available threshold that you need to start thinking about replacing. In your case, you actually are already eating into the available spare (your counter is at 0×54, or 84%) and that’s probably being down to it being TLC. In my case, and I’m using MLC, I’m at 120% (0×78) “used” on my boot drive, and it’s still not touched a spare block… 👇

simchris

perhaps add second hdd for archive purposes, or use better brand of nvme like WD black. no issues here

Sebastian001

simchris Well, every SSD eventually fails, regardless of the manufacturer…and an HDD for Streamfab isn’t an option, that takes way too long.

Dado29

My D: drive, which I use for downloading, was like this a year ago when I designated it for that purpose. Be sure to turn off defragmentation in Windows.

Btw, try HDD Regenerator

simchris

Sebastian001
"too long’ ? Using 10TB WD BLACK HDD as my scapegoat drive and download high speed every day of the week, going back to January. Writing all my temp/cache files to that drive as well. Zero issues. Just my opinion. My gen4 2TB NVME WD Black boot drive doing just fine, at 100% health.

To be clear, I’m writing to MKV only, 1080p 5.1; and 4K on the couple of sites supporting that.

Sebastian001

It’s the original one that was in the device when I bought it… I’ve now decided on a Seagate FireCuda 530R 1TB…

Sebastian001

When I think of Redfox now, I remember the processing took less than a second…they solved it differently…

0xFeedBeef

Sebastian001 they used a different set of tools…

BUT what SF can do is at the very least have a switch that disables the daft faststart flag of ffmpeg, or make that a registry key so the lowest common denominator has faststart switched on, and those who want it switched off (and know the potential consequences) can have a means of disabling it.

Wilson.Wang

0xFeedBeef

https://dl.dvdfab.cn/download/StreamFab_x64_6263official_2025_11_17_17_44_39_utility_tool_dev_disablefaststart_streameta_dev_vs2019_d43046fa.exe

A test version that disable the ffmpeg faststart.

You can check it first.

Wilson

Germania

Wilson.Wang A test version that disable the ffmpeg faststart.

You can check it first.

I can’t download mp4 files from Amazon with the test version - always error 702
Same queue, account + connection works fine with 6263 release

old ffmpeg cmdline works .. -disposition:a:0 default -movflags faststart+disable_chpl
new ffmpeg cmdline fails: .. -disposition:a:0 default-movflags +disable_chpl

Therefore the superfluous + must be removed - result with +disable_chpl
Unable to choose an output format for '+disable_chpl'; use a standard extension for the filename or specify the format manually Error initializing the muxer for +disable_chpl: Invalid argument\r\nError opening output file +disable_chpl

MrGrackle

The OP has a very valid point. When I was using a regular HDD as the temp and download folder, the drive noise was horrendous. Moving it to a spare SSD simply made the noise go away, but the constant IO is still happening.

To those out there ready to point out “Get a better drive” — Samsung has the best drives out there.

0xFeedBeef

MrGrackle with the new beta that gets rid of the faststart, you can actually have the output directory point to a spinny drive (even an SMR one 😱), and buy an el cheapo SSD that you’re willing to bin after a year or two for your temp directory 😉

MrGrackle

0xFeedBeef with the new beta that gets rid of the faststart, you can actually have the output directory point to a spinny drive (even an SMR one 😱), and buy an el cheapo SSD that you’re willing to bin after a year or two for your temp directory 😉

What’s amazing is if you look at the way back history, I reported massive disk access and compared the RF program not needing to do it. I guess all it took was someone to report a bad drive from it.

Different topic… LOL, the binary is close to 50 Mb less than the official release. It’s funny how much fluctuation there is from version to version.

Having just installed the prerelease in this thread, the “Loading task queue” went much much faster. I can have zero items in the history and it could take 20 seconds sometime.

Oh, and the suggestion to disable optimization in Windows… Windows does not optimize SSDs. It will TRIM them but only if you tell it to.

0xFeedBeef

I think the problem is that several years back, MLC SSDs were fairly common, even eMLC ones, and you could hammer them without a thought (22nm eMLC was a “forever” disk), nowadays, SSDs are literally at the boundary of “life”- you don’t even have the time to fart, and it’s time to replace the darn thing!

Ok, so I’m not the only one who noticed that the beta feels way snappier than the official release then, @Wilson.Wang ! 👍

Sebastian001

Just to make sure I understand correctly, with the translation… Without Fast Start, fewer hard drive accesses are performed?🤔

0xFeedBeef

Sebastian001 essentially, yes, it’s one fewer almost complete write to the output directory

edit: obviously it’s completely inconsequential if you’re outputting to MKV files

MrGrackle

Sebastian001 Just to make sure I understand correctly, with the translation… Without Fast Start, fewer hard drive accesses are performed?🤔

Yes.

Reminds me of Windows 11. Fast Start DISABLED and Windows boots up FASTER.
Fast Start DISABLED takes about 12 seconds after the Bios posts. ENABLED takes between 35-45.

Sebastian001

0xFeedBeef MP4 😉

0xFeedBeef

Germania is it just Amazon, or are you having issues with others? I’m downloading fine with D+ & NF…

KidJoe faststart only affects MP4 output

Germania

Germania
old ffmpeg cmdline works .. -disposition:a:0 default -movflags faststart+disable_chpl
new ffmpeg cmdline fails: .. -disposition:a:0 default-movflags +disable_chpl

Therefore the superfluous + must be removed - result with +disable_chpl

After taking a closer look at the logs:

D+ -strict unofficial -movflags +disable_chpl
NF -strict unofficial -movflags +disable_chpl

I have to correct my error analysis; the (unneeded) + is not the problem
at Amazon, but rather the missing space between default and -movflags