Varför buffrar Jellyfin på en hemserver?

Jellyfin buffrar när en del av uppspelningsvägen inte kan leverera, konvertera eller avkoda video snabbare än tidslinjen går framåt. Videotranskodning är en vanlig orsak, men inte den enda. En ström kan också stanna på grund av klientkodekbegränsningar, undertextbehandling, instabilt Wi-Fi, otillräcklig uppladdningsbandbredd på distans, lagringskonflikter eller en transkodningskatalog som inte kan ta emot mer temporär data.

Det snabbaste sättet att hitta flaskhalsen är att kontrollera det aktuella uppspelningsläget innan du ändrar hårdvaruinställningar. Jämför sedan om problemet påverkar varje fil, endast 4K- eller HDR-media, en klient, fjärranvändare, uppspelning med undertexter eller flera samtidiga strömmar.

Kontrollera uppspelningsläget innan du ändrar något

Öppna Jellyfin-instrumentpanelen medan den påverkade videon spelas och inspektera den aktiva sessionen. Detta fastställer om servern levererar originalfilen eller aktivt konverterar en del av den.

Jellyfin delar uppspelning i fyra uppspelningsvägar med successivt högre serverbelastning: Direktuppspelning, Remux, Direktström och videotranskodning. Direktuppspelning skickar originalmediet med nästan ingen bearbetning. Remux ändrar behållaren, Direktström konverterar ljudet medan videon bevaras, och Transkodning omkodar videoströmmen.

Det här första resultatet ändrar hela felsökningsriktningen. Om Direktuppspelning buffrar, börja med nätverk, lagring, klient och mediefil. Om videotranskodning buffrar, kontrollera varför konvertering begärdes och om servern kan slutföra hela processen snabbt nog.

Ta reda på varför Jellyfin begärde en transkodning

En fil spelar inte direkt bara för att klienten stöder dess videokodek. Jellyfin utvärderar hela kombinationen av behållare, videokodek, kodekprofil, bitdjup, upplösning, ljudformat, kanaluppställning, undertexter, bithastighet och klientens uppspelningsbegränsningar.

Till exempel kan klienten stödja HEVC-video men inte det inkluderade TrueHD-ljudspåret. En annan klient kan avkoda båda strömmarna men misslyckas med att visa det valda undertextformatet. Dessa skillnader kan göra att samma fil blir Direct Play på en enhet, ljudkonvertering på en annan och full videotranskodning i en webbläsare.

Spela in orsaken till uppspelningen innan du ändrar inställningar. Testa också en annan ljudspår, inaktivera undertexter och spela samma fil via en annan Jellyfin-klient. Dessa kontrollerade tester är mer användbara än att aktivera alla codec-rutor i transkodningsmenyn.

Mjukvarutranskodning kan överbelasta en liten server

Mjukvaru-transkodning använder CPU:n för att avkoda källan, applicera filter, skala bilden och koda en ny ström i realtid. En lågpresterande processor kan hantera en 1080p-konvertering men misslyckas när källan är 4K HEVC, 10-bitars video eller HDR.

När konverteringen inte kan ligga före uppspelningen, förbrukar klienten så småningom de buffrade videosegmenten och pausar. CPU-användningen kan förbli nära sin maxnivå medan Jellyfin upprepade gånger försöker bygga tillräckligt med data före den aktuella positionen.

Om servern har en stödjande integrerad eller diskret GPU är korrekt konfigurerad hårdvaruacceleration vanligtvis mer användbar än att ändra FFmpeg-trådans antal. Om servern saknar kompatibel kodare kan en minskning av den begärda upplösningen eller bithastigheten bekräfta att transkodningskapaciteten är den begränsande faktorn.

Hårdvaruacceleration är en flerstegsprocess

Att välja Intel Quick Sync, VA-API, NVIDIA NVENC eller AMD AMF i kontrollpanelen garanterar inte att varje del av konverteringen körs på GPU:n.

