You bookmark something brilliant mid-unit, move on, and by the time you’d actually use it again the unit’s finished, the term’s changed, or you’ve moved year levels entirely and it’s sitting three folders deep in a browser bookmarks bar that’s really just a graveyard sorted by the order you found things in. The resource never went anywhere. Your ability to find it again did. So I built Edu Links: a small, static site that’s nothing but curated links, organised by subject, searchable, and boring enough on purpose that I’ll actually keep it current.

What it actually is

Not a bookmarking app, not a CMS, nothing to log into. It’s a Jekyll site – one YAML file (_data/links.yml) holding every link, grouped by subject and then by sub-area, rendered as cards with a logo, a name, and a one-line description of why it’s useful rather than just what it is. Right now that’s 101 links across six subjects – Maths, Literacy, Class Utilities, Research, PYP, and Christian Studies – split into 30 sub-areas like fluency_and_number_facts and atl_skills.

Adding a link means editing one file: a name, a url, a description under the right subject and sub-area, commit, and GitHub Actions rebuilds the site. No admin panel, no database, nothing else to think about.

The small stuff that took longer than the big stuff

Card logos are fetched automatically from each site’s favicon – one less thing to source and upload by hand. But favicons fail: a 404, a school network’s content filter blocking the request, whatever. An onerror handler on the image quietly drops it and falls back to a letter tile instead of a broken-image icon. Simple enough, until two failed favicons that happen to share an initial letter render as identical tiles, and a page full of “these look like copies of each other” is worse than no logos at all. The fix isn’t randomness – that would make cards flicker between colours on every rebuild – it’s a cheap deterministic hash of the link’s name and domain, spread across a small palette, so the same link always lands on the same tile colour but a different link with the same initial lands on a different one.

Headings needed their own small fix too. Sub-area keys are snake_case (atl_skills, inquiry_and_planning), turned into display headings automatically – which is fine until an acronym runs through the same title-casing logic and “ATL” becomes “Atl”. An acronyms list in _config.yml (ATL, PYP, IB, STEM, STEAM, ICT, BTN, PZ) keeps those fixed, matched on whole words only, so “atlas” doesn’t get mangled into “ATLas” along the way.

Search, without needing a server

Every link is also written into a generated search.json at build time, and a small vanilla-JS script searches it client-side – press / from anywhere on the site, the way most docs sites work, and it searches every subject at once rather than just the page you’re on. It’s progressive enhancement on purpose: if the script fails to load for any reason, the site still works exactly as well as it did before JavaScript existed, you just browse by page instead of searching.

Built over a weekend

Scaffolded Saturday, real content and the search/UI pass on Sunday – empty repo to a live, searchable site in a weekend, which is about the right level of ambition for a resource hub. It doesn’t need to be clever. It needs to still be useful next term, and the term after that, once I’ve completely forgotten I ever found half of what’s on it.

Repo’s at andrew-snape/edsites if you want to see how it’s put together, or steal the favicon-fallback trick for a link dump of your own.

Andrew

Here is how that half is put together.

Music: Lidarr, slskd and Soularr

Lidarr handles the library and knows what is missing. What it is not especially good at is finding things, at least not the older, more obscure and more Australian end of what I listen to. Usenet and torrent indexers tend to carry the big releases and not much else.

Soulseek covers that gap better than anything else I have tried, because it is people sharing their actual collections rather than an index of scene releases. The problem is that Soulseek is a chat-era desktop client, not something you point a *arr at.

Three containers solve that:

• slskd is a headless Soulseek daemon with a web UI and, crucially, an API.
• Soularr is the glue. It polls Lidarr for missing albums, searches slskd for them, downloads what matches, and hands the result back to Lidarr to import.
• Lidarr itself, on the nightly tag, because the music side of the *arr family moves slower and the stable builds lag further behind than they do for TV and film.

Soularr runs on a five minute loop:

environment:
  SCRIPT_INTERVAL: "300"

The settings that actually mattered

Most of Soularr’s config is fine at defaults. Three lines were not.

The first is format. I originally allowed MP3 as a fallback and regretted it, because “available” and “worth keeping” are different questions and MP3 kept winning on availability:

# FLAC preferred, AAC (.m4a/.aac) as fallback. No MP3.
allowed_filetypes = flac 24/192,flac 16/44.1,flac,m4a,aac

Dropping MP3 entirely means some albums simply do not get grabbed. That is the correct outcome. They sit in Lidarr as missing until someone shares a better copy, which on Soulseek happens more often than you would expect.

The second is match strictness. Soulseek filenames are whatever the sharer felt like that day, so a loose match will cheerfully import a live bootleg as the studio album:

minimum_filename_match_ratio = 0.8
failed_import_denylist = True

The denylist is the important half. Without it, a release that fails to import gets found again on the next pass, fails again, and loops forever.

The third is the download path, and it is the whole point of the post about the single mount:

# Same folder as before, but reached via Lidarr's /data mount so it sits on the
# SAME filesystem as the root folder (/data/Music) -> instant hardlink import.
download_dir = /data/downloads/complete/slskd

Same folder on disk, expressed through Lidarr’s /data mount rather than a separate one, which turns the import from a copy into a hardlink.

The ALAC era, and why it ended

Digging through the Lidarr config folder to write this, I found the previous version of my answer to the format question, and it was the exact opposite one. extended.conf still says:

audioFormat="alac"    # Set this to ALAC (Apple Lossless Audio Codec)
requireQuality="true"  # Enforces ALAC and lossless format during conversion

alongside three shell scripts whose entire job was to walk the library, convert every FLAC to ALAC with ffmpeg, and delete the original.

The reasoning was sound at the time. This is an all-Apple house, and for years iOS simply would not play FLAC. ALAC is also lossless, so converting between the two costs nothing in quality, and it meant everything played everywhere without thinking about it.

What changed is that the problem went away. Modern iOS handles FLAC, and Plex and Audiobookshelf both transcode on the fly anyway. Rewriting the entire library to solve a compatibility problem that no longer exists is pure churn, so now Soularr fetches FLAC and it stays FLAC.

The scripts are worth keeping around as a warning, though. Here is the business end of the newer one:

find . -type d -name "@eaDir" -prune -o -type f -iname "*.flac" -print0 | \
  xargs -0 -P 4 -I {} bash -c '
    ...
    if ffmpeg -nostdin -y -i "$file" -vn -acodec alac "$output"; then
      rm "$file"
    ...

