It’s possible for a certain hardware/software setup not to support a certain codec. For example, my jellyfin client (Finamp) uses the iOS native decoders (afaik), which means opus files are practically broken. My music library (8000+ songs) contained exactly 1 lossy file, which just so happened to be an opus file. I decided to spend the extra ~20MB to standardise my entire library to flac files, ensuring I could play every song on all my devices.

Edit cause I posted too soon: you are generally correct; only in very specific circumstances will you encounter compatibility issues like this one in the modern world. This is 100% apple being apple, and you can expect pretty much every other (reasonably modern) device to support all codecs you might encounter in the wild.

To add to the audio compression: it isn’t possible to further compress an mp3 file without losing any quality. You can either:

1. Recompress to a lossy codec (mp3, aac, opus). This will lead to smaller file sizes if you set the bitrate lower than that of the input file, but it will always worsen the quality, no matter the bitrate.
2. Recompress to a lossless format (flac easily being the best one). Going from a lossy to a lossless format will increase the file size (sometimes by quite a substantial amount), while keeping the same quality. There is very little reason for you to do this
3. keep the original files (my recommendation)

If you’re willing to spend some extra time learning about audio compression, you can download lossless files and compress those directly to whatever format and bitrate you want. The quality will be better than option 1 above, as the audio is only lossely compressed once instead of twice.

YouTube would be smart enough not to advertise Adobe creative cloud in the pre-roll ads of this video, right? Right???

Which compression level are you using? My old server is able to compress flac’s at the highest (and therefore “slowest”) compression level at >50x speed, so bumping the level up shouldn’t be too hard on your CPU.

I’ve been running some external drives on my server for about a year now. In my experience, hard drives with an external power supply suffer less from random disconnects. The specific PC also makes quite a large difference in reliability. My server is just a regular desktop and has very little problem staying connected and powering my 3 external drives. My seedbox is an old laptop, and has been having almost constant problems with random disconnects and power issues. Maybe test how well your framework does with some external drives before committing to the plan?

Have you tried the official guide from the jellyfin website?

As for the guide this AI generated: it bothers me that they instruct you to use chocolatey for the *arrs, but still advice you to install docker, qbittorrent and jellyfin manually (all of which have chocolatey packages). I disagree with the comment that external storage would be recommended, as internal storage is generally more reliable (depending on a lot of factors of course). Also, I believe the “adding a library”-section of the jellyfin setup is a bit too short to be of any use, and would recommend referring to the jellyfin docs instead.

This guide also doesn’t explain how to make jellyfin accessible outside of your LAN. Once again, I’d recommend referring to the jellyfin docs if you want to do this.

I personally have only set up qbittorrent, jellyfin and docker (not the *arr suite), so I can’t comment on the completeness of the guide, but I wouldn’t trust it too much (seeing the previous oversights).

And finally, as someone who started their selfhosted server journey on windows: don’t. There is a reason why almost all guides are written for linux, as it is (in my humble opinion) vastly superior for server usage once you get used to it.

I believe SSD’s don’t actually experience wear when reading data, only when writing. Loading more data from SSD’s shouldn’t cause any premature failure. Overwriting more data each update could cause the drive to fail slightly earlier, but if that’s really that big of a concern, you’d be best of moving to Debian stable (no updates means no SSD writes).

If SSD wear prevention is really that big of a concern, you might be interested in profile-sync-daemon (https://wiki.archlinux.org/title/Profile-sync-daemon). It reduces writes to hard drives by keeping your browser profile in RAM, and only periodically syncing it to disk.

Though I must add that SSD’s wearing out really isn’t that much of an issue with modern drives. With normal usage, a drive will become obsolete long before it actually wears out.

Oh never mind, you’re already using the proprietary driver.

Which GPU do you use? I believe mint defaults to the nouveau drivers for Nvidia GPU’s, which generally has significantly worse performance compared to the proprietary driver.

Not OP (OC? Not the person you were helping, you get what I mean), are you sure you meant df -h? fd -H seems more useful for to me when trying to find a specific file in a dotfolder, though even that didn’t work on my system. fd ignores ~/.config by default, so you need to use fd -u (which is an alias for fd -I -H) to find the correct files.

Anyways, from your description it seems like the correct file would be ~/.config/kwinrc, which exists on my system.

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

https://awesome-selfhosted.net/tags/recipe-management.html

https://awesome-selfhosted.net/tags/task-management--to-do-lists.html

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

You could try adding the __GL_THREADED_OPTIMIZATION=1 environment variable to the custom launch options, it improved performance and lessened bugyness for me.

You could also try to run the launcher with software rendering¹ by editing ~/.paradoxlauncher/launcher-v2.2024.1/Paradox Launcher (you might have to change the version). Try adding --disable-gpu in the last line, between --no-sandbox and "$@"

You could also try disabling gamemoderun. It hasn’t really improved performance in my experience, but has caused some bugs for me. It also muddies the logs.

¹Shamelessly stolen from https://www.protondb.com/app/394360#ju-PgaxbiU

Could you give a bit more information about the hardware and software setup?

• which GPU do your desktop and laptop have? (from what I could find online, the A285 has an iGPU from 2019. I really hope this is wrong)
• wayland or X11?
• hoi4 native or via proton?

I believe I had similar issues on my Nvidia GPU, but resizing the window was a complete fix in my case.

If the installer is small enough (<650MB I believe), you can upload it to virustotal.com to have it be scanned by ~65 antivirus programs

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.

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).

The more you compress the longer and more CPU intensive it is to decompress

I believe this is becoming less and less true with modern algorithms. Take for example ZSTD: while the compression speeds differs by several orders of magnitude between the fastest and slowest modes, the decompression difference is only about 20%. The same holds true for flac, where the decompression speed is pretty uniform across all compression levels.

These algorithms probably aren’t used by repacked like fitgirl (so your answer is generally correct in the context of repacks). I do believe it is still interesting to see these new developments in compression techniques.

I have had decent experiences with TiLP on linux. According to their website, it “can handle any TI calculator (from TI73 to V200) with any link cable.”. Their website also explicitly states support for the NSpire and NSpire-CAS, but the NSpire CX II isn’t mentioned. It might be worth a shot?

If it doesn’t work, the easiest solution would probably be a windows VM with USB-passtrough (which wine doesn’t support as far as I know). You could then use the webapp I linked earlier.

I use the “wakeonlan” package. Simply install it, ssh to your server, and run “wakeonlan xx:xx:xx:xx:xx:xx”, where “xx:xx:xx:xx:xx:xx” is the Mac-adres of the PC you’re trying to wake.

If I understand your post correctly, you have 2 PC’s at home: one running wireguard, and one you want to wake using WoL. This is similar to my setup, where I have a server and a personal desktop. When I want to wake my PC remotely, I just ssh to the server and use the server to wake the desktop. Connecting to the server and telling it to wake your PC seems easier than trying to redirect your phone’s WoL app over wireguard.