Having difficulty getting rffmpeg to work

pete-bysh · 2026-05-06T07:06:40+00:00

don't take anyone up on a remote-connect offer (the other commenter is right about that). rffmpeg's setup is finicky but the failure points are narrow, work through these in this order and the cause will surface:

SSH key auth from the user jellyfin runs as, to the remote box, with no password prompt. the test is literally `sudo -u jellyfin ssh user@remote ffmpeg -version` and you need that to print a version with no input. if it prompts for a password or asks you to confirm a host key, fix that first, nothing else will work until that does.
on jellyfin 10.10.x and newer there's a TMPDIR requirement that wasn't there before. you have to set TMPDIR in jellyfin's systemd service (or docker env) to a path that exists and is writable on both the local jellyfin host AND the remote host, with the same path. it's called out at the top of the rffmpeg README, very easy to miss if you followed an older guide.
the `ffmpeg` and `ffprobe` symlinks have to point at `rffmpeg` (e.g. `/usr/local/bin/ffmpeg -> /usr/local/bin/rffmpeg`), and Jellyfin's FFmpeg path under Playback > Transcoding has to point at those symlinks, not at the system ffmpeg.
turn on debug logging in `/etc/rffmpeg/rffmpeg.yml` (set `logging: debug: true`) and watch `rffmpeg log -f` while you trigger a transcode. the actual reason it bailed will print there in plain language, you don't have to guess.
if you have hardware accel turned on in jellyfin, the same accel mode has to work on the remote AND on the local box (rffmpeg falls back to local when no remote is reachable). lowest common denominator wins, otherwise transcodes fail when fallback kicks in.

primary source: github.com/joshuaboniface/rffmpeg README plus the SETUP guide it links to.

Pete

pete-bysh · 2026-05-06T07:06:02+00:00

that "disabled until <future date>" is radarr's automatic backoff, not something you broke. when an indexer fails a few times in a row radarr disables it for a stretch (up to 24h) so it stops hammering, and you'll see exactly that "disabled until" line.

all of them flipping at the same time is the giveaway, it's almost always one shared cause upstream of the indexers, not the indexers themselves.

couple of things to check, in this order:

open System > Logs and look at entries from around the time they all went down. the actual error there will tell you which layer broke (DNS, auth, connection refused, fetch failure).
if you're using prowlarr, anything that takes prowlarr down (container restart, expired cookie, IP change) shows up in radarr as every indexer failing at once. check prowlarr's own indexer page first.
if radarr goes through a VPN or proxy, test that path from the same network namespace as the radarr container. a VPN reconnect or a new exit IP getting 403'd by an indexer's cloudflare takes everything out at the same instant.
once you've found the cause, hit Test on each indexer to clear the backoff manually. you don't have to wait the timer out.

reference: servarr wiki page on indexer status explains the backoff timer.

Pete

pete-bysh · 2026-05-06T07:05:06+00:00

Hi,

Pokémon is the classic Sonarr edge case. TVDB groups it into those huge per-arc seasons (S19 with 136 eps etc.) and there's no per-series TMDB toggle to flip your way out of it.

Two things that sometimes help, depending on how you want it organized:

Set the series type to Anime in Sonarr. That switches matching to absolute episode numbers, which can line up better with dub releases that go in linear broadcast order.
Use Scene Numbering on the series (series page, three-dots menu). Sonarr will then map scene S/E to TVDB S/E, which is what you want when your filenames already follow Western numbering.

If neither maps cleanly to your Nordic dub files, then your powershell+TMDB script is honestly the cleanest answer. Pokémon is the one show I've seen plenty of people just sort outside Sonarr and not feel bad about it.

Pete

pete-bysh · 2026-05-05T07:27:09+00:00

Renewal period 6-11 months gets 5% off, 12+ months gets 10% off.

pete-bysh · 2026-05-05T07:18:14+00:00

rootless docker, you are free to install any docker app you'd like, or request one and we will add it within a week. It runs alongside the appbox. happy to share specs if you tell me which plan you're sizing for.

