Ik draaide Jellyfin al een tijd in een Debian LXC op mijn Proxmox-host. Dat werkte eigenlijk prima. De bibliotheken draaiden goed, clients konden verbinden en zelfs hardware transcoding via de Intel iGPU werkte.
Toch begon Jellyfin steeds meer te voelen als een dienst die ik liever los wilde trekken van mijn Proxmox-omgeving. Niet omdat de LXC-setup slecht was, maar omdat Jellyfin één van de zwaardere services in mijn homelab is. Bij metadata-scans, meerdere gebruikers of transcoding kan er ineens flink wat CPU-, GPU- en I/O-belasting ontstaan.
Mijn Proxmox-host draait ook andere VM’s en containers, en die wilde ik wat meer ademruimte geven. Toen ik een compacte desktop-pc met een Intel i7, 16 GB RAM en een Intel iGPU beschikbaar had, was dat een mooi moment om Jellyfin naar dedicated hardware te verhuizen.
Het doel was simpel: Jellyfin native op Debian draaien, met directe toegang tot Intel Quick Sync, terwijl Proxmox meer ruimte overhoudt voor andere taken.
Van LXC naar native Debian
De nieuwe machine is bewust simpel gehouden: Debian 13, Jellyfin native geïnstalleerd en de media via NFS vanaf de NAS. Geen Docker, geen LXC en geen GPU-passthrough meer.
Na de installatie heb ik eerst gecontroleerd of Debian de Intel iGPU zag:
ls -lah /dev/dri
Daarin verschenen onder andere card0 en renderD128. Vooral /dev/dri/renderD128 is belangrijk voor Jellyfin, omdat die gebruikt wordt voor hardware acceleration.
Daarna heb ik de benodigde VA-API-tools en Intel media driver geïnstalleerd:
sudo apt install vainfo intel-media-va-driver mesa-va-drivers
Vervolgens heb ik getest of de Jellyfin-service zelf toegang had tot de iGPU:
sudo -u jellyfin vainfo --display drm --device /dev/dri/renderD128
Toen dat werkte, wist ik dat de basis voor Intel Quick Sync goed stond.
Jellyfin zelf heb ik native op Debian geïnstalleerd. In de logs was daarna te zien dat hardware acceleration beschikbaar was en dat Jellyfin zijn eigen FFmpeg-build gebruikte. Dat was precies wat ik wilde zien.
Data en media overzetten
De belangrijkste data van de oude Jellyfin-installatie heb ik meegenomen: de database, configuratie, gebruikers, plugins, bibliotheekdata, metadata en cache. De transcode-map heb ik bewust niet meegenomen, omdat dat tijdelijke data is.
De media zelf staat op een NAS en wordt via NFS gemount. Op de nieuwe machine heb ik dezelfde mountlocatie gebruikt als op de oude server. Daardoor bleven de bestaande mediapaden voor Jellyfin gelijk.
Dat was een belangrijk onderdeel van de migratie. Omdat de paden hetzelfde bleven, hoefde Jellyfin de bibliotheken niet opnieuw op te bouwen en hoefden de bestaande instellingen niet aangepast te worden.
Na het kopiëren heb ik de rechten hersteld en de Jellyfin-user toegevoegd aan de juiste groepen voor toegang tot de iGPU:
sudo chown -R jellyfin:jellyfin /var/lib/jellyfin /etc/jellyfin /metadata /cache
sudo usermod -aG render,video jellyfin
Daarna startte Jellyfin op de nieuwe machine met de bestaande gebruikers, plugins, bibliotheken en instellingen. Dat was eigenlijk het mooiste moment van de migratie: inloggen en zien dat alles er nog gewoon stond.
IP-adres overnemen
Om de migratie zo onzichtbaar mogelijk te maken, heb ik de nieuwe machine uiteindelijk hetzelfde vaste IP-adres gegeven als de oude Jellyfin-LXC.
Daardoor hoefde ik de reverse proxy niet aan te passen. Voor clients en gebruikers bleef de server aan de voorkant hetzelfde, terwijl aan de achterkant de hele machine was vervangen.
De totale downtime was ongeveer 15 minuten. Gebruikers kregen geen SSL-foutmelding, apparaten gaven geen “server has changed”-waarschuwing en clients hoefden niet opnieuw gekoppeld te worden.
Dat vond ik misschien wel het beste resultaat van de hele migratie: technisch was er veel veranderd, maar voor gebruikers was het vrijwel onzichtbaar.
Hardware transcoding testen
Daarna heb ik getest of Intel Quick Sync ook echt gebruikt werd. Daarvoor gebruikte ik intel_gpu_top:
sudo apt install intel-gpu-tools
sudo intel_gpu_top
Bij een zware 4K-transcode was duidelijk te zien dat de iGPU werd aangesproken. Jellyfin gaf aan dat er getranscodeerd werd en ffmpeg was actief.
De test ging om een 4K HEVC Main10 / Dolby Vision / HDR-bron die de client niet direct kon afspelen. Jellyfin moest dus transcoderen en tone mapping toepassen. Dat werkte netjes en de server haalde ongeveer 2x realtime.
Toch blijft de belangrijkste les: hardware transcoding is mooi, maar direct play blijft beter. Zeker bij 4K HDR of Dolby Vision-bestanden kan transcoding alsnog zwaar zijn. De nieuwe setup kan dit nu goed aan, maar ik zie transcoding vooral als vangnet.
Conclusie
Deze migratie was vooral bedoeld om mijn Proxmox-host meer ademruimte te geven. Jellyfin draaide prima in een LXC, maar als zwaardere mediaservice past het beter op eigen hardware.
Een mooi bijkomend voordeel is dat Jellyfin nu native op Debian draait, met directe toegang tot de Intel iGPU. Intel Quick Sync werkt zonder container- of LXC-passthrough en hardware transcoding is goed te controleren met tools zoals intel_gpu_top.
Door de mediapaden en het IP-adres gelijk te houden, bleef de migratie voor gebruikers vrijwel onzichtbaar. Geen nieuwe clientconfiguratie, geen reverse proxy-aanpassingen en slechts ongeveer 15 minuten downtime.
De oude LXC-setup was dus zeker niet verkeerd, maar deze nieuwe indeling past beter bij mijn homelab: Proxmox voor VM’s en containers, en Jellyfin als zwaardere mediaservice op eigen hardware.