Four parallel ffmpeg jobs, each deleting the source the moment the encode returns zero, across the whole music library, with no dry run and no way to undo it. Compare that to the audiobook script further down this post, which defaults to printing what it would do and moves duplicates aside rather than deleting them. Same author, same NAS, about eighteen months apart. The difference is entirely that in between I had a script do something I did not expect on a folder I cared about.

Those files are still sitting in the config folder. That is fine while they are only ever run by hand, but “a destructive script with no dry run, left lying about” is exactly the sort of thing that is fine right up until it is not.

Sharing back

One thing worth saying plainly, because it is easy to set up slskd as a pure leech and never think about it. Soulseek is a community of people sharing personal collections, and the whole thing falls over if everyone takes and nobody gives. My music library goes back in, read-only:

volumes:
  - /volume1/Music:/music:ro

shares:
  directories:
    - /music

The :ro is deliberate. slskd has no reason to write to the library, so it cannot.

Audiobooks and ebooks

Different problem entirely. There is no Sonarr for audiobooks, so this side is less “automation” and more “a good pipeline with a human at the front”.

Audiobookshelf is the server. It handles audiobooks, ebooks and podcasts, remembers where everyone is up to, and has decent iOS apps, which matters in this house. One small deployment note: it defaults to port 80, which is a bad neighbour on a Synology, so it gets moved:

environment:
  PORT: 10000   # override the default port 80
volumes:
  - /volume1/AudioBooks:/audiobooks
  - /volume1/Books:/Books
  - /volume1/Podcasts:/podcasts

Calibre-Web-Automated handles ebooks. The useful part over plain Calibre-Web is the ingest folder: drop a file into a watched directory and it converts, tags, covers and files it into the library without opening the Calibre desktop app.

- /volume1/downloads/book-ingest:/cwa-book-ingest   # clean drop zone CWA watches
- /volume1/Books:/calibre-library                   # final ebook library

Shelfmark sits in front of both as the request tool: search, pick, download. The interesting bit is that it routes by type. Ebooks go to the CWA ingest folder so Calibre-Web-Automated processes them. Audiobooks go straight into the Audiobookshelf library, because there is nothing to convert:

- INGEST_DIR=/cwa-book-ingest
- DESTINATION_AUDIOBOOK=/audiobooks
- HARDLINK_TORRENTS_AUDIOBOOK=false

That last line is a deliberate exception to everything I argued above. Audiobook torrents routinely arrive as multi-part RAR sets rather than playable files, so there is nothing sensible to hardlink. Copy and extract is the correct behaviour here, even though it costs the disk space.

The part no tool fixes

Audiobooks arrive named appallingly. Some are a bare author folder. Some are Richard_Powers_-_The_Overstory__Unabr_-_64k__2018____01_23__-__The_Overstory.nfo. Some are a single folder containing four unrelated Roald Dahl books. No scanner recovers from that, so I wrote two scripts.

inventory-audiobooks.sh is read-only and changes nothing. It walks the library and writes one text file listing every folder, every audio file, and the embedded tags from the first file in each folder via ffprobe. That inventory is what you actually plan from.

tidy-audiobooks.sh does the work, and its most important line is at the top:

# SAFE BY DEFAULT: DRY=1 only prints what it would do.
DRY=1

Every operation goes through one wrapper so the dry run is not something I have to remember to implement per command:

act(){ echo "+ $*"; [ "$DRY" -eq 0 ] && "$@"; }

The target layout is Author - Title, or Author - Series ## - Title for anything in a series, zero-padded so it sorts properly. Duplicates and GraphicAudio versions get moved to a _duplicates folder rather than deleted, because a script that has never made a mistake has simply not run often enough yet.

The script is also, deliberately, a hand-written list of decisions rather than clever pattern matching:

act mv "$LIB/Hanya Yanagihara"          "$LIB/Hanya Yanagihara - A Little Life"
act mv "$LIB/Douglas Stuart"            "$LIB/Douglas Stuart - John of John"

That looks like a lot of typing, and it is. But it means the script doubles as a record of every judgement call I made about the library, which a regex never would.

What it adds up to

Plex also mounts /volume1/AudioBooks, so anything in there turns up on the Apple TVs and HomePods alongside everything else. Audiobookshelf handles the phones. Both read the same tidied folders, which is the entire reason the tidying was worth doing.

Immich is the fix, and it has taken over in two stages: first as an additional copy running alongside iCloud, and gradually as the place the photos actually live.

Why Immich and not just a folder of files

A folder of files is a backup. It is not a photo library. Nobody in the family is going to browse a share looking for the photo of the dog at the beach.

Immich is close enough to Photos that people will actually use it: a proper mobile app that backs up in the background, albums, faces, and search that understands what is in the picture rather than just the filename. That last part matters more than I expected. Being able to type “beach” and get the beach photos is what turns a self-hosted archive into something people open.

Running it on a DS920+

Three details in my compose are Synology-specific and worth stealing.

Hardware acceleration reuses the same GPU passthrough as everything else. The DS920+’s Intel chip does the transcoding and the machine learning, using the same /dev/dri device access that got Plex hardware transcoding working:

extends:
  file: hwaccel.transcoding.yml
  service: vaapi

and for the ML container, OpenVINO rather than CPU:

image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}-openvino
extends:
  file: hwaccel.ml.yml
  service: openvino

The first library scan does face detection and search indexing over every photo you own. On CPU that is a weekend. On the iGPU it is an evening.

Tell Postgres it is on spinning disks. The database sits on the same mechanical drives as everything else, not an SSD cache, and Immich will tune itself accordingly if you say so:

DB_STORAGE_TYPE: 'HDD'

Ignore Synology’s own clutter. If you point Immich at a share that Synology Photos has ever touched, it will happily import thousands of generated preview and proxy files as though they were real photos. One line in .env stops that:

IGNORE_FILES_PATTERN=SYNOPHOTO_*

The one stack Watchtower is not allowed near

Everything else on the NAS updates itself. Watchtower runs at 1am, pulls new images, restarts containers, cleans up the old layers, and I mostly find out because something looks slightly different.

Immich is the exception, and every container in the stack says so:

labels:
  - "com.centurylinklabs.watchtower.enable=false"

Immich moves quickly and releases regularly carry database migrations. An unattended 1am pull that half-migrates a Postgres database holding the family photo library is not a risk worth taking to save five minutes of attention a month. Upgrades here are deliberate: read the release notes, pull, run it, check it.