En Jellyfin-transkodning kan inkludera avkodning, avflätning, skalning, formatkonvertering, HDR-tonmappning, inbränning av undertexter och kodning. Jellyfin noterar att vissa steg kan förbli på CPU:n på grund av hårdvaru-, drivrutins- eller mjukvarubegränsningar. Delvis acceleration kan därför ge hög CPU-användning även när GPU-aktivitet är synlig.

Verifiera hela uppgiften istället för att bara kontrollera om en GPU finns. Tvinga en förutsägbar transkodning, övervaka videoavkodnings- och kodningsmotorerna, inspektera FFmpeg-kommandot och leta efter filter som har fallit tillbaka till mjukvara.

Aktivera inte avkodningsformat som ditt GPU inte klarar av

Sidan för hårdvaruacceleration tillåter administratörer att välja videoformat som Jellyfin kan försöka avkoda via GPU:n. Att aktivera ett format som inte stöds lägger inte till den kapaciteten i hårdvaran.

Om GPU:n inte kan avkoda exakt codec-profil eller bitdjup kan Jellyfin falla tillbaka på mjukvaruavkodning eller misslyckas med att initiera hårdvaruvägen. Det är därför en HEVC-fil kan fungera medan en annan orsakar oväntat hög CPU-användning.

Bekräfta GPU-generation och stödda profiler, och aktivera sedan endast de format den faktiskt kan bearbeta. Testa vanliga H.264-, HEVC Main 10- och HDR-filer separat istället för att behandla all 4K-media som en enda arbetsbelastning.

Docker måste ges tillgång till GPU:n

En GPU som upptäcks av värdoperativsystemet är inte automatiskt tillgänglig inuti en Jellyfin-container. Containern behöver också korrekt enhetsmappning, runtime, drivrutiner, grupper och behörigheter.

För Intel- och AMD-GPU:er på Linux exponerar värden vanligtvis render-enheter under /dev/dri. Containeranvändaren måste kunna komma åt relevant render-enhet. NVIDIA-konfigurationer kräver värddrivrutin och en lämplig container-runtime. Praktiska Docker-kontroller inkluderar verifiering av render-enheten, mappning in i containern och tillägg av korrekt render-grupp GID.

Lämna inte containern i privilegierat läge som en permanent lösning. Det kan användas kortvarigt för att bekräfta att det underliggande problemet är enhetstillgång, men den slutgiltiga driftsättningen bör endast exponera de nödvändiga GPU-resurserna och behörigheterna.

Verifiera GPU-aktivitet under en verklig transkodning

En lyckad containerstart bevisar inte att hårdvarutranskodning fungerar. Jellyfin kan köras normalt, skanna biblioteket och spela filer direkt samtidigt som den inte har användbar tillgång till GPU:n.

Tvinga en transkodning genom att tillfälligt välja en lägre klientkvalitet än källan. På Intel-system, övervaka videoenheterna med ett verktyg som intel_gpu_top. På NVIDIA-system, inspektera aktiva processer och encoderaktivitet via nvidia-smi. Kontrollera också om CPU-användningen sjunker jämfört med mjukvarutranskodning.

Om det inte finns någon GPU-aktivitet, kontrollera den mappade enheten, containeranvändaren, render-gruppmedlemskap, hårdvaruaccelerationens metod och FFmpeg-loggen. Om GPU:n är aktiv men uppspelningen fortfarande är långsam kan en annan pipeline-steg fortfarande köras i mjukvara.

Undertexter kan utlösa en fullständig videotranskodning

Ett vanligt symptom är jämn uppspelning tills undertexter aktiveras. Detta sker ofta med bildbaserade undertexter eller stilade format som den valda klienten inte kan visa direkt.

När Jellyfin måste bränna in undertexter i bilden avkodar den varje bildruta, renderar undertextlagret och kodar en ny videoström. Det kan förvandla en annars lågbelastad Direct Play-session till en av serverns mest resurskrävande uppspelningsvägar.

Inaktivera undertexter och spela upp samma scen igen. Om buffringen försvinner, prova ett textbaserat undertextspår som SRT, testa en annan klient eller kontrollera om den valda hårdvaruvägen kan accelerera den omgivande avkodningen, filtreringen och kodningen.

