avidamoeba

This is true but it’s nice to have the whole app, data and database in one place, going together, snapahotted together, backupable together. It’s slower for sure. With a large pool (more disks) and especially with the magic of SSD cache, database reads fly and reads are the majority of the loads in my heads. In the future I would put root on ZFS as well and either do SSD cache or have root on ZFS SSD pool that gets send/recved regularly onto the spinning pool so it’s easy to restore when needed.

Thanks for looking into it. As far as I read they moved to an ORM with 10.11 as a prereq to supporting other db engines. I’m guessing the db connection code would be undergoing major changes when they do that so I wouldn’t rewrite the current implementation. I’d either follow that work and help them get it right or rework the implementation after they’re done. We’ll just suffer through the mean time. 😄

64K is generally small recordsize. For media they recommend 1M. My db was sitting on the default 128K recordsize and perforned fine on 10.10. It doesn’t matter much for reads because ZFS keeps it in RAM and if it gets evicted it goes into SSD cache (l2arc). But for writes the cache wouldn’t help unless I disable sync which risks data loss. I don’t think 10.10 did much writes during lib scan so write perf only mattered when something changed.

Not sure if this is the problem I was hitting with my Home Videos library type. It’s got directories with YouTube videos. I tried re-adding it in 12-rc3, which was released a month after the nightly mentioned in the issue thread. Still couldn’t complete. I ended up re-adding the media as Shows library. Works okay with the directory structure I have.

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.

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

600MB. Would that require changes to Jellyfin? They’re on the path to introducing Postgres support.

Complications, yes!

With great power come great … uuh … :D

Immich

Soma

Folks who’ve used Linkwarden and archivebox, which do you prefer? Is one a superset of the other?

This, make a partition thats a few gigs smaller than the drive, add the partitions to the storagr pool instead of the raw drives.

Don’t think about drives in terms of reliability. Consider them a consumable in your storage system. The storage system should insulate you from the exact drives. Run a ZFS mirror or RAIDz2. Swap drives when they fail. The exact brand and model shouldn’t matter.

As always the social infrastructure (community, user base) is much more important for the success and use value of a piece of software than the exact technology used to make it (lang, framework, helper tools).

The upgrade was pretty trivial from 2.7.5. Minimal changes in the docker compose file if your was up-to-date on 2.7.5. Mostly version changes. No changes needed to .env other than going to v3.

Ahahaha, nice. Reminds me of how we looked at implementing share-to-app (when that was a novel thing) in a mobile OS circa 2011 and we looked at how iOS did it. It was a list of hardcoded targets - Facebook, Twitter. No pluggability no nothing. Our product team was like - if no pluggability is good enough for Apple, it’s good enough for us!

Restricted access? Am an Android user since 2008 and never had an iOS device.

Wait for 3.0.3 and then the emergency 3.0.4. 😅

That’s probably coming too. This is the first preview of the feature.

Sounds like you should self-host Nextcloud with Tasks and Tasks.org on your phone. 😄

Migration guide - immich.app/blog/v3-migration.

docker compose up!

RAIDz2 for 5.5TB with 2-disk redundancy.

Coud probably be done. Find publicly shared Immich albums -> sync to Google Photos -> share publicly -> write the public Google Photos URL to the metadata of the Immich album.

It is but it requires public internet access to the Immich instance, or everyone involved being on our VPN. Reusing someone else’s publicly facing service to share photos from a private Immich instance is a clever workaround.

Time to setup an arr stack.

I think self-hosting has the expectation of the ability to self-host for indefinite period of time. E.g. I can run Jellyfin 10.10 for as long as I have the hardware and willingness to run it. A proprietary piece of software, say Plex, could technically allow that too, but that’s much less likely. Since I can’t see its source code, I can’t know if there’s a time bomb that stops it from working at some future date. Or an update/remote procedure I don’t know about that asks me to pay $750 at some point to continue using it. Which could preclude me from being able to continue self-hosting it. Is the ability to self-host indefinitely an expectation everyone shares? Probably not. Probably worth thinking about in this context though.