The same reasoning applies to the two supporting images, which are pinned to digests rather than floating tags:

image: docker.io/valkey/valkey:8-bookworm@sha256:fea8b3e6...
image: ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357...

Pinning the database image is not paranoia. The Postgres container carries the vector extensions Immich’s search depends on, and a surprise major version bump underneath a running library is exactly the kind of morning nobody wants.

The “alongside” part: external libraries

The thing that made Immich viable rather than just interesting is external libraries. Immich can index folders it does not own, in place, without moving or restructuring anything:

volumes:
  - ${UPLOAD_LOCATION}:/data
  - /volume1/homes/andrew/Photos:/Archive_Import
  - /volumeUSB2/usbshare2-2:/USB_Archive:ro

/data is the library Immich manages, at /volume1/photo. The other two are decades of accumulated photos that already exist elsewhere: an archive folder in my home directory, and an external USB drive.

Note the :ro on the USB share. Immich has no business writing to a historical archive, so it cannot. If I ever misconfigure a retention rule or fat-finger a bulk delete, the twenty-year-old scans are behind a read-only mount and simply are not reachable. That mount flag is the cheapest insurance in the whole setup.

The “instead” part, honestly

I am not going to claim iCloud Photos is switched off, because it is not.

What has changed is which one I would be upset to lose. Immich now holds the complete archive, including everything that predates iCloud and everything that was scattered across old drives, and it takes the background upload from the phones. iCloud has quietly become the working set: the last couple of years, synced across devices, feeding the Apple TV screensaver and shared albums with people who are never going to install a self-hosted photo app.

The things still keeping iCloud in the picture are the integration bits rather than the storage. Shared albums with family who are not on Immich. Live Photos behaving properly everywhere. The Photos app being the thing that opens when you tap a photo in Messages. None of those are Immich failures, they are the cost of an ecosystem that is genuinely well built.

The direction is clear enough though. Every month the storage tier matters less, because the thing I would actually grieve losing is already sitting on a drive in the study.

One caveat worth stating loudly

Immich on the NAS is not a backup. RAID is not a backup either. Both protect against a drive failing, and neither protects against the house being burgled, flooded, or the array being corrupted by something I did to it at 11pm.

Right now the honest position is that iCloud is doing double duty as the off-site copy for recent photos, and the older archive is not as protected as it should be. That is the next problem to solve, and probably the next post.

This one’s a single-vehicle plugin on purpose – I have one MG4, and building for a fleet nobody’s testing against felt like the wrong kind of ambitious. It’s real, published, MIT-licensed software, and it runs continuously against my actual car, not a demo account.

Reverse-engineering SAIC’s cloud API

There’s prior art here – SAIC-iSmart-API/saic-python-client-ng, an existing MIT-licensed Python client – and the plugin ports the request shapes from that project rather than the code itself, since this is plain Node, not Python. A few things about the API were worth knowing before ever pointing it at a real car:

• Every request body is AES-128-CBC encrypted, key and IV both derived from MD5 hashes of the request path, a tenant ID, the auth token, and the timestamp, plus a separate APP-VERIFICATION-STRING header that’s an HMAC-SHA256 over similar material. None of it documented anywhere official.
• The VIN has to be sent as a SHA-256 hash, never in the clear. Send the raw VIN and you get error 36805, “not within the package scope” – which reads exactly like an account or subscription problem and is actually just “you hashed this wrong.”
• Status and command endpoints are all asynchronous the same way: the first call returns an event-id with no data. You resend the identical request with that event-id attached, repeatedly, until a response finally carries data – anywhere from a couple of seconds to most of a minute if the car’s asleep and has to wake up over its own cellular connection.
• SAIC only allows one active session per account, full stop. Logging in from the plugin silently signs the phone app out. Not a bug, just how the backend works – worth a line in the README so nobody thinks they’ve broken something.
• The gateway appears to rate-limit an account for roughly 15 minutes if it sees repeated logins in a short window from a new client, which is why the plugin polls conservatively, every 15 minutes by default.
• Region matters – there’s a separate gateway hostname per market (gateway-mg-au.soimt.com for Australia, and equivalents for EU, China, Brazil, Israel, Turkey, India, Thailand), configurable in the plugin.

Every write command – lock, unlock, heated seats, rear defrost, windows – goes through one endpoint, POST /vehicle/control, with a body like:

{
  "rvcReqType": "<command type, as a string number>",
  "rvcParams": [
    { "paramId": 5, "paramValue": "<base64 of raw bytes>" }
  ],
  "vin": "<sha256 hex of VIN>"
}

rvcReqType selects the command family, rvcParams is a flat array of typed, byte-packed parameters specific to it, and every observed request ends with a paramId: 255 zero-byte sentinel whose actual purpose is unclear – it’s just there, in every example, so the plugin sends it too. It reads like a protocol designed for something CAN-bus-adjacent that got wrapped in JSON and HTTPS as an afterthought for the cloud, which – once you’ve stared at enough of these vehicle APIs – it more or less always is.

Two commands the reference client supports and this plugin deliberately doesn’t: engine control and the remote immobilizer. Interesting to know exist, not something a hobby project needs anywhere near a real car.

Building it without risking the real car or the real house

The build order mattered as much as the code. A standalone test rig went first – a raw Node script, then a throwaway Homebridge instance paired to a separate test Home – specifically so a bad login attempt couldn’t sign the real iSmart app out or corrupt the Home everyone in the house actually uses. Only after that went onto the real Homebridge instance, and even then, read-only first: battery, lock state, door/boot/bonnet contact sensors, charging status. Writable lock/unlock came later, and only after its request was checked byte-for-byte against the reference client using a mocked send function that logs the outgoing JSON instead of transmitting it – so the first real command sent to the car was one I’d already confirmed matched a known-working implementation exactly.

It worked. Unlocking the plugin’s HomeKit switch actually opens the doors.

From there: interior/exterior temperature sensors (guarded against the API’s occasional -128 “field unavailable” sentinel, which now falls back to the last good reading and raises a HomeKit fault instead of showing a nonsense number), heated seats labelled by physical side rather than driver/passenger (the API’s own labelling is ambiguous across left- and right-hand-drive markets), rear window defrost, and window open/close. The last three shipped off by default, gated behind their own config flags, because they were new and nothing had confirmed them against the real car yet.

Heated seats and rear defrost: tested, confirmed working. Windows: tested, and consistently failed. That’s the interesting part of this post.