HDR-tonmappning kan vara mer krävande än normal transkodning

Om 1080p och vanlig 4K SDR-media spelas upp korrekt men HDR-innehåll buffrar på en SDR-klient är tonmappning en stark kandidat.

Servern kan behöva avkoda en 10-bitars HDR-källa, konvertera dess färg- och ljusstyrkeomfång för SDR, skala den och koda en ny videoström. Ett system som klarar normal H.264-transkodning kan fortfarande vara oförmöget att utföra hela den arbetsbelastningen i realtid via mjukvara.

Testa samma HDR-fil på en HDR-kompatibel klient, tvinga sedan fram en SDR-transkodning och jämför CPU- och GPU-aktivitet. Hårdvarustöd för HEVC-avkodning bevisar inte automatiskt att den valda tonmappningsmetoden är fullt accelererad.

Klienten bestämmer mycket av uppspelningsvägen

Jellyfin kan Direct Play:a en fil i en skrivbordsmediespelare medan den transkodas i en webbläsare eller TV-applikation. Den skillnaden betyder inte att serverkonfigurationen ändrats mellan sessionerna.

Varje klient rapporterar sina stödda codecs, behållare, ljudformat, undertexter, upplösningar och bitrategränser. En mer kapabel spelare kan undvika konvertering, medan en begränsad spelare kan kräva ljudkonvertering, remuxing eller fullständig videotranskodning.

Testa samma fil, ljudspår, undertextspår och nätverksanslutning på två klienter. Om problemet följer en klient, undersök den enhetens uppspelningsmöjligheter och appinställningar innan du ändrar servern.

Direct Play kan fortfarande buffra

Direct Play eliminerar videokonvertering som huvudflaskhals, men det bevisar inte att varje annan del av vägen fungerar felfritt.

NAS:en måste fortfarande läsa mediet, nätverket måste leverera det kontinuerligt och klienten måste avkoda och visa det. Högbitratstoppar, instabilt Wi-Fi, ett långsamt klientgränssnitt, lagringsfel och omförsök eller en underdimensionerad spelare kan avbryta en annars direkt ström.

Kopiera problemfilen till klienten och spela upp den lokalt. Om lokal uppspelning också hackar, undersök mediefilen eller klientens avkodare. Om den lokala kopian fungerar medan Jellyfin Direct Play buffrar, fokusera på nätverket och serverns lagringsväg.

Testa den faktiska LAN-vägen istället för ett internethastighetstest

Ett snabbt internetresultat mäter inte vägen från Jellyfin-servern till en TV, telefon eller streamingbox i hemmet. Det avslöjar inte heller Wi-Fi-jitter, paketförlust, trängsel i mesh-backhaul eller en långsam enhetsgränssnitt.

En användbar lokal diagnos jämför uthållig filkopieringshastighet, en trådbunden klient, en kodning med lägre bitrate och den ursprungliga filen med hög bitrate. Praktiska lokala strömningstester inkluderar också test av Ethernet, kontroll om klienten tvingar fram en transkodning och att flytta tunga bakgrundsuppgifter utanför visningstider.

Titta på uthållig prestanda snarare än den högsta siffran som visas under några sekunder. Video med stora bitrate-toppar behöver tillräckligt med marginal för att klara korta nätverksavmattningar utan att tömma klientens buffert.

Fjärrbuffring har vanligtvis en annan orsak

Om samma media spelas korrekt hemma men buffrar via en extern anslutning, blir serverns uppladdningsbandbredd och den fjärranslutna rutten huvudmisstänkta.

Den användbara hastigheten begränsas av hemmets uppladdningshastighet, den fjärranslutna klientens nedladdningshastighet, VPN- eller omvänd proxy-överhuvud, konkurrerande trafik i hushållet och strömmens bitrate. En stor remux kan överskrida den tillgängliga uppladdningskapaciteten även om den spelar direkt perfekt över LAN.

Sänk tillfälligt den fjärrstyrda uppspelningskvaliteten. Om det löser buffringen, ställ in en hållbar fjärrbitrate eller använd hårdvarutranskodning för att skapa en mindre ström. Behandla den lägre inställningen som bevis på en bandbreddsgräns, inte som bevis på att den ursprungliga filen är defekt.

