Maxy

@Maxy@lemmy.blahaj.zone

• ⁨Comment⁩ on ⁨Would you buy "self-hosted in a box" hardware?⁩ ⁨⁨2⁩ ⁨months⁩ ago⁩:

  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?

• ⁨Comment⁩ on ⁨Would you buy "self-hosted in a box" hardware?⁩ ⁨⁨2⁩ ⁨months⁩ ago⁩:

  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)

• ⁨Comment⁩ on ⁨Data HDD with SSD catch drive⁩ ⁨⁨2⁩ ⁨months⁩ ago⁩:

  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.

• ⁨Comment⁩ on ⁨Data HDD with SSD catch drive⁩ ⁨⁨2⁩ ⁨months⁩ ago⁩:

  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)

• ⁨Comment⁩ on ⁨[deleted]⁩ ⁨⁨10⁩ ⁨months⁩ ago⁩:

  You could look at the awesome-selfhosted list, specifically these two sections:

  awesome-selfhosted.net/…/recipe-management.html

  awesome-selfhosted.net/…/task-management--to-do-l…

  I don’t have any experience with any of those, but there might be something that fits your needs.

• ⁨Comment⁩ on ⁨File size preference for Radarr?⁩ ⁨⁨10⁩ ⁨months⁩ ago⁩:

  Ah, it looks like we have a small misunderstanding. I thought you were talking about uncompressed video, which is enormous. This is only used in HDMI cables for example. A 1080p60 uncompressed video is 2.98Gbit/s, or about 1.22 terabytes per hour.

  A remux is “uncompressed” in the sense that it isn’t recompressed, or in this case transcoded. A remux is still compressed, just to a lesser degree than a transcode. This means the files are indeed larger, but the quality is also better than transcodes.

  To clarify the article’s confusing statement: they claim that remuxes can reduce size by throwing away some audio streams, while keeping the original video. This is true, but the video itself hasn’t gotten any smaller: you are simply throwing away other information.

• ⁨Comment⁩ on ⁨File size preference for Radarr?⁩ ⁨⁨10⁩ ⁨months⁩ ago⁩:

  Remuxes aren’t uncompressed, nor are they losslessly compressed. They’re just a 1:1 direct copy from some other medium (generally blu-rays or DVD’s).

• ⁨Comment⁩ on ⁨klay’s simple cookbook for Linux, v0.9.0⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  No problem! It actually seems like a great guide, especially for beginners, I might link it to some friends.

• ⁨Comment⁩ on ⁨klay’s simple cookbook for Linux, v0.9.0⁩ ⁨⁨1⁩ ⁨year⁩ ago⁩:

  Just out of curiosity, are you sure “fd” is the right command in the “format storage” section? I don’t have a rasbian system to test this on, but on my arch system, “df” is used to list disks; “fd” is a multithreaded version of “find”, which I manually installed.