The window mystery

“Pre-heaters work, but windows don’t open or close” was the report. Reasonable enough on its face – except the Homebridge log told a different story once I actually read it.

The log showed Timed out after 60s waiting for the vehicle – but across every command type, not just windows. Locks, seat heat, rear defrost, all timing out, which flatly contradicted “seats and defrost work.” That contradiction was the real clue, and it would have been easy to tunnel straight to “windows are broken” and miss it. The timestamps explained it: six separate seat-heat attempts inside a twenty-second window, interleaved with window, defrost, and lock attempts – someone (me) tapping switches enthusiastically in the Home app rather than one command at a time.

Bug one, real, and fixed: the API client had no concept of “one command at a time.” Every call ran its own independent poll loop against the same car, and the backend apparently only tracks one in-flight command per vehicle – so overlapping calls just timed each other out, even if the vehicle had already reacted to the first one. Fixed with a small promise-chain queue in front of every /vehicle/control call, so a second tap now waits its turn instead of racing the first. Verified with a dry-run script that fired three concurrent fake commands and asserted no two were ever in flight at once – pass – before it went anywhere near the real car again.

That’s a genuinely general lesson: if the device can only execute one command at a time, your client has to enforce that itself. The device’s own API will not save you, and “tapped the button twice” isn’t a hypothetical – it happened in the very first real testing session.

Except the mystery wasn’t actually solved. A single, isolated window command – nothing else running – still failed after the full sixty seconds. This time, better debug logging (added on the fly, mid-investigation, straight onto the live plugin files on the NAS over the network, ahead of a proper release, because the diagnostic detail was needed for the next test, not next week) showed exactly what the car kept saying, every three seconds, for the whole minute:

code=4 event-id=- data=no message=The remote control instruction failed, please try again later.

Just “still not done,” forever, with no real progress – which ruled out overlapping commands (there weren’t any this time) and pointed at either the car or the backend flatly declining to make progress on this one command. A follow-up test surfaced a sharper error:

code=8 event-id=- data=no message=Request failed. Please check the vehicle status and try again.(255)

alongside, almost simultaneously:

code=8 event-id=- data=no message=Other remote command in progress. Please try again later.(3)

That second message was actually useful confirmation of the first bug – the backend genuinely does reject overlapping commands with an explicit error when it sees them – but it also meant this “clean” test wasn’t clean: the live NAS install had only received the logging patch, not the queue fix itself, which was still sitting in git. So the concurrency fix had to go live too before the next test could be trusted.

With that done, and a lead from outside research – a public project building a local Android-Automotive-OS app for MG4s (dragonro/MG4_winclose) documented, for a completely different interface into the same car, that window motors lose power the moment the car locks, and any close command sent after that point simply does nothing – I ran a properly controlled final test: unlock, immediately open the driver’s door and hold it, fire the window command while the door’s still open and the car’s accessory power should be live. A few iterations, including with the car freshly started.

Still failed. Every time, the same way. Which is a real answer, just not the one I wanted: this is a genuine limitation of this vehicle, on this software version, not a bug in the plugin.

Removing what doesn’t work

Rather than leave a switch in the plugin that either silently does nothing or occasionally times out and shows “Not Responding,” version 0.6.0 removed window control outright: the four Switch services and the enableWindowControls config option are gone from the accessory. The low-level controlWindow() method and its constants stay in the API client, unused, clearly commented as tried-and-confirmed-not-working-on-this-hardware, for anyone with different hardware or a future firmware update who wants to pick it up. The README, API docs, and changelog all carry the specific finding: tested against a real MG4 on software version SWi165 - R11 (Australia), tried locked, unlocked-with-door-open, and freshly-started, always the same code 8 rejection. Heated seats and rear defrost, shipped as “unverified” in the same release as windows, got promoted to “confirmed working” once the real car had proven them out.

Documenting a negative result properly – the exact error codes, the exact conditions tried, the exact conclusion – felt like it mattered more here than either quietly shipping a feature that doesn’t work or quietly deleting all evidence it was ever attempted. Someone else with an MG4, or a different firmware version, gets a real starting point instead of having to rediscover all of this from scratch.

Two smaller things worth knowing

HomeKit caches accessory and service names at first pairing, permanently, client-side. Rename a service in the plugin’s code afterwards and the Home app just keeps showing the old name – the only fixes are renaming it manually inside Home, or removing and re-adding the accessory. Tripped me up when a code change didn’t visibly do anything, and it’s a genuinely useful thing to know before you build any HomeKit accessory of your own.

Live-patching a running system mid-investigation is sometimes the right call, not a shortcut you feel bad about. My Homebridge config directory is reachable over the network from my Mac, so the installed plugin files could be edited directly and the affected child bridge restarted from the Config UI, without a full release cycle, purely to get the debug output the next test actually needed. The fix goes through the normal commit-and-release path once you know what you’re doing – but getting unblocked right now beat waiting on a pipeline built for a different situation.

Try it

npm install -g homebridge-mg-saic

Repo’s at andrew-snape/homebridge-mg-saic, MIT licensed, full credit to SAIC-iSmart-API/saic-python-client-ng for mapping the API first. If you’ve got an MG4 on different hardware or firmware and want to take another run at the window mystery, the escape hatch is still sitting there in the code, commented and waiting.

Andrew

Update: pre-conditioning confirmed, and another “not a bug”

Six releases since this post went up (0.7.0 through 0.9.4). The short version: it got faster, it got more resilient, and the one feature still marked “implemented but nobody’s actually tried it on the real car” finally got tried.

Speed and reliability first. Vehicle status and charging status now fetch in parallel instead of one after the other, which roughly halves refresh time when the car’s asleep and has to wake up over its own cellular connection. An expired token now triggers an automatic re-login mid-poll instead of requiring a Homebridge restart. The whole codebase moved to TypeScript, with a Vitest suite and ESLint running in CI ahead of every publish.

Pre-conditioning — the remote aircon — is now confirmed working. Tapping it in Home returned code: 0 after about 16 seconds and three polls, and the climate system audibly kicked on.

It came with its own small mystery, same shape as the window one: it runs the heater, every time, regardless of ambient temperature — and that’s correct, not a bug. The command asks for a fixed 22°C and never sets the compressor flag, and on this car heating runs on a resistive element with the compressor off. So “pre-conditioning” means “warm the cabin to 22°C,” not “set my preferred temperature” — worth knowing before you rely on it on a 40-degree day. Now documented properly in docs/API.md, including the temperature-index formula and a specific warning that fan-speed bytes 4 and 5 aren’t higher fan speeds — they silently put the car into heat-plus-front-defrost.