Lagring är mer benäget att misslyckas vid samtidig belastning

En frisk hårddisk kan vanligtvis läsa en vanlig filmström utan problem. Lagring blir mer misstänkt när uppspelning överlappar med nedladdningar, säkerhetskopior, biblioteksgenomsökningar, miniatyrbildsgenerering, paritetsoperationer, rensningar eller flera användare.

Dessa uppgifter skapar konkurrerande läsningar, skrivningar och sökningar. En disk kan visa acceptabel sekventiell hastighet i ett benchmarktest samtidigt som den utvecklar hög latens vid blandad aktivitet.

Övervaka användning och latens medan buffring sker. Pausa nedladdningar och underhållsjobb, och spela sedan upp samma fil igen. Håll Jellyfin-databasen, metadata och cache på lagring med lägre latens där det är möjligt, medan stora mediefiler kan ligga kvar på kapacitetsinriktade diskar.

En full transkodningskatalog kan stoppa uppspelningen

Transkoderad video skrivs som temporära segment innan klienten konsumerar den. Om det tilldelade filsystemet, SSD:n, RAM-disken eller Docker-volymen har otillräckligt ledigt utrymme kan FFmpeg inte längre producera nya segment.

Ett tidigare Jellyfin-problem dokumenterade hur uppspelningen bara kunde fortsätta tills den nådde det sista segmentet som skapades innan transkodningskatalogen fylldes. Rapporten är gammal och stängd, men symtomet är fortfarande en användbar anledning att kontrollera utrymmet när en transkoderad ström stannar efter flera minuter.

Kontrollera ledigt utrymme, inode-tillgänglighet, behållarkartläggning, skrivbehörigheter och kapacitetsgräns för transkodningsvägen. Var särskilt försiktig med små RAM-diskar eller temporära filsystem: att använda minne kan minska lagringslatens, men en för liten gräns kan orsaka ett abrupt uppspelningsfel.

En problemfil pekar vanligtvis på mediet

Om många filer med liknande upplösning och bitrate spelas upp korrekt är det mindre sannolikt att en enskild felande titel bevisar att hela servern är underdimensionerad.

Filen kan innehålla en ovanlig codec-profil, skadade bildrutor, en ljudlayout som inte stöds, ett bildundertextspår, felaktiga tidsstämplar eller en extrem bitrate-topp. En säsong av en serie kan också ha kodats annorlunda än de andra.

Testa ett annat ljudspår, stäng av undertexter, inspektera medieinformationen och jämför filen med en annan titel som använder samma codec. En enkel remux till en ny behållare kan hjälpa till att avgöra om det är behållaren eller tidsstämplarna som är problemet utan att behöva koda om hela videon.

Flera strömmar avslöjar gemensamma resursbegränsningar

En hemserver kan hantera en ström perfekt och börja buffra först när en annan användare startar uppspelning. Jämför uppspelningsläget för varje aktiv session innan du antar att nätverket ensam är orsaken.

Flera Direct Play-sessioner ökar främst lagrings- och nätverksbelastningen. Flera videotranskoder konkurrerar också om GPU-kodningskapacitet, CPU-filter, minnesbandbredd och transkodningskatalogens utrymme.

Testa en session, lägg sedan till strömmar en i taget medan du övervakar CPU-, GPU-, disk- och nätverksanvändning. Detta identifierar om den praktiska gränsen är antalet konverteringar, den totala mediebitraten eller blandad lagringsaktivitet.

Läs FFmpeg-loggen innan du installerar om Jellyfin

Serverns instrumentpanel visar vilken typ av uppspelning som sker, medan motsvarande FFmpeg-logg förklarar hur Jellyfin försökte bearbeta filen.

Sök efter fel vid initiering av hårdvaruenhet, behörighetsfel, ej stödjda profiler, mjukvarureserv, undertextfilter, tonmappningsfilter, in-/utmatningsfel, processavslutningskoder och lagringsutrymmesfel.

