The purpose of the TEMP folder is to do all the temporary work, not just part of it, and only when the final result is ready, to move the final result into the destination folder (and if the creation of the final file encounters an error, that erroneous file doesn't pollute the final destination folder) using platform API. This is how we programmed in 90s, it's resilient and time-tested... (and if the TEMP and the final destination folder are on the same disk, platform API doesn't actually move data, but simply changes directory entries as needed).
Think of it this way: you assemble a car on an assembly line in a factory, and only once the car is fully assembled, you move a complete car to a showroom for the customer to collect; you don't stream a collection of parts to a showroom and assemble the car in front of the customer...
What StreamFab is doing now is downloading and decrypting in the TEMP folder (local ramdisk in my case), but actually creates the final file in the destination folder. Not only that, but given that ffmpeg is written by rank amateurs who not only can't read the ISO spec, but also can't figure out that you can trivially do MOOV atom at the head of file in a single write pass if the entirety of the source is already available, StreamFab ends up "creating" the final file twice (and either pass can fail).
StreamFab insist (no option of turning it off) that the MOOV atom must be at the front of file (utterly unnecessary save for rare cases), so the brain-dead ffmpeg writes out a dummy version to the final destination folder, then writes out the final version over it... and it does so in tiny little chunks wasting everyone's time. So not only do you end up spending more than twice the time processing over RSS SMB as the download itself (see graph), but you're also wasting at the very least 2x writes on your SSD (and that's not counting the enormous write amplification you get from committing tiny chunks of data to disk. Even with my enterprise-grade eMLC SSDs that are rated at 45DWPD, I'm measuring below 15DWPD with write amplification due to StreamFab (and yes, that's the only thing reading and writing to that disk). I dare not think how fast consumer TLC SSD get burned through!
The app is great, but it's wasting customers' money on things that it shouldn't do, worse yet, it literally takes under ten minutes worth of effort to fix it! C'mon guys, you could do better!
PS: yt-dlp, for example, uses -P "temp:..." correctly.
Think of it this way: you assemble a car on an assembly line in a factory, and only once the car is fully assembled, you move a complete car to a showroom for the customer to collect; you don't stream a collection of parts to a showroom and assemble the car in front of the customer...
What StreamFab is doing now is downloading and decrypting in the TEMP folder (local ramdisk in my case), but actually creates the final file in the destination folder. Not only that, but given that ffmpeg is written by rank amateurs who not only can't read the ISO spec, but also can't figure out that you can trivially do MOOV atom at the head of file in a single write pass if the entirety of the source is already available, StreamFab ends up "creating" the final file twice (and either pass can fail).
StreamFab insist (no option of turning it off) that the MOOV atom must be at the front of file (utterly unnecessary save for rare cases), so the brain-dead ffmpeg writes out a dummy version to the final destination folder, then writes out the final version over it... and it does so in tiny little chunks wasting everyone's time. So not only do you end up spending more than twice the time processing over RSS SMB as the download itself (see graph), but you're also wasting at the very least 2x writes on your SSD (and that's not counting the enormous write amplification you get from committing tiny chunks of data to disk. Even with my enterprise-grade eMLC SSDs that are rated at 45DWPD, I'm measuring below 15DWPD with write amplification due to StreamFab (and yes, that's the only thing reading and writing to that disk). I dare not think how fast consumer TLC SSD get burned through!
The app is great, but it's wasting customers' money on things that it shouldn't do, worse yet, it literally takes under ten minutes worth of effort to fix it! C'mon guys, you could do better!
PS: yt-dlp, for example, uses -P "temp:..." correctly.
Attached Files
Comment