Two real bugs turned up from actual usage logs, not lab testing. A command the car explicitly rejects (code: 8) used to retry for the full 60 seconds before failing, burying a message like “Vehicle is powered on. Please turn it off and try again.” — it now fails immediately and surfaces that message. Same log run showed the car requires being locked with the ignition off before it’ll accept seat-heat or rear-defrost commands remotely — a vehicle-side restriction, not something the plugin can work around, but useful to know before assuming a command’s gone nowhere. And cached-accessory edits weren’t being written back to Homebridge’s on-disk cache, so a newly enabled switch could stay invisible in Home until you removed and re-paired the accessory.

Full blow-by-blow is in CHANGELOG.md.

Andrew

The symptom

A download finishes. The *arr picks it up and imports it. On a healthy setup that import is instant, no matter how big the file, and the download stays seeding without using a second copy of the disk space. On a broken setup the import takes as long as it would take to copy the file, and for a while you are holding two full copies of every release.

That difference is a hardlink versus a copy, and whether you get one or the other comes down to how the container sees the filesystem.

Why it happens

A hardlink is a second name for the same data on disk. It costs nothing and takes no time, but it only works within a single filesystem. The same is true of an atomic move: renaming a file within one filesystem is instant, while “moving” across filesystems is really copy-then-delete.

Here is the trap. On the NAS, /volume1/downloads and /volume1/TVShows are the same filesystem. But if you hand the container two separate bind mounts:

volumes:
  - /volume1/downloads:/downloads
  - /volume1/TVShows:/tv

then inside the container those are two separate mount points. The import gets treated as a cross-device operation, the hardlink is refused, and the move degrades to a full byte-for-byte copy followed by a delete. The host knew they were the same filesystem. The container did not.

The fix

Mount the parent once, and let the paths sit underneath it:

volumes:
  - /volume1/config/sonarr:/config
  - /volume1:/data

That is it. Every one of my *arrs and both download clients carry the same /volume1:/data line, with a comment in the compose file so future me does not “tidy it up”:

- /volume1:/data          # single mount: downloads + libraries on one filesystem

Inside the container the root folder becomes /data/TVShows, and the download client’s completed folder becomes /data/downloads/complete. Both sit under one mount point, so hardlinks and atomic moves work the way they were meant to.

The download client has to agree. If SABnzbd reports a path the *arr cannot resolve identically, you end up reaching for Remote Path Mappings, which is a patch over a problem you no longer need to have. Give SABnzbd and Transmission the same /volume1:/data and the paths line up on their own.

The other half: permissions

Hardlinks also need the process to be allowed to create them. Every container in the stack runs as the same user and group, with the same umask:

environment:
  PUID: 1026
  PGID: 101
  UMASK: "002"

UMASK: "002" is the part people miss. It makes new files group-writable, so the *arr that imports a file and the client that downloaded it are not fighting each other over who owns what.

The exceptions, and why they exist

Not everything wants the single mount, and it is worth being deliberate about which.

Plex only ever reads. It never imports, never moves, never hardlinks, so it gets narrow, purpose-named mounts instead: /volume1/Movies:/movies, /volume1/TVShows:/tv, and so on. Narrower is better when a container has no business writing to the library.

Prowlarr gets no media mounts at all. It only syncs indexers to the other *arrs, so there is nothing for it to see.

And then there is the honest wart. Lidarr carries one extra mount purely so that Soularr keeps working:

- /volume1/downloads/complete/slskd:/downloads/slskd   # kept so Soularr keeps working

That is exactly the pattern this post is arguing against, and it is there because a third-party tool hardcoded expectations about the path. The right answer was to point Soularr at the same folder expressed through the /data mount instead, so the import stays a hardlink, which is what it does now. The extra mount is a leftover I have not removed yet. More on that stack in the next post.

How to check yours

The quickest test is to look at the link count. After an import, run this on the host against the downloaded file:

ls -li /volume1/downloads/complete/some.release.mkv

The number in the second column is the link count. If it is 2, you have a hardlink and the library copy is the same data on disk. If it is 1, you have two separate copies and you are paying for both.

Finding the actual interface

The soundbar still runs something – SmartThings has to talk to it somehow – and it turns out these devices ship an on-board “IP Control” server that Samsung uses internally. The protocol itself was reverse-engineered first by ZtF/hass-samsung-soundbar-local for Home Assistant; this plugin ports that knowledge over to Homebridge/HomeKit, credited properly in the README.

It’s JSON-RPC 2.0 over TLS on port 1516, behind a self-signed certificate issued to “Samsung IP Control G2” (shared across Samsung display products generally, not per-device – so TLS verification has to be disabled outright, not just relaxed). The handshake mints a token you attach to every call after:

curl -sk https://192.168.0.45:1516/ \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json' \
  -d '{"jsonrpc":"2.0","method":"createAccessToken","id":1}'

That Accept: application/json header isn’t optional, and the way it fails if you skip it is the kind of thing that costs you an hour: drop it and the server comes back 400 Bad Request with a text/xml content type, which reads like “you’re speaking the wrong protocol entirely,” not “you forgot a header.” Both traps are called out explicitly in the README and in the code, because nothing about either failure mode points at its actual cause.

Volume without a volume knob

The RPC surface is small and mostly does what you’d expect – powerControl, getVolume, getMute, inputSelectControl, soundModeControl, getCodec. One genuine quirk: several of these are getter and setter on the same endpoint, disambiguated only by whether you passed a value – call powerControl with no power param and it just tells you the current state instead of changing anything.

The real oddity is volume. There’s no “set volume to 37” method anywhere in the protocol – only relative stepping, VOL_UP and VOL_DOWN via remoteKeyControl. HomeKit, meanwhile, wants an absolute 0-100 slider. So setVolume reads the current level and fires repeated up/down presses until it reaches the target, capped at 25 steps per call so a slider drag can’t machine-gun the device with requests.

There’s a subtler trap underneath that: getVolume lags roughly one press behind the device’s actual state at the cadence this plugin uses, so re-polling between steps to check progress causes overshoot – the loop thinks it hasn’t arrived yet when it has, and keeps stepping past the target. The fix is to not ask: the stepping loop tracks the target locally and trusts its own count, hands that value back to HomeKit immediately, and only re-confirms against the real device with a debounced “settle” poll about 900ms after the last press.