Fånga loggen från exakt den session som buffrar. En logg från en orelaterad Direktuppspelning eller lyckad transkodning kan leda till fel slutsats. Att installera om servern löser sällan en klientcodec-gräns, en otillgänglig GPU-enhet eller en full temporär katalog.

Använd symptomet för att välja nästa test

Följ denna felsökningsordning

1. Återskapa problemet med samma fil och klient.
2. Öppna Jellyfin-instrumentpanelen och anteckna uppspelningsläget.
3. Anteckna den angivna orsaken till transkodning eller kompatibilitet.
4. Inaktivera undertexter och testa ett annat ljudspår.
5. Spela upp samma fil via en annan klient.
6. Kontrollera CPU- och GPU-aktivitet under den påverkade sessionen.
7. Öppna motsvarande FFmpeg-logg.
8. Kontrollera utrymme och skrivbehörigheter i transkodningsmappen.
9. Testa kontinuerlig LAN-genomströmning eller fjärruppladdningskapacitet.
10. Pausa nedladdningar, säkerhetskopior, skanningar och lagringsunderhåll.
11. Jämför problemfilen med liknande media.
12. Överväg ny hårdvara först när bevisen visar en beräkningsbegränsning.

Denna ordning förhindrar att orelaterade ändringar döljer den ursprungliga orsaken. Ändra en variabel i taget och spela upp samma scen så att resultaten förblir jämförbara.

Slutsats

Att Jellyfin buffrar betyder inte automatiskt att hemservern behöver en snabbare CPU. Börja med det aktiva uppspelningsläget, eftersom Direct Play och videotranskodning pekar på olika delar av systemet.

För transkodade sessioner, identifiera varför konvertering krävs, verifiera hela hårdvaruaccelerationskedjan, testa utan undertexter, inspektera HDR-tonmappning och bekräfta att transkodningsvägen har tillräckligt med skrivbart utrymme. I Docker, verifiera GPU:n inifrån containern istället för att enbart lita på värddetektering.

För Direct Play, fokusera på stabil nätverksprestanda, klientavkodning, lagringsaktivitet och den enskilda mediefilen. Kombinationen av uppspelningsläge, klient, codec, undertexter, resursaktivitet och FFmpeg-loggar ger en mer pålitlig diagnos än att ändra slumpmässiga inställningar eller byta hårdvara först.

Vanliga frågor

Varför buffrar Jellyfin bara när undertexter är aktiverade?

Det valda undertextformatet kan kräva inbränning. Jellyfin måste då avkoda videon, rendera undertexter på varje bildruta och koda en ny ström. Försök att inaktivera undertexter, välja ett textbaserat spår eller använda en klient som kan rendera undertextformatet direkt.

Varför transkodar Jellyfin på en enhet men använder Direct Play på en annan?

Klienter stöder olika kombinationer av containers, videokodekar, ljudformat, undertexttyper, profiler och bithastigheter. Den mindre kompatibla enheten ber servern att konvertera den del av filen som inte stöds.

Hur kan jag bekräfta att Jellyfins hårdvaruacceleration fungerar?

Tvinga fram en videotranskodning och inspektera sedan serverns GPU-avkodnings- och kodningsmotorer. Bekräfta också att FFmpeg-loggen använder den förväntade hårdvaruenheten och att containern kan komma åt enheten utan behörighetsfel.

Varför buffrar Jellyfin även om det står Direct Play?

Direct Play tar bort videotranskodning från vägen, men nätverket, lagringen, mediefilen och klientens avkodare kan fortfarande vara för långsamma eller instabila. Testa filen lokalt på samma klient och jämför trådbunden och trådlös uppspelning.

Bör Jellyfin använda en SSD för transkodning?

En SSD kan minska latensen för temporära segment och är användbar för Jellyfin-databasen, metadata och cache. Det viktigaste kravet är en transkodningsväg med tillräckligt utrymme, pålitliga skrivningar och korrekta behörigheter. En RAM-disk med rätt storlek kan också fungera, men en för liten kan stoppa uppspelningen.