Domi

I have exactly the setup you described, a Raspberry Pi with an 8 TB SSD parked at a friend of mine. It connects to my network via Wireguard automatically and just sits there until one of my hosts running Duplicati starts to sync the encrypted backups to it.

Has been running for 2 years now with no issues.

This had terrible consequences

Ha, they never learn. They also blocked most of Cloudflare in Austria a few years back.

Fun fact: It was the first IP block they tried. They haven’t tried again since then.

https://blog.cloudflare.com/consequences-of-ip-blocking/

Did anything ever come from this? I imagine that any of the railway companies affected would want to sue?

Not much possibility for argumenting about security reasons either when you literally have the GPS coordinates of your competitors in your code.

That’s less of an opinion and more of a hardware restriction, isn’t it?

If I had a 5 Mbps connection or no display that can display 4k, I also would not download in 4k.

That is what I’m doing currently but now unbound doesn’t talk to the root servers anymore, it sends all queries to Quad9.

Both scenarios are not ideal because you always end up with one entity knowing all your queries.

Not illegal but it leaves all your DNS lookups in plain text with your ISP, which just doesn’t sit right with me.

Not that the ISP in my country would care.

Is it possible to get unbound to talk to the root servers via TLS/HTTPS by now?

I’m currently using Quad9 because they support DNS over TLS and DNS over HTTPS.

Do a library rescan on your music library and then download the latest Finamp beta from here: https://github.com/jmshrv/finamp/releases

Lyrics should work then:

@[email protected]

Check out Picard, I switched to it when I switched to Linux: https://flathub.org/apps/org.musicbrainz.Picard

I tried Jellycon briefly when I started but it’s unfortunate that it doesn’t integrate into the Kodi UI properly, so there’s no way to really use the Kodi interface nicely without casting from the Jellyfin app. It more or less just becomes a playback client for the Jellyfin app. If the Jellyfin app wouldn’t be such a disaster when casting I probably would be fine with that.

Might try it again in the future but the Jellyfin app experience is nothing like what Kore or Yatse can do directly with Kodi.

CoreELEC is community maintained and the N2+ still receives the latest builds, my last update was just last month.

However, CoreELEC can be installed on many devices (including some Android TV boxes) that have Amlogic chips. You can see a full list if you to to the download page on the CoreELEC page https://coreelec.org/.

Also, CoreELEC is not Android, it is Linux running only Kodi. If you need anything besides Kodi you might want to look at another solution or have multiple devices.

Kodi still plays via SMB/NFS when configured in direct play mode. Only the metadata is provided via Jellyfin and play progress is synced to Jellyfin.

The Jellyfin plugin is not the most stable piece of software but it gets the job done.

I have been using an Odroid N2+ with CoreELEC installed and the Jellyfin Kodi plugin for years now.

Plays pretty much everything you throw at it, including 4k HDR HFR.

Dolby Vision is supported in CoreELEC but only on some devices.

because the rain sensor doesn’t seem to do jack shit in a Tesla

That’s because they saved 70 cents and don’t have rain sensors, they use “AI” image recognition to detect rain and snow.

It works as well as it sounds.

Is that a real Deezloader website? That website looks shady af.

I don’t run Pi-hole but quickly peeking into the container (docker run -it --rm --entrypoint /bin/sh pihole/pihole:latest) the folder and files belong to root with the permissions being 755 for the folder and 644 for the files.

chmod 700 most likely killed Pi-hole because a service that is not running as root will be accessing those config files and you removed their read access.

Also, I’m with the guys above. Never chmod 777 anything, period. In 99.9% of cases there’s a better way.

They have a different architecture so it comes down to preference.

Docker runs a daemon that you talk to to deploy your services. podman does not have a daemon, you either directly use the podman command to deploy services or use systemd to integrate them into your system.

I just built the Vulkan layer and gamescope from git and then started my native Steam installation normally. Then I just set the launch parameters to ENABLE_HDR_WSI=1 gamescope --hdr-enabled --hdr-debug-force-output --nested-refresh 165 --fullscreen --steam --output-width 3440 --nested-width 3440 --output-height 1440 --nested-height 1440 -- env ENABLE_GAMESCOPE_WSI=1 DXVK_HDR=1 DISABLE_HDR_WSI=1 %command%.

Works pretty well so far but I’m on AMD.

Which monitor do you have? ABL is unfortunately fairly aggressive on OLED screens, e.g. my screen only reaches about 250 nit with a 100% white window, which is only 10-20 nit brighter than the maximum for SDR content.

I can’t speak for Star Wars but Dune is pretty bright so you might just run into your monitors ABL very easily. You can test by making mpv really small against a black background and then maximizing. If the image gets dimmer you’re getting limited by ABL.

You might want to grab a 4k remux for something like The Greatest Showman or Spider-Man: Across the Spider-Verse to benchmark with. They have a lot of colorful but dark scenes to really bring out the HDR highlights.

I’m also using Plasma 6 to play games and watch movies in HDR and everything looks as expected.

What monitor/TV do you use? Did you install the necessary Vulkan layers? Do you use mpv with the correct parameters? Which movies/scenes?

You can try turning the SDR brightness all the way down and back up. If the brightness of mpv changes, you’re not running in HDR.