Token handling has its own small discipline: tokens are cached, concurrent requests are coalesced so the plugin never mints two at once under parallel calls, and any failed RPC call invalidates the cached token and retries once – because a stale token after the soundbar reboots just looks like a generic failure, not a clean “unauthorized” you could branch on.

One soundbar, one pairing

HomeKit only allows a single Television service per bridge, so the accessory has to be published as an external accessory rather than through Homebridge’s normal cached-bridge flow. The practical effect: after restarting Homebridge, you don’t just see it appear – you have to go into the Home app, Add Accessory, “More options,” and pair it with the same PIN as your main Homebridge bridge, as if it were a second, separate bridge. It’s a one-time gotcha but a genuinely confusing one if you don’t know it’s coming, and it’ll bite anyone building a HomeKit TV, soundbar, or receiver integration, not just this one.

Getting it onto npm

Before shipping, a general health pass on the repo turned up two real bugs that had nothing to do with the protocol work: no .gitignore at all (node_modules/ and dist/ one git add -A away from landing in a commit), and PLUGIN_NAME hardcoded unscoped in src/settings.ts while the actual npm package name is scoped, @snapeos/homebridge-samsung-soundbar-local. Both fixed, along with a package.json metadata mismatch in the same family – repository, bugs, and homepage all pointed at github.com/snapeos/... instead of github.com/andrew-snape/..., because the npm scope and the GitHub username aren’t the same string and it’s easy to type one where you meant the other.

Release itself went out as a GitHub Actions workflow triggered on v*.*.* tags: npm ci, npm run build, npm publish, reading an NPM_TOKEN repo secret. Simple in principle. Cutting the actual first release found six separate ways for that to go sideways, each one small and specific enough to be worth listing:

1. The session’s own git access turned out to be PR-only. Pushing a tag directly from inside Claude Code got a flat 403, and the GitHub tooling available had no tag-or-release-creation call at all – only branches and PRs. Direct pushes to main or tag refs just aren’t permitted from that kind of session, by design. Had to hand the tag push back to my own machine.
2. zsh doesn’t treat inline # as a comment by default, unlike a bash script. A copy-pasted command with a trailing # explanation comment got the entire comment text, em dash included, passed straight to npm as a literal argument, and it choked on the dash.
3. git push over HTTPS prompted for a username and password. GitHub dropped plain password auth for git years ago; it wants a personal access token in that field, and none was cached.
4. npm ci failed outright – it hard-requires a committed lockfile, and package-lock.json had only ever existed locally, never actually git added.
5. A tag “move” silently didn’t move. Deleting and recreating the tag looked like it worked – no errors – but it still pointed at the old broken commit, because the local main it was cut from hadn’t actually fast-forwarded first. Only caught on the next attempt by inserting an explicit git log -1 --oneline checkpoint before retagging and reading the output back before proceeding.
6. npm rejected the publish for 2FA reasons – 403, “granular access token with bypass 2fa enabled is required.” The token behind NPM_TOKEN was a type that expects an interactive one-time code, which obviously can’t happen inside CI. Fixed on npmjs.com’s end: regenerate as a classic Automation token, or a granular one with the bypass-2FA permission ticked, then update the secret.

The best part of that release day, though, wasn’t any of the above – it’s what happened while #4 was still broken. The failed run auto-triggered GitHub’s own Copilot “autofix” bot, a completely separate AI agent, native to Actions. It cloned the repo on its own branch, diagnosed the exact same missing-lockfile problem, ran npm install --package-lock-only, and opened its own PR. And its logs showed it was running on claude-sonnet-4.6 under the hood – so for a few minutes, two different AI coding agents were independently working the same repo, on related but uncoordinated problems, one of them Claude Code and the other GitHub’s own bot also running on a Claude model. I merged its PR in about a minute, same as everything else that week, and it turned out to be the fix that got the lockfile issue closed out for good.

Once the token was sorted, the workflow went green and I checked the registry directly rather than just trusting CI:

curl -s https://registry.npmjs.org/@snapeos/homebridge-samsung-soundbar-local
# {"name":"@snapeos/homebridge-samsung-soundbar-local","versions":["1.0.0"], ...}

1.0.0 was live.

And then it broke again

A few days later, in a fresh session, I corrected a real factual error: the README, the config schema, and the code all defaulted maxVolume to 40, described as roughly where the HW-Q930D tops out. It doesn’t – it goes to 100. That’s not a logic bug; the scaling option itself worked fine for whatever number you gave it. It’s a domain fact about a physical device that no amount of reading the code or unit testing could have caught – only owning the hardware tells you that. Fixed the default in three places (schema, platformAccessory.ts, README) and committed it.

Tagging v1.0.1 and pushing triggered the same publish workflow, which failed at the very last step:

npm error code E403
npm error 403 Forbidden - PUT https://registry.npmjs.org/@snapeos%2fhomebridge-samsung-soundbar-local
npm error 403 You cannot publish over the previously published versions: 1.0.0.

npm publish reads the version to ship from package.json, not from the git tag – and package.json still said 1.0.0. Tagging a release and bumping the package version are two separate manual steps in this repo, and I’d simply skipped the second one. npm was correctly refusing to let me republish a version that was already live; that’s the registry working as designed, not a fluke.

The annoying part was that v1.0.1 was now a burned tag – already pushed, pointing at a commit with the wrong version baked in. Retagging it onto the fix would mean force-pushing over an already-public tag, which is the kind of history-rewrite that’s generally worth avoiding, more so for something as visible as a release tag. So instead of forcing it, I bumped forward: package.json and package-lock.json to 1.0.2, committed, tagged v1.0.2 fresh, pushed. No force-push, nothing rewritten. v1.0.1 just sits there in the tag list now, permanently unused – a small, harmless scar that documents the mistake better than deleting it ever would. The workflow ran again and published cleanly; npm view @snapeos/homebridge-samsung-soundbar-local version came back 1.0.2.

The actual lesson

A git tag and package.json’s version field are two independent sources of truth for “what version is this,” and nothing enforces they agree until the registry rejects the mismatch at the very end of a CI run. A pre-publish step that just asserts the two match before npm publish is allowed to run would have turned both of these into a clear, immediate CI failure instead of a 403 discovered after the fact – worth adding next time I touch this workflow.

Try it

