Unless your initial recordings were lossless (they probably weren’t), recompressing the files with a lossless flag will only increase the size by a lot. Lossless video is HUGE, which is why almost no one actually records/saves it. What you’re probably looking for is visually lossless transcoding, where you do lose some data, but the difference is too small for most people to notice.

My recommendations:

1. Go to your recording software and change the setting to better compress your videos the first time around. Compressing once generally gives a better quality to size ratio than compressing twice. It’s therefore best if your recording software get it right first time, without you having to keep on recompressing your videos.
2. When tinkering with encoding setting, trying to find what works best for you, it might be useful to install Identity to help you compare the original files and one or more transcoded version(s).
3. Don’t try to recompress the audio; you’ll save very little space, and the losses in quality become perceptible much faster than video. When using ffmpeg, the “-c:a copy” flag should simply copy the original audio to the new file, without any change in quality or size
4. I’d recommend taking some time to read through the ffmpeg encoding guides. H265 and AV1 are good for personal archiving, with AV1 providing better compression ratios at the cost of much slower encoding. You could also choose VP9, which is similar in compression ratio and encoding speed to h265.
5. You’ll have to choose between hardware and software encoding. Hardware encoding can (depending on your specific hardware and settings) be 10-100x faster than software, but software generally gives better compression ratios at similar qualities. You should test this difference for yourself and see if the extra time is worth it for the extra quality. Do keep in mind that AV1 hardware encoding is only supported by some of the most recent GPU’s (rx7000 and rtx4000 from the top of my head). If you don’t have one of those GPU’s, you’ll either have to choose software encoding or pick a different codec.

Source: Gapminder, cited as source by the above graph as well

Funny how much the graph changes when you have more than 1 data point per decade every decade. Almost makes me wonder whether the creator of the above graph was trying to paint a certain picture instead of presenting raw data in a way that makes it easier to grasp, without bias.

Notice the inflection point where Mao implements the “great leap forward”. Also notice other countries’ similar rates of increasing life expectancy in the graph below, just without the same ravine around 1960.

I’m sorry, but I have to disagree with (what I think to be) your implicit claim that Mao somehow single-handedly raised China’s life expectancy through the power of communism or whatever. Please do correct me if this wasn’t your implicit claim, and if you we’re either 1) yourself mislead by the graph you shared, or 2) you have some other claim entirely that is somehow supported by said graph.

You mean deeper than Lviv, which they have been striking from day 1 of the invasion? How much deeper can Russia still strike?

Luxury! My homeserver has an i5 3470 with 6GB or RAM (yes, it’s a cursed 4+2 setup)! </badMontyPythonReference>

Interesting, I also run Nextcloud and pihole, and vaultwarden, jellyfin, paperless-ngx, gitea, vscode-server and a minecraft server (every now and then).

You’re right that such a system really does show its age, but only when doing multiple intensive tasks at the same time. I try not to backup my photos to Nextcloud while running minecraft, for example, as the imagine identification task pins my CPU at 100%. So yes, I agree, you’re probably not doing anything out of the ordinary on your setup.

The point I was trying to make still stands though, as that pi 2B could run more than I would’ve expected beforehand. I believe it once even ran jellyfin, a simple file server, samba, and a webserver with a simple HTML website. Jellyfin worked just fine, as long as the pi didn’t have to transcode (never got hardware transcoding to work).

It is funny that you should run out of memory, seeing as everything fits (albeit, just barely) on my machine in 1/5 the memory. Would de overhead of running VM’s account for such a large difference?

Coming from someone who started selfhosting on a pi 2B (similar-ish specs), you’d be surprised. If you don’t need anything fast or fancy, that 1GB will go a long way, and plenty of selfhosted apps require very little CPU. The only real problem I faced was that all HTTPS-related network tasks were limited at ~3MB/s, as that is how fast my pi could encrypt the data (presumably, I just saw my webserver utilising the entire CPU and figured this was the most likely explanation)

It depends what you’re optimising for. If you want a single (relatively small) download to be available on your HDD as fast as possible, then your current setup might be better (optimising for lower latency). However, if you want to be maxing out your internet speeds at all time and increase your HDD speeds by making the copy sequential (optimising for throughput), then the setup with the catch drive will be better. Keep in mind that a HDD’s sequential write performance is significantly higher than its random write performance, so copying a large file in one go will be faster than copying a whole bunch of random chunks in a random order (like torrents do). You can check the difference for yourself by doing a disk benchmark and comparing the sequential vs random writes of your drive.

qBittorrent has exactly the option you’re looking for, I believe it’s called “incomplete download path” in the settings, letting you store incomplete downloads at a temporary path and moving them to their regular location when the download finishes. Aside from the download speed improvement, this will also lead to less fragmentation on your HDD (which might be part of the reason why it is so slow when downloading directly to it). Pre-allocating space could have the same effect, but I would recommend only using one of these two solutions at once (pre-allocating space on your SSD would only waste space)