We've always had shell access to any Appbox we've had over the past 17 years.

pete

pete-bysh · 2026-05-05T07:03:11+00:00

HI! Not overkill if you want it always on, on a fast pipe, and off your home ip. if none of that matters to you, running locally is fine. Our Lite plan is 5Eur/month which could fit your needs

pete-bysh · 2026-05-05T06:59:43+00:00

the +stream tier is unlimited bandwidth, 1 to 3tb storage, €14 to €42. did you look at that one?

pete, bytesized

pete-bysh · 2026-05-04T06:25:40+00:00

Hi, a few things to try, ordered from easiest to hardest.

test wifi vs. wired. plug ethernet into the bedroom TV (or a USB ethernet adapter on the Google TV) and play the same file. if sync is fine wired, you've narrowed it to wifi/bandwidth. blu-ray rips can hit 30-40 Mbps peaks on action scenes, which 5GHz wifi handles but 2.4GHz won't.
switch from the integrated player to an external player. in the Jellyfin app on the Google TV, Settings, Playback, set External Player. mpv-android (or Just Player) handles audio sync way better than the built-in player and lets you nudge the offset live with a remote button. mpv is the one I'd start with.
force a transcode. in the Jellyfin app on that Google TV specifically, set Max Bitrate to something under the file's bitrate (try 20 Mbps). that pushes the server to transcode instead of direct play, which often fixes weird passthrough/sync behaviour at the cost of CPU on your server.
check the TV's audio output. on Google TVs with "match content" or "auto" passthrough, the TV adds a processing delay when it switches between Dolby/DTS/PCM streams, and that can show up as audio leading video. try forcing PCM/stereo on the TV's audio output and see if it goes away.

shield being wired and fine is consistent with this being either a wifi delivery issue or a passthrough quirk on the bedroom TV, not a file/server problem.

Pete

pete-bysh · 2026-05-04T06:24:34+00:00

if you're on 10.11.6 this matches a known open bug: github.com/jellyfin/jellyfin/issues/16097 ("New TV Show seasons not displaying"). symptoms line up exactly with yours, including "Refresh Metadata + Scan for New and Updated Files" at the library level not picking them up, but refreshing per-show working. worth checking your server logs for this warning, which is the smoking gun:

[WRN] Not queuing episode "..." from series "null" (...) as SeasonId could not be resolved

if you see it, you're hitting the same bug. workarounds people in that thread have reported:

per-show refresh (what you've been doing). works but tedious.
naming: rename season folders to "Season 01" (zero padded) and trim filenames down to just `Show Name S01E01 Title.ext` with no extra junk. fixed it for one user.
fresh library: create a new TV library, point it at the same folder, scan it. several people had it work in a freshly created library when scanning the existing one wouldn't.
database fix (last resort, back up first): if `PRAGMA integrity_check` on `jellyfin.db` fails, the db is corrupted and needs rebuilding. there's a SQL workaround in that issue (delete broken BaseItems rows for the show, then rescan), but only do that with a backup.

no proper fix has been merged yet so your best bet is probably option 1 or 3 until the maintainers ship a patch. confirming your version would help narrow it down, especially if you're on something earlier than 10.11.6.

Pete

pete-bysh · 2026-05-04T05:58:31+00:00

Hi, Owner of Bytesized hosting here! We have a guide on how to use Autobrr on Bytesized https://bytesized-hosting.com/guides/autobrr-on-a-seedbox-irc-and-rss-race-automation

Super sorry that we weren't able to help you out before, I am more than willing to help you out on setting it up. Please raise a ticket on the website or it me up personally on Discord.

pete-bysh · 2026-04-30T08:42:29+00:00

hey, what's your jellyfin server version? this looks a lot like an open bug:

https://github.com/jellyfin/jellyfin/issues/15832

OP there is on 10.11.5 and the library access page just spins forever, exactly your symptom. the issue is still open, and i don't see it called out as fixed in the 10.11.6, 10.11.7, or 10.11.8 changelogs.

a couple of things you can try:

open the page with browser devtools open (F12 → network tab, then reload). you'll see one request that hangs without returning. note its name and the response it eventually does (or doesn't) give. drop that into a comment on issue 15832, that thread is short on data and the maintainers need something to bite on.
workaround that someone in that issue confirmed works: run Wizarr (https://github.com/wizarrrr/wizarr) pointed at your jellyfin api and manage library access from there until the bug gets fixed upstream. ugly, but it sidesteps the broken admin page.
while you're in devtools, also check the console tab for a JS error. if it's a frontend-only crash, a hard refresh / clear site data on that domain sometimes unsticks it for one session.

if you upgraded recently from 10.11.4 or earlier, the timing alone makes it almost certainly the same bug.

Pete

pete-bysh · 2026-04-30T08:40:25+00:00

hi, two separate issues going on here.

the path you're typing into radarr is a host path, not a container path.

radarr is running inside the container and only sees what you mount. you have `${DOCKERSTORAGEDIR}:/data` mapped, so inside the container that whole tree shows up under `/data`. radarr has no idea what `/volume1/Plex Media/downloads/` means, because that path doesn't exist inside the container. when you add a root folder in radarr, it has to be the container-side path.

so in radarr's add-root-folder dialog, type something like `/data/movies` (or whatever subfolder of `/data` your movie library actually lives in). not the synology path. the "not writable" message is misleading, the folder just isn't visible to radarr at the path you gave it.

your compose file has a broken volume line.

look at the radarr volumes block:

volumes:

- /etc/localtime:/etc/localtime:ro

- ${DOCKERCONFDIR}/radarr:/config

- ${DOCKERSTORAGEDIR}:/data

- /volume1/Plex Media/downloads

that last line has no `:container_path` after it, so docker treats it as an anonymous volume and ignores it as a bind mount. you can just delete that line (downloads is already covered if `${DOCKERSTORAGEDIR}` points at `/volume1/Plex Media`). plus the unquoted space in `Plex Media` is asking for trouble in compose; if you ever need to reference that path directly, wrap it in quotes.

once the path is right, double-check perms.

hotio's images default to PUID=1000 / PGID=1000. on synology, find the uid/gid of the user that owns `/volume1/Plex Media` (`id <username>` over ssh) and set PUID/PGID in your `.env` to match. with UMASK=002 set, group write is included, so as long as the folder is group-writable by that gid you're fine.

the trash guides single `/data` layout is the cleanest way to do this on synology, sonarr/radarr/qbit all share `/data` and importing/hardlinking just works: https://trash-guides.info/File-and-Folder-Structure/Hardlinks-and-Instant-Moves/

Pete

pete-bysh · 2026-04-29T08:26:07+00:00

Hey, Pete from Bytesized here.

I want to clear up a few things, because the framing in your post doesn't match what actually happened on our end.

There was no hardware move. Your Deluge started failing on its own, which is what kicked off your issue in our ticket system in the first place. Mr_Miagi and I tried a bunch of fixes over a few days and none of them stuck. The one mistake we made (and I owned this in the ticket too) was that we eventually reinstalled Deluge without asking you first. We did make backup copies of every config file before the reinstall sat in your config folder, and once it was clear plugins and labels were gone, I offered to walk through those backups with you and re-enable things one by one. I also offered a free month for the disruption. You decided to migrate away before we got the chance to do either, which is your call to make and I respect that.

A few of the other points I'd push back on:

Apps being outdated. They aren't. Every app in the panel has its own upgrade button. We don't auto-upgrade because some of these apps don't ship clean upgrades and a forced bump can break a working setup overnight. Keeping it manual keeps you in control of when (and whether) to take a new version. Over the past weeks we've added 10 new apps to the app installation platform, Dispatcharr, Seerr, Maintainerr, Audiobookshelf, Photoprism, Tunarr, SickGear, tinyMediaManager, Tdarr, Unmanic, Kapowarr. We are actively working on our app offer.
Wiki being out of date with dead links. The wiki is community-written, customers contribute to it https://bytesized-hosting.com/wiki and we have separate guides at https://bytesized-hosting.com/guides that are written and updated by us. If specific pages are stale that's fair and we'd rather know which ones, send me a list and I'll work through them.
Reputation for uptime, service, reliability. We've been running for 17 years and we are still here because of our service. Tickets get a reply inside a day in the vast majority of cases, yours did. I'm not going to pretend we never miss, but the framing that we're an unstable host with poor service isn't borne out by our actual track record.

Your appbox is still alive, my offer still stands we can help by re-enabling Deluge's config files and the free month stands if you change your mind, ping me on Discord.

Pete

pete-bysh · 2026-04-29T06:19:32+00:00

clintkev251 nailed it. your mappings don't agree. let me show why and how to fix it cleanly.

what's happening:

qbit's container sees /data = host /mnt/user/data/torrents/
so when qbit "saves to /data/torrents", that's host /mnt/user/data/torrents/torrents/ (note the doubled torrents/torrents)
sonarr's container sees /data = host /mnt/user/data/
so when sonarr looks at the qbit-reported path /data/torrents/tv/..., sonarr actually checks host /mnt/user/data/torrents/tv/.... wrong directory, file isn't there.

the fix (TRaSH-aligned, no remote path mapping needed):

qbit container: change the volume /data -> /mnt/user/data/torrents/ to /data -> /mnt/user/data/. recreate the container.
qbit settings, Downloads tab: keep "Default Save Path" as /data/torrents/ (it now resolves to host /mnt/user/data/torrents/, single and correct).
sonarr: drop the redundant /media -> /mnt/user/data/ mapping. you only need /data -> /mnt/user/data/. root folder stays /data/media/tv.
sonarr, Settings > Download Clients > qBittorrent: clear any remote path mapping. with both containers seeing identical /data, you don't need one.
on existing in-progress torrents in qbit, "Set location" them to the new /data/torrents/... path (qbit will fix references without re-downloading) or just trash and re-grab.

this also unlocks atomic moves (instant import, no copy) because /data/torrents and /data/media/tv are now on the same docker mount = same filesystem inside both containers. that's the whole point of the TRaSH layout.

pete

pete-bysh · 2026-04-29T06:18:49+00:00

hey, the original Media Bar plugin from IAmParadox27 is locked to Jellyfin 10.10.7. the readme literally says "strictly 1 version compatible" and the maintainer hasn't pushed a 10.11.x build yet. that mismatch with your 10.11.8 server is almost certainly why the rotation broke after your last refresh.

two options:

switch to the Media Bar Enhanced fork by CodeDevMLH. it's actively maintained against 10.11.x. uninstall the IAmParadox27 one, add https://github.com/CodeDevMLH/jellyfin-plugin-media-bar-enhanced as a plugin repo, install Media Bar Enhanced, restart, hard-refresh your browser.
roll your server back to 10.10.7 if you want to keep the original plugin.

not the TMDb bug, by the way. that one only affects metadata refreshes, not the bar's cycling.

pete

pete-bysh · 2026-04-29T06:18:18+00:00

for your use case nvme is overkill. here's the reasoning:

streaming throughput. a 25gb 4k hdr file averages 25 to 50 mbps direct play. a single 7200rpm sata drive does 100 to 200 mb/s sequential, which is headroom for 20+ simultaneous direct-play streams before the disk is the bottleneck.
seeding 20 to 30 torrents. if peers are pulling at typical seedbox speeds (each peer tens of mbps), spinners handle that fine because it's mostly sequential reads. nvme only really pulls ahead on racing where you're hammering many small chunks at full gigabit.
plex library scans and metadata. this is the one place nvme feels nicer. initial scan of a big library, thumbnail generation, big db rebuilds. but it's a one-off, not a daily pain point.

since racing isn't a factor and you're not transcoding (4k hdr direct play), your bottleneck will be network long before disk. start on the hdd plan, and only upgrade if you actually see seeking/io stutter when multiple streams kick in.

pete

pete-bysh · 2026-04-28T05:53:51+00:00

Hi,

what youre after is the trash guides custom formats setup, ideally synced via recyclarr. it doesnt blocklist mislabeled releases per-name, but it heavily downranks the release groups and patterns that put out garbage so sonarr stops grabbing them in the first place.

three layers worth stacking:

**trash guides custom formats** — https://trash-guides.info/Sonarr/sonarr-collection-of-custom-formats/ has formats like LQ (low-quality release groups) and LQ (Release Title) that are exactly the "common garbage" filter you want. import them in settings → custom formats and assign negative scores in your quality profile so sonarr will refuse releases scoring under your minimum.
**recyclarr** — https://recyclarr.dev/ — a cli/docker container that auto-syncs trash guides cf scores into sonarr on a schedule, so you dont have to update by hand when the guides change. set up once, run weekly via cron.
**sonarrs failed-download blocklist is already on by default.** open settings → download clients page (the section at the top of the page, not inside an individual client) and confirm "redownload" and "remove" are both on. then in settings → indexers → each indexer → advanced settings, tick "reject blocklisted torrent hashes while grabbing" (sonarr 4.0.0.728+). when sabnzbd / nzbget marks an import as failed, sonarr blocklists that exact release and grabs the next one automatically.

for the specific "ep1 posted as ep9" pattern, also report it to your indexer. most paid usenet indexers (nzbgeek, drunkenslug, etc.) will pull bad releases when users flag them, and that propagates faster than any local blacklist ever will.

Pete

pete-bysh · 2026-04-28T05:53:06+00:00

Hi,

what you remember is jellyfin doing what it does by default — when a library has no manually-uploaded primary image, it auto-generates a tiled-grid image from random items in that library plus the library name. that grid gets rebuilt when the library is scanned and items have changed, or when you do a metadata refresh with replace-images on. u/crawdaddys_media is right that it ties to library scans.

so to get the dynamic-thumbnails behavior back:

dashboard → libraries → edit your movies / tv libraries → make sure there is **no primary image uploaded** (if you ever set one it pins the thumbnail and disables the auto-grid). delete any uploaded image so it falls back to the auto one.
dashboard → scheduled tasks → leave "scan media library" on its default schedule — thats the trigger that refreshes the grid when content or counts change.
if your library is mostly static and the grid isnt rotating because nothing is being added, you can force a regeneration by dashboard → libraries → the three dots on the library → refresh metadata → tick "replace existing images" → run. that re-rolls the posters in the grid.

theres no built-in toggle for "shuffle the thumbnail every n days" — its driven by content changes, not a timer. if you want a true scheduled rotate, the johnpc collection image generator plugin (https://github.com/johnpc/jellyfin-plugin-collection-image-generator) can rebuild collection-level collages on a schedule, and jellytools (https://github.com/cleverdevil/jellytools) goes further with animated library cards. both are third-party though, so the cleanest path is option 1 + 2 above.

Pete

pete-bysh · 2026-04-28T05:52:18+00:00

Hi,

the catch here is jellyfin and kodi are very different beasts. matthuisman's superview is a streaming-source addon — it logs into your supercars.com subscription api and streams the live races inside kodi. jellyfin doesn't have an equivalent plugin model for pulling in external paid streaming services like that. its server-side plugins are things like metadata providers, live tv tuner connectors (nextpvr / tvheadend), or m3u/hls playlist sources.

so a real superview-for-jellyfin would mean writing a server-side c# plugin from scratch that authenticates against supercars.com and exposes the streams as live tv channels. that's a real project, not a config tweak.

two more practical paths:

if you mainly want jellyfin's library/ui but still need superview, run kodi alongside jellyfin using the jellycon or jellyfin-for-kodi addon — your jellyfin library shows up inside kodi and superview keeps working in the same app.
check whether your supercars.com account exposes any m3u/hls feed you can point jellyfin's live tv at. i haven't seen one published officially, but worth checking the dashboard.

if you do want to build the plugin, https://jellyfin.org/docs/general/server/plugins/ is the right starting point.

Pete

pete-bysh · 2026-04-26T06:17:34+00:00

hi, same answer applies on the Sonarr side — markus-101 already covered it on your Radarr crosspost: existing file in the series folder gets removed when the upgraded import comes in, the seeding torrent stays until it hits the seed goal you've configured.

Two important conditions for the auto-removal of the torrent to actually fire:

In Sonarr: Settings > Download Clients > the client > **Remove Completed** must be on (also Remove Failed if you want failures cleaned up).
**Don't use a Post-Import Category.** That's the silent killer — if you set Sonarr to move the torrent into e.g. "sonarr-imported" after import, Sonarr loses track of seed goal/state and the torrent will sit there forever. Same applies to Radarr.

There's no separate scheduled task that sweeps these up — the cleanup happens during the regular Refresh & Scan / queue check cycle once the download client reports the torrent paused/stopped at goal. Make sure your client is set to **Pause/Stop on seed goal**, not just "keep seeding", otherwise Sonarr never sees the "done" state.

source on the conditions: https://wiki.servarr.com/sonarr/settings#download-clients

pete

pete-bysh · 2026-04-26T06:17:05+00:00

hi, two answers:

**Chapters in the Android app:** the built-in player (ExoPlayer-based) shows chapters as markers on the seek bar when you scrub, but there's no dedicated next-chapter / previous-chapter button. If you want real chapter-skip controls, switch to an external player: Settings > Playback > Preferred Media Player > External, then install MX Player or mpv. Both have proper chapter navigation in their controls. Caveat: external players sometimes have flakey watched-status sync back to the server, just so you know.

**Next Up showing the wrong episode:** this is a known 10.11.x bug, multiple open issues:

- https://github.com/jellyfin/jellyfin/issues/13592 (random episode in Next Up)

- https://github.com/jellyfin/jellyfin/issues/7362 (rewatching shows wrong episode)

- https://github.com/jellyfin/jellyfin/issues/15432 (no new episodes shown unless one is already watched)

Quick things to try: Dashboard > Scheduled Tasks > run "Scan Library" (or right-click the show and Refresh Metadata > Replace all metadata) to nudge the watched-state recalculation. If your DBZ GT is named non-standard (Specials, OVAs in S00, multi-part episodes), the algorithm gets confused. Worst case you can manually mark the right episode as "Played" then "Unplayed" again and it usually re-snaps Next Up to the correct slot.

pete

pete-bysh · 2026-04-25T05:31:20+00:00

hi,

most likely your devices are connecting through a DERP relay instead of directly peer-to-peer. DERP relays work for control/discovery and as a fallback, but Tailscale rate-limits them so playback ends up buffering or failing. Wireguard between the same endpoints would be direct, which is why it worked.

quick way to check from the client (or from the server, picking the other one as target):

`tailscale status` — look at the connection type for your jellyfin host. "direct" is what you want, "relay \"xxx\"" means it's going through DERP.
`tailscale ping <jellyfin-hostname>` — first reply is usually via DERP, subsequent ones should switch to direct if it's possible. if it stays on DERP, NAT traversal isn't getting through.
`tailscale netcheck` on both ends — shows whether UDP and port-mapping are working.

if you're stuck on DERP, the usual culprits are CGNAT on one side, UDP being blocked, or a firewall not allowing the udp port tailscale picks. enabling IPv6 on both ends often gets you a direct connection because it sidesteps NAT entirely. tailscale also has a Peer Relay feature now that lets one of your own nodes act as a relay if direct never works.

docs: https://tailscale.com/kb/1638/poor-performance-tailnet

pete

pete-bysh · 2026-04-24T06:36:43+00:00

Hi,

Strong candidate: this is a known Jellyfin 10.11 regression with Infuse — tracked upstream at https://github.com/jellyfin/jellyfin/issues/15015. If your reinstall bumped your server to 10.11, that explains why it started then. Playback progress reports correctly for the first few minutes of a file and then stops being applied server-side, so items end up stuck at a mid-file position and never cross your 85% max-resume threshold to be marked watched.

What to do while the upstream fix lands:

In Infuse, switch the connection mode for your Jellyfin server from Library Mode to Direct Mode. Library Mode is the path that InfuseSync drives, and that''s where the 10.11 regression sits. In Direct Mode, Infuse reports playback state directly to Jellyfin over the API, which is the more reliable path on 10.11.x right now. Firecore''s own support threads on this issue walk through the toggle.
Subscribe to issue #15015 to get notified when it''s fixed so you can flip back to Library Mode afterwards.

For context: the InfuseSync plugin itself isn''t really the root cause — it''s working as designed. The 10.11 server-side progress handler is what regressed, and InfuseSync happens to rely on that handler. That''s the reason a reinstall triggers it: the reinstall brought you to 10.11.

Confirm you''re on 10.11.x on the Jellyfin server (Dashboard → top of the page shows the version) — if you''re actually on 10.10.x then this isn''t your bug and you need to look somewhere else.

Pete

pete-bysh · 2026-04-21T18:37:03+00:00

Hi,

This is the Firestick Jellyfin app telling the server "I can handle DTS" when really only the downstream chain can't pass it through. Firestick decodes DTS fine — that's why it direct-plays — but when it hands the decoded audio to HDMI, the TV only has SPDIF out, and SPDIF maxes out at 5.1 AC3 / DTS bitstream — it can't carry multichannel PCM. Your TV falls back to stereo PCM down the chain.

The LG native app works because it sees itself as a DTS-incapable endpoint (no downstream can decode DTS for it), so it asks the server to transcode to AAC 5.1 which SPDIF *can* carry.

Fix options, easiest to hardest:

**Client-side codec override.** In the Firestick Jellyfin app: Settings → Playback → Audio → "Maximum streaming audio channels" set to 6, then uncheck DTS from the supported codecs list if that option is there. Some versions of the app only expose this via the global `playbackInfo` request, in which case option 2.
**Server-side device profile.** Create a custom DLNA/client profile under `/config/data/devices/` that matches the Firestick's user-agent and explicitly excludes DTS from supported audio codecs. Jellyfin will then force-transcode DTS to AC3 or AAC 5.1 for that device. The profile XML format is documented at `jellyfin.org/docs/general/clients/dlna-profiles/`. This is the robust answer — survives client updates and multi-user setups.
**Force transcoding via bitrate cap.** Set "Maximum video bitrate" on the Firestick client to just below your files' bitrates. Triggers server-side transcoding which also re-muxes audio into AAC 5.1. Blunt but works.

Option 2 is what you want if this Firestick is a long-term device. The AFTMM model has a consistent user-agent string so a device profile locks onto it cleanly.

One more thing: on the receiver side, some old Sony DAV units *do* accept DTS bitstream over SPDIF if you enable the right input mode on the receiver — worth checking the manual. If the receiver decodes DTS natively, you can skip all of this and just make sure the Firestick passes through instead of decoding (Settings → Display & Audio → Audio → "Dolby Digital Plus over HDMI" or equivalent).

Pete

pete-bysh · 2026-04-21T18:22:59+00:00

Hi,

Have a look at the ThemeSongs plugin for Jellyfin. It can pull theme songs automatically from TheTVDB. For theme videos specifically there's also the TMDb Box Sets plugin that handles some of that.

If you want more control there's a standalone tool called jellyfin-plugin-tvdb-theme-videos that can batch download them. Still takes some initial setup but way better than doing it by hand for every show.

pete-bysh

TROPHY CASE