npm install -g @snapeos/homebridge-samsung-soundbar-local

Repo’s at andrew-snape/homebridge-samsung-soundbar-local, full credit to ZtF’s Home Assistant integration for cracking the protocol first.

Andrew

Why bother with a bridge at all

HomeKit accessories fall into two camps: things that speak the protocol directly (a handful of light bulbs and plugs, if you buy carefully), and everything else. “Everything else” is most of the smart home market – security cameras, doorbells, garage door controllers, TVs – and normally that means a separate app, a separate account, and no way to put that device in a Siri shortcut or a Home automation next to anything else.

Homebridge sits in the middle: it’s an open-source Node process that pretends to be a real HomeKit bridge (the same HAP protocol a genuine Apple-certified accessory speaks), backed by a plugin per device or ecosystem. From the Home app’s point of view, everything behind it looks like any other HomeKit accessory – same automations, same Siri phrases, same “everyone in the house can control it” behaviour, no separate login required for anyone else in the family.

What’s actually running

The container itself is unremarkable – a single Docker service on the NAS:

services:
  homebridge:
    image: homebridge/homebridge:latest
    container_name: homebridge
    restart: unless-stopped
    network_mode: host
    environment:
      - TZ=Australia/Melbourne
      - PUID=1026
      - PGID=101
    volumes:
      - /volume1/config/homebridge:/homebridge
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

network_mode: host isn’t optional here – HomeKit pairing and discovery run over mDNS/Bonjour, which is multicast traffic that doesn’t survive Docker’s normal bridged networking. Homebridge has to sit directly on the LAN to be discoverable by the Home app at all. PUID/PGID match the NAS user that owns the config volume, and everything that actually matters – accessory config, cached pairings, plugin settings – lives under that one bind-mounted /homebridge directory, so the container itself is disposable.

On top of that base image, four plugins are doing the real work:

• homebridge-ring – the Ring doorbell, cameras, and alarm system, all showing up as native HomeKit accessories. It’s configurable down to a fine grain: I’ve got it hiding the extra light-group and siren switches Ring’s own integration exposes by default, so the Home app shows what’s actually useful instead of a wall of redundant toggles.
• homebridge-config-ui-x – the web dashboard for managing the whole install: plugin config, logs, restarts, without hand-editing JSON over SSH every time.
• My own Centurion garage door plugin – the door itself, covered in more depth in the post on forking and rebuilding it. Talks to the door controller’s local API directly rather than through any cloud service, camera stream included.
• homebridge-matter – bridging Matter-native devices in as well, so Matter and classic HomeKit accessories end up in the same Home app without caring which protocol each one actually speaks under the hood.

There’s a fifth plugin, an Xbox integration, sitting in the config but disabled – turned out controlling a game console from the Home app wasn’t actually useful day to day, so it’s parked rather than uninstalled in case that changes.

Child bridges, and why each accessory gets its own

The one config detail worth calling out: every platform in Homebridge’s config.json gets its own _bridge block – its own HAP username and port, run as an independent child process rather than all sharing the main bridge. Homebridge does this by default now because it isolates failure: if the Ring plugin throws and its child bridge falls over, the garage door and the Matter bridge keep running and stay responsive in the Home app. Losing one integration used to mean losing all of them, back when everything ran as accessories on a single bridge process. Each child bridge also gets its own Matter port since Homebridge 2.0 added native Matter support – meaning the same accessories can, in principle, be exposed to a Matter controller too, not just HomeKit.

Was it worth it

For an all-Apple household specifically, yes, without much hesitation. Nobody in the house has to remember which app the garage door lives in versus the doorbell versus the alarm – it’s all just Home, all controllable by anyone with an iPhone on the family’s Apple ID, all available to Siri and to automations that mix accessories from completely different vendors in the same scene. The tradeoff is the one that comes with any self-hosted piece of infrastructure: if the NAS or the container is down, so is smart home control until it’s back up. For devices with a local API – the garage door being the clearest example – that’s a small risk since there’s no cloud dependency in the loop at all. For the Ring side, cloud-dependent either way, so Homebridge being briefly offline doesn’t make things meaningfully worse than Ring’s own app being down would.

Andrew

FileFlows is what finally stuck. It’s a self-hosted, Docker-deployable file processing tool with a drag-and-drop flow builder, and – the part that actually made it worth setting up – proper Intel Quick Sync support, using the same /dev/dri device passthrough as the Plex hardware transcoding setup.

What the main flow actually does

Nothing fancy, deliberately – I’m running the manual settings rather than the paid automatic-optimisation tier for now:

• Scan the existing library.
• If a file is already HEVC: leave the video alone, but still strip audio tracks that aren’t the show or movie’s actual language (unless its default language isn’t English, in which case that one stays), strip unnecessary subtitle tracks, rename, and update the metadata to match.
• If a file is still H.264: transcode it to HEVC – lossy, but with the same audio and subtitle cleanup applied either way.
• Speed set to about 3 (low end), quality around 6. That combination fits my library well: newer high-quality stuff usually already arrives as HEVC, so it never hits the transcode step at all, and most of what’s still H.264 is older – 90s and early-2000s material that was low quality to begin with, so a leaner encode isn’t giving up anything that wasn’t already gone.
• Audio stays as AC3/EAC3 rather than getting converted down to AAC – I tried that, and the loss was more noticeable than expected, enough to actually matter. So audio re-encoding isn’t part of the flow.

Where it sits relative to Sonarr and Radarr

FileFlows runs against the library after the fact rather than sitting in front of the import. I could point it at the downloads folder (alongside SABnzbd) so new files get converted before Sonarr and Radarr ever import them, but I’ve deliberately not done that – sometimes I just want the file available immediately, not queued behind a transcode. Letting FileFlows work through the library in the background gets the same result without making a new download wait on it.

Two more flows, for the smaller libraries

• Audio: FLAC downloads (16 or 24-bit, mostly off slskd) get remuxed to Apple Lossless. Not for any technical reason over keeping FLAC – purely because ALAC imports into Apple Music without friction, and everything I own is Apple hardware.
• Audiobooks: individual MP3/AAC chapter files from Audiobookshelf and Calibre-Web get merged into a single M4B, which is what actually gives proper chapter markers and metadata instead of a folder of identically-named tracks.

Video files also get repackaged from MKV into MP4 as part of the main flow. That loses a bit of what MKV can do – multiple embedded subtitle tracks and richer metadata mostly – but MP4 plays cleanly on everything I actually own, which matters more day to day than the features I’d be keeping.

