Avid Amoeba

@avidamoeba@lemmy.ca · Joined ⁨Jul⁩ ⁨2023⁩

Replying to @⁨Strit@lemmy.linuxuserspace.show⁩

That would be reasonable. I did repeated rescans and only counted subsequent rescans. For me the initial scan after upgrade took a bit more but not hours. Subsequent scans took less. E.g. 20min -> 13min for write-optimized filesystem. So that’s reasonable, although 10.10 was way faster. Library scans are expected to get faster in 13 according to some Github threads I read.

When I had the broken Home Videos library I waited 3 days for the initial scan to complete and it did not. Repeated rescans did not seem to complete although I didn’t wait 3 days for them. I’m not taking into account those scan times. Something was wrong with this library type on 10.11 and/or my media. Worked fine on 10.10.

Replying to @⁨ragebutt@lemmy.dbzer0.com⁩

I came up with a funny strategy I use to lock it down a bit. What’s exposed to the internet for me is Apache2 reverse proxy. The proxy is locked down to reject all connections EXCEPT for the ones coming from a special subdomain which is something like a 64-character long random string. This prevents pretty any unwanted connections. Obviously the special subdomain must remain as secret as a shared password among the Jellyfin users. It works for trusted users.

What I want ideally is an “authenticated firewall.” OpenWrt rejecting all connections on the open port except for an allowlist of IPs. Then there must be a system where users can authenticate and their IP is added to the allowlist. I haven’t found an off-the-shelf solution like this but I’ll make it some day. Too bad I figured this random string subdomain trick cause it seems good enough for now. :D

posted in Selfhosted

Improve very slow library scans on Jellyfin 10.11 / 12 on spinning media

I’ve been trying to upgrade from 10.10 to 10.11 for a while now, as the Android TV app keeps nagging me, and every attempt ended with impossibly long library scan times.

After some thorough investigation, it appeared that a Home Videos type collection causes unending scan (yet to be solved), but also that Jellyfin does a lot of writes to the config directory (either database or metadata or both). Mine’s on spinning media part of a ZFS pool. I tried a few performance tuning options, such as testing the config dir with recordsize (similar to block size) of 4K, 8K, 64K, 128K and library scans fell from 30-40 minutes down to 8-13min with 4K-64K. The ZFS tuning wiki suggest 64K recordsize with LZ4 compression for SQLite workloads such as Jellyfin. That seems to work as well as 4K and 8K but likely is faster when reading thumbnails and such.

Note that upgrading to 12-rc3, which is supposed to speed up library scans did not improve scan times for me. Optimizing config/database write speed did. I cross-checked the culprit by experimenting with moving the config dir to NVMe and RAM. Both of those got the scan times down to 8-9 minutes compared to the optimized spinning media’s 12-13.

So if you had upgraded (or about to) to 10.11 your library scans are (about to get) dog slow and your Jellyfin’s config dir resides on spinning media, optimize its write performance for SQLite.

Replying to @⁨eicker@lemmy.world⁩

The shovel maker disagrees. This gon be gud.gif 😂

Implicator.aiHuang Defends Chinese AI Models After Bessent Sanctions ThreatNvidia's Jensen Huang said American companies should be allowed to run Chinese open-weight models, hours after Treasury Secretary Scott Bessent threatened sanctions over model distillation. Moonshot releases the full Kimi K3 weights by July 27.