Andrew

The starting point

There was already a plugin for this: KieraDOG/homebridge-cgd-garage-door, built by Long Zhao. It talked to the door’s local API, exposed open/close, the lock mode, and the courtesy light as a Homebridge platform, and worked. But it hadn’t been touched in a while, it predated Homebridge 2.0 and modern Node, and as an outside contributor I have no publish access to push new versions of the original npm package. Rather than run a stale plugin forever or start from nothing, I forked it.

Catching up, then diverging

The fork started boring on purpose: merge in everything from upstream main first, so the history stays honest about what’s actually new. From there the first real change was Homebridge 2.0 and Node 20+ support – table stakes for a plugin to keep working on a current Homebridge install.

The bigger step was migrating the whole plugin to the modern ESM format Homebridge’s own plugin template now expects: "type": "module" in package.json, TypeScript’s nodenext module resolution, export default instead of the old CommonJS export =, explicit .js extensions on every relative import (Node’s ESM resolver requires it, TypeScript won’t add it for you), and a modernized config.schema.json. Alongside that I brought in a proper local dev loop from the official plugin template – npm run watch now builds, links, and runs a real Homebridge instance against a throwaway test config, rebuilding on every save, instead of hand-wiring npm link each time.

That migration also forced the publishing question: the original homebridge-cgd-garage-door package name isn’t mine to publish to. It went out first under a scoped name, then got renamed again to @snapeos/homebridge-centurion-garage-door – “Centurion” is the brand actually printed on the hardware, and a much more findable search term than “CGD” (the app’s internal abbreviation). The Homebridge platform identifier itself (CGDGarageDoor, what goes in a user’s config.json) stayed untouched throughout, so nobody’s existing config broke across any of this.

What got added on top

Once the plugin was back on solid, current footing, a handful of real gaps were worth closing:

• A Stop button. The door’s local API has always supported door=stop, but nothing used it. HomeKit’s garage door service only models open/closed, so there’s no native slot for “stop” – it’s exposed as a separate momentary switch instead, the same workaround other garage plugins use for the same HomeKit limitation.
• Real device identity and error state. The accessory’s serial number was a random HAP placeholder; it’s now the device’s stable hostname. More usefully, the door’s status API quietly reports its own error codes, which were being ignored entirely – a genuine device-side fault now surfaces properly as “Not Responding” in the Home app instead of looking like a normal, healthy door.
• Native camera streaming. The Centurion controller has a built-in camera, served as an unauthenticated MJPEG stream on port 88. Previously that meant running a separate homebridge-camera-ffmpeg setup alongside this plugin just for the picture. It’s now a first-class CameraController on the garage door accessory itself – live view and snapshots, right there in Home, no second plugin. Getting ffmpeg to actually forward frames from a real MJPEG source (not a synthetic test pattern) surfaced two genuine bugs worth remembering: the stream has no reliable timestamps, so forcing an output framerate silently dropped every frame until -use_wallclock_as_timestamps was added on the input side; and libx264’s default lookahead buffering meant nothing reached the output at all on a short-lived session, fixed with -preset ultrafast -tune zerolatency.
• A stuck update lock. A command that threw partway through left the plugin’s internal “is updating” flag permanently set, silently freezing status polling after a single failure – an easy one to miss until it happens to you at an inconvenient moment.

Working with Claude Code on it

Most of this – the ESM migration, the camera integration, the bug fixes – was built working with Claude Code, in the same spirit as the 6AS Word Games project but for a very different kind of codebase: TypeScript, a real device protocol, and no way to “just reload the page” to check your work. The verification bar ended up higher than usual as a result – confirming the camera fix meant standing up a fake MJPEG server matching the real device’s exact response headers and capturing live RTP packets off a loopback SRTP receiver, not just watching tsc pass.

Try it

If you’ve got a Centurion door and run Homebridge, search “Centurion Garage Door” in the Homebridge UI, or:

npm install -g @snapeos/homebridge-centurion-garage-door

Repo’s at andrew-snape/homebridge-cgd-garage-door, full credit to Long Zhao’s original plugin for doing the hard part first – reverse-engineering the door’s local API in the first place.

Andrew

That move to Docker is where I hit the first real snag: hardware transcoding. On the Mac minis it just worked – basic, since those were Core 2 Duo-era chips, but baked in and automatic. In a Docker container, none of that comes for free. The DS920+’s CPU supports Intel Quick Sync fine; the container just needs to actually be given access to it.

Getting Quick Sync into the container

Two pieces, both well documented once you know to search for “Quick Sync” and “/dev/dri” together.

First: DSM resets the permissions on the Intel GPU’s device nodes back to root-only on every reboot, so the Synology-specific fix is a Task Scheduler boot script – Control Panel -> Task Scheduler -> Create -> Triggered Task -> User-defined Script, run as root, triggered on Boot-up:

chmod 666 /dev/dri/card0 /dev/dri/renderD128

Second, the container itself needs the device passed through, documented in plexinc’s own docker image as a --device=/dev/dri:/dev/dri docker run flag – the docker-compose equivalent:

services:
  plex:
    image: plexinc/pms-docker
    devices:
      - /dev/dri:/dev/dri

Then it’s just a toggle inside Plex – Settings -> Server -> Transcoder -> Show Advanced -> Use hardware acceleration when available (this needs an active Plex Pass). With both pieces in place, transcodes that used to peg a CPU core run on the GPU instead.

Remote access, and the thing I’m still watching

Plex Pass also makes remote access almost too easy – it’s on, working, and reachable from the internet with basically no setup on my end. That’s genuinely convenient, but it sits a bit oddly next to the rest of the homelab: everything else now runs behind Tailscale, with nothing else exposed directly. Plex is the one exception, and it’s something I’m keeping an eye on rather than something I’ve actually solved. Moving it behind Tailscale too would be easy for me – the hard part is everyone else. Family and friends who use it just want to press play, and asking them to install and log into Tailscale first is a bigger ask than it sounds.

Why Docker over the native package

None of this is strictly necessary – Synology’s own Plex package supports hardware transcoding out of the box, no Docker required. I moved anyway, mostly for the boring reasons: backups are just the compose file and the config volume, a bad Plex update is a five-second rollback to the previous image tag instead of an uninstall/reinstall, and it’s one less thing tied to Synology’s own package ecosystem if the media server ever moves off this NAS.

Andrew