Loading/Buffing issues on jellyfin

Posted by iBangax132

Afternoon all, My jellyfin is basically unwatchable due to buffering speed... Internet doesnt seem to be the issue as im on 1GB tariff and getting very good speeds. looking for some help on what i can do to make it better? running a dell optiplex SFF i7 6700 no dedicated gpu (could be this?) 16gb ram 500SSD any ideas and thoughts would be great thought about vpn being the blocker - caps my torrents at 12mbs roughly give or take?

33 replies

tomspark wrote:

Great upgrade — the A310 even handles those HEVC 10-bit files that beat the old chip, so this should end the buffering for good. Two steps. First, in the terminal: sudo sparkbox restart media — Jellyfin only grabs graphics hardware when it starts up, so this hands it the new card. Then in Jellyfin: Dashboard, Playback, Transcoding — keep VAAPI, but change the device to the Arc: with two chips in the machine it's usually /dev/dri/renderD129 (run ls -l /dev/dri — the new second renderD entry is the Arc). Finally re-tick hardware decoding for HEVC and HEVC 10bit (the boxes we unticked before) and Save. Play that stubborn file and tell me what happens.

Frosty wrote:

Could be your media formats having to transcode to play. When something is playing, you should be able to see if it’s direct play or transcoding on the jellyfin dashboard. You can use tdarr or handbrake to change media formats into something more compatible like AV1 HVEC 264

iBangax132 wrote:

thanks for that tdarr sounds perfect - im trying to find the folder where all the movies/tv shows are stored and cannot get tdarr to find it (i also cant find it locally) any thoughts on where they might be stored? using linux mint if that helps

tomspark wrote:

Frosty's spot on — it's transcoding, and there's good news on two fronts. First, your media question: the apps don't see your files as a normal folder on the PC — inside SparkBox they all share one path called /data. So in Tdarr, when you add a Library, point it at /data (or /data/Movies and /data/TV). That's why you can't find it locally — same files, just shown to the apps as /data. Second, and this may fix the buffering with zero converting: your i7-6700 has Intel Quick Sync built into the chip, so you don't actually need a dedicated GPU. In the SparkBox dashboard go to Settings, find 'Hardware Transcoding', and set it to intel (or auto). Jellyfin then offloads the heavy lifting to that built-in chip, which usually turns 'unwatchable' into smooth right away. Do that first — Tdarr's still worth it later for shrinking your library.

iBangax132 wrote:

I did try enabling the quick sync but nothing would load and i would get errors - ill re enable it and see what happens again

tomspark wrote:

Ah, that's a common one and it's fixable — when hardware transcoding throws errors it's almost always a permissions match on the GPU chip, not the chip itself. When you re-enable it and it errors, grab two things so I can pinpoint it: 1) What the error actually says (Jellyfin usually pops a 'Playback Error' — the exact wording matters). 2) From your terminal: ls -l /dev/dri — that shows whether the graphics device is even visible. Most likely fix once we confirm: SparkBox has a 'render group' setting (JELLYFINRENDERGID) that has to match your Linux Mint system's value. Paste those two and I'll give you the exact number to set. And if it keeps fighting you, no stress — Tdarr converting your files (pointed at /data like I mentioned) gets you smooth playback without the GPU at all, as a solid plan B.

iBangax132 wrote:

so here is the output: total 0 drwxr-xr-x 2 root root 80 Jun 19 07:54 by-path crw-rw----+ 1 root video 226, 1 Jun 19 07:54 card1 crw-rw----+ 1 root render 226, 128 Jun 19 07:54 renderD128 scott@scottmedia:~$ the error: Playback Error Playback failed due to a fatal player error. thanks alot for the support as well!

tomspark wrote:

Perfect — the GPU is right there (that renderD128 line is exactly what Quick Sync needs), so it really is just the group-permission match, like I hoped. I need two quick numbers from your terminal: getent group render getent group video Each prints a line ending in a number, e.g. render:x:993: — give me those two numbers. Then in the SparkBox dashboard Settings, set JELLYFINRENDERGID to the render one and JELLYFINVIDEOGID to the video one, save, and try playback again. That tells Jellyfin which group owns the chip so it's actually allowed to use it — the 'fatal player error' should clear. And thanks for the kind words, we'll get this last bit sorted!

iBangax132 wrote:

render:x:992: video:x:44: ill make those changes now but off and soon!

tomspark wrote:

Those are the ones: set JELLYFINRENDERGID = 992 and JELLYFINVIDEOGID = 44 in the dashboard Settings, save, then play something. Hardware transcoding should kick in and the buffering should be gone. If it's still stubborn when you're back, give me a shout and we'll go to the Tdarr plan B — but I think this is the one. Go enjoy your evening!

iBangax132 wrote:

just a quick one couldnt find jellyrender or those settings in is it somewhere specific?

tomspark wrote:

Ah, that's because those two aren't in the dashboard — they're advanced overrides you set in the .env file directly (which is exactly why you couldn't find them in Settings). And this actually explains the error: SparkBox defaults the render group to 105, but yours is 992, so Jellyfin was being put in the wrong group and got denied access to the GPU. You've got terminal access, so: sudo nano /opt/sparkbox/.env Add (or update) these two lines: JELLYFINRENDERGID=992 JELLYFINVIDEOGID=44 Save with Ctrl+O, Enter, Ctrl+X, then run sudo sparkbox restart media. Give it a minute and play something — hardware transcoding should finally kick in. Your render group was the mismatch (video was already right at 44). That should be the one!

iBangax132 wrote:

so just reviewed what section should i add the code in? its currently not there and its split in to categories... does it matter where?

tomspark wrote:

Good question — and easy answer: it doesn't matter at all where you put them. The .env is just a flat list of name=value lines; the section headers are only there to keep it tidy for humans, and SparkBox reads the whole file regardless. Easiest is to scroll to the very bottom and add the two lines on their own: JELLYFINRENDERGID=992 JELLYFINVIDEOGID=44 Save, then sudo sparkbox restart media. Play something after a minute and the GPU should finally kick in.

iBangax132 wrote:

made those changes but unfortunately same error: did reboot and wait a few mins Playback Error Playback failed due to a fatal player error.

tomspark wrote:

Thanks for testing — here's the missing piece. SparkBox hands the graphics chip to Jellyfin, but Jellyfin has its OWN separate switch you have to flip; setting the .env alone doesn't turn it on inside Jellyfin. To do it: In Jellyfin: menu (top-left) - Dashboard - Playback - Transcoding. Set 'Hardware acceleration' to 'Video Acceleration API (VAAPI)' (the universal Linux one). The device box should show /dev/dri/renderD128 — leave it. Tick hardware decoding for H264 and HEVC, then Save at the bottom. Play something again. If it STILL errors, then the GPU itself is the holdup — run this and paste what it shows, it spells out the exact reason in plain text: docker exec sb-jellyfin-media sh -c 'cat "$(ls -t /config/log/FFmpeg.Transcode-.log | head -1)"' | tail -20

iBangax132 wrote:

NUMBEROFFRAMES: 1724 NUMBEROFBYTES : 42802 STATISTICSWRITINGAPP: mkvmerge v97.0 ('You Don't Have A Clue') 64-bit STATISTICSTAGS: BPS DURATION NUMBEROFFRAMES NUMBEROFBYTES Stream mapping: Stream 0:0 - 0:0 (hevc (native) - h264 (h264vaapi)) Stream 0:1 - 0:1 (eac3 (native) - aac (libfdkaac)) Press [q] to stop, [?] for help [hevc @ 0x7c7932981a00] No support for codec hevc profile 2. [hevc @ 0x7c7932981a00] Failed setup for format vaapi: hwaccel initialisation returned error. Impossible to convert between the formats supported by the filter 'Parsedsetparams0' and the filter 'autoscale0' [vf0:0 @ 0x7c793297d100] Error reinitializing filters! [vf0:0 @ 0x7c793297d100] Task finished with error code: -38 (Function not implemented) [vf0:0 @ 0x7c793297d100] Terminating thread with return code -38 (Function not implemented) [vost0:0/h264vaapi @ 0x7c793293e000] Could not open encoder before EOF [vost0:0/h264vaapi @ 0x7c793293e000] Task finished with error code: -22 (Invalid argument) [vost0:0/h264vaapi @ 0x7c793293e000] Terminating thread with return code -22 (Invalid argument) [out0/hls @ 0x7c793297d340] Nothing was written into output file, because at least one of its streams received no packets. frame= 0 fps=0.0 q=0.0 Lsize= 0KiB time=N/A bitrate=N/A speed=N/A

tomspark wrote:

That log is exactly what I needed — and it pinpoints it. Your file is HEVC 10-bit, and your graphics chip can't hardware-DECODE that specific format (that's the 'No support for codec hevc profile 2' and 'Failed setup for format vaapi' lines). The GPU is fine for the encoding part — it just can't decode this one format. Easy fix: back in Jellyfin, go to Dashboard - Playback - Transcoding. In the 'Enable hardware decoding for:' list, UNCHECK HEVC (and 'HEVC 10bit' if it's listed) — leave H264 ticked. Save. That tells Jellyfin to decode HEVC on the CPU but still hand the heavy encoding to the GPU, which your hardware handles fine. Play that same file again — it should go now.

iBangax132 wrote:

okay thats fixed the error but we are now back to massive buffering/not even loading sometimes for the specific file type (other movies and show work fine im assuming different file type)... is it not worth going for tdarr route?

tomspark wrote:

You've got the right instinct — Tdarr is exactly the move here. The deal: your chip can't decode that HEVC 10-bit format and your CPU is too slow to do it live, so those files will always struggle. Tdarr fixes it for good by converting them ONCE to a format that plays easily (H264), so nothing has to scramble mid-playback. It's built into SparkBox — turn it on: sudo sparkbox enable tdarr Then open it at your-server-ip:8265. It runs a quick setup wizard and its built-in worker connects on its own. Create a Library pointing at /data and pick a transcode option that outputs H264 — it'll work through your library in the background and those buffering files start playing smoothly (the H264 ones that already work can be left alone). Shout when you're in and I'll help with the Library settings.

iBangax132 wrote:

last one from me tonight have to pick this up tomorrow so ive got it looking at /data/ but it doesnt pick anything up once ran, havent fully looked at any documentation on this one i must say. I also cant seem to figure out where i choose what file i want as an output (did go through the quick tut it gives) any setup help would be great or tips - ill try again tomorrow with some docs/youtubing first before i bother you! thanks again so much for being active

tomspark wrote:

No worries at all — and good news, nothing's broken. A Tdarr Library on its own only SCANS and health-checks; the part that actually converts files (and where you choose the output format, H264 etc.) is the 'transcode plan' you add to the Library. That missing step is why nothing's being picked up to process. We've actually got a full walkthrough for exactly this — Library + transcode plan, end to end: https://tomsparkbox.com/guides/tdarr-setup.html That's perfect for your read-tomorrow plan. One safety note: Tdarr can MODIFY your files, so when you set up the transcode plan, point it at ONE small folder first and check the result plays before turning it loose on the whole library. Get some rest — ping me tomorrow and I'm happy to walk through any step. Thanks for being so easy to work with!

iBangax132 wrote:

Good morning! ive tried to setup tdarr and looks like ive got bits sorted from videos and guides - but it isnt picking anything up when scanning library. i assume this could be a permission issue? looked at the logs and i see this maybe i configured wrong? 2026-06-21T08:17:52.395] [WARN] TdarrServer - "/data//Music" [2026-06-21T08:17:52.395] [WARN] TdarrServer - "/data//TV" [2026-06-21T08:17:52.395] [WARN] TdarrServer - "/data//downloads" [2026-06-21T08:17:52.395] [WARN] TdarrServer - "/data//incomplete" [2026-06-21T08:17:52.395] [WARN] TdarrServer - "/data//youtube" [2026-06-21T08:18:52.399] [WARN] TdarrServer - The following folders exist in the cache that need to be deleted manually: [2026-06-21T08:18:52.400] [WARN] TdarrServer - "/data//Movies" [2026-06-21T08:18:52.400] [WARN] TdarrServer - "/data//Music" [2026-06-21T08:18:52.400] [WARN] TdarrServer - "/data//TV" [2026-06-21T08:18:52.401] [WARN] TdarrServer - "/data//downloads" [2026-06-21T08:18:52.401] [WARN] TdarrServer - "/data//incomplete" [2026-06-21T08:18:52.401] [WARN] TdarrServer - "/data//youtube" [2026-06-21T08:19:52.407] [WARN] TdarrServer - The following folders exist in the cache that need to be deleted manually: also thinking what goes in the source folder area? more digging im assuming i need to create a specific transcode folder?

tomspark wrote:

When a Tdarr library scans but finds nothing, it's almost always the library's Source folder pointing somewhere the files aren't. In Tdarr - Libraries - your library - Source, it needs to be the exact path your media actually lives at inside the container (the same one Jellyfin uses - usually /media or /data). Point it there and re-scan. If it still comes up empty after that, tell me the exact Source path you set and I'll check it against where your media really is.

iBangax132 wrote:

i seem to have fixed it and you were correct it was pointing /media instead of /data! its now picked it up and transcoding how would i know if its progressing? it has 139 files but nothing transcoded yet

tomspark wrote:

Great catch, that /data fix was exactly it, and nothing's wrong now. With 139 files queued and no graphics card, Tdarr is converting them using the processor, which is just slow, so each file takes a while and seeing nothing finished this early is completely normal. To watch it, open the Tdarr home page (your-server-ip:8265), it shows counts for files queued vs transcoded that tick up as it works, plus the file it's currently on. Leave it running and that transcoded number will climb. Check back in a few hours and you'll see it moving.

iBangax132 wrote:

think about 3 hours in and nothing has changed - would a 800mb file take that long? im unsure of waiting times - i can also see cpu is below 10% usage which would indicate nothing is happening?

tomspark wrote:

Good instinct, you're right. If the processor's sitting near idle after three hours it's stuck, not just slow, and an 800MB file wouldn't take anywhere near that long. The usual culprit is the worker count. On the Tdarr home page there's a panel for your server with a row labeled Transcode and little + and - buttons next to a number. If that number is 0, files just sit in the queue and nothing ever starts. Click + to make it 1, and within a minute a file should kick off and you'll see the processor jump. If it's already 1 or more, tell me and we'll look closer.

iBangax132 wrote:

thats fixed it! its now running - is it worth leaving it at 1 transcoder or use more?

tomspark wrote:

Nice, that was it. For your setup 1 transcoder is perfectly fine and safe. Since you've got a backlog to clear you could bump it to 2 to get through them faster, just keep an eye on things, and if the machine gets hot or sluggish while you're using it, drop back to 1. Once the backlog's done, 1 is plenty for day-to-day since new stuff only trickles in. Glad it's sorted!

iBangax132 wrote:

im making a full circle back to this comment - ive installed an intel Arc A310 in the jellyfin media box (optiplex 5040) i now want it to use this to encode - i know we changed it to use my cpu but now want to change it to the GPU how would i go about that?

iBangax132 wrote:

so i did this and it did make things smoother although i now have a slight issue with this one example: The suspicious part is that it doesn't specify /dev/dri/renderD129 anywhere. here's another clue in the log: after the FFmpeg version/configuration information, the log simply ends. There's no input initialization, stream mapping, output stream, frames encoded, or HLS segments generated. Compare that with your successful Outlander transcode, which proceeded into stream mapping and then encoded frames. So I think what's happening is essentially: 2012.mkv ↓ 4K HEVC Main10 HDR ↓ Jellyfin asks VAAPI for hardware decode ↓ likely selects renderD128 ↓ Intel HD 530 ↓ can't handle this decode path ↓ transcode never starts should be hitting the a310 gpu but seems not to be {"Protocol":0,"Id":"4ad5e4d0a4c3ec08b9fad57e3542767d","Path":"/data/Movies/2012 (2009)/2012 (2009).mkv","EncoderPath":null,"EncoderProtocol":null,"Type":0,"Container":"mkv","Size":33788715603,"Name":"2012 (2009)","IsRemote":false,"ETag":"a8bc6e101621c5026b6c4e18d0fb7cc3","RunTimeTicks":94704860000,"ReadAtNativeFramerate":false,"IgnoreDts":false,"IgnoreIndex":false,"GenPtsInput":false,"SupportsTranscoding":true,"SupportsDirectStream":true,"SupportsDirectPlay":true,"IsInfiniteStream":false,"UseMostCompatibleTranscodingProfile":false,"RequiresOpening":false,"OpenToken":null,"RequiresClosing":false,"LiveStreamId":null,"BufferMs":null,"RequiresLooping":false,"SupportsProbing":true,"VideoType":0,"IsoType":null,"Video3DFormat":null,"MediaStreams":[{"Codec":"hevc","CodecTag":null,"Language":null,"ColorRange":null,"ColorSpace":"bt2020nc","ColorTransfer":"smpte2084","ColorPrimaries":"bt2020","DvVersionMajor":null,"DvVersionMinor":null,"DvProfile":null,"DvLevel":null,"RpuPresentFlag":null,"ElPresentFlag":null,"BlPresentFlag":null,"DvBlSignalCompatibilityId":null,"Rotation":null,"Comment":null,"TimeBase":"1/1000","CodecTimeBase":null,"Title":null,"Hdr10PlusPresentFlag":null,"VideoRange":2,"VideoRangeType":2,"VideoDoViTitle":null,"AudioSpatialFormat":0,"LocalizedUndefined":null,"LocalizedDefault":null,"LocalizedForced":null,"LocalizedExternal":null,"LocalizedHearingImpaired":null,"DisplayTitle":"4K HEVC HDR","NalLengthSize":null,"IsInterlaced":false,"IsAVC":false,"ChannelLayout":null,"BitRate":28542328,"BitDepth":10,"RefFrames":1,"PacketLength":null,"Channels":null,"SampleRate":null,"IsDefault":true,"IsForced":false,"IsHearingImpaired":false,"Height":1600,"Width":3840,"AverageFrameRate":23.976025,"RealFrameRate":23.976025,"ReferenceFrameRate":23.976025,"Profile":"Main 10","Type":1,"AspectRatio":"2.40:1","Index":0,"Score":null,"IsExternal":false,"DeliveryMethod":null,"DeliveryUrl":null,"IsExternalUrl":null,"IsTextSubtitleStream":false,"SupportsExternalStream":false,"Path":null,"PixelFormat":"yuv420p10le","Level":153,"IsAnamorphic":false},{"Codec":"truehd","CodecTag":null,"Language":"eng","ColorRange":null,"ColorSpace":null,"ColorTransfer":null,"ColorPrimaries":null,"DvVersionMajor":null,"DvVersionMinor":null,"DvProfile":null,"DvLevel":null,"RpuPresentFlag":null,"ElPresentFlag":null,"BlPresentFlag":null,"DvBlSignalCompatibilityId":null,"Rotation":null,"Comment":null,"TimeBase":"1/1000","CodecTimeBase":null,"Title":"TrueHD Atmos 7.1","Hdr10PlusPresentFlag":null,"VideoRange":0,"VideoRangeType":0,"VideoDoViTitle":null,"AudioSpatialFormat":1,"LocalizedUndefined":null,"LocalizedDefault":"Default","LocalizedForced":null,"LocalizedExternal":"External","LocalizedHearingImpaired":null,"DisplayTitle":"TrueHD Atmos 7.1 - English - Dolby TrueHD \u002B Dolby Atmos - Default","NalLengthSize":null,"IsInterlaced":false,"IsAVC":false,"ChannelLayout":"7.1","BitRate":4860002,"BitDepth":24,"RefFrames":null,"PacketLength":null,"Channels":8,"SampleRate":48000,"IsDefault":true,"IsForced":false,"IsHearingImpaired":false,"Height":null,"Width":null,"AverageFrameRate":null,"RealFrameRate":null,"ReferenceFrameRate":null,"Profile":"Dolby TrueHD \u002B Dolby Atmos","Type":0,"AspectRatio":null,"Index":1,"Score":null,"IsExternal":false,"DeliveryMethod":null,"DeliveryUrl":null,"IsExternalUrl":null,"IsTextSubtitleStream":false,"SupportsExternalStream":false,"Path":null,"PixelFormat":null,"Level":0,"IsAnamorphic":null},{"Codec":"dts","CodecTag":null,"Language":"eng","ColorRange":null,"ColorSpace":null,"ColorTransfer":null,"ColorPrimaries":null,"DvVersionMajor":null,"DvVersionMinor":null,"DvProfile":null,"DvLevel":null,"RpuPresentFlag":null,"ElPresentFlag":null,"BlPresentFlag":null,"DvBlSignalCompatibilityId":null,"Rotation":null,"Comment":null,"TimeBase":"1/1000","CodecTimeBase":null,"Title":"DTS-HD MA 7.1","Hdr10PlusPresentFlag":null,"VideoRange":0,"VideoRangeType":0,"VideoDoViTitle":null,"AudioSpatialFormat":0,"LocalizedUndefined":null,"LocalizedDefault":"Default","LocalizedForced":null,"LocalizedExternal":"External","LocalizedHearingImpaired":null,"DisplayTitle":"DTS-HD MA 7.1 - English","NalLengthSize":null,"IsInterlaced":false,"IsAVC":false,"ChannelLayout":"7.1","BitRate":4589094,"BitDepth":24,"RefFrames":null,"PacketLength":null,"Channels":8,"SampleRate":48000,"IsDefault":false,"IsForced":false,"IsHearingImpaired":false,"Height":null,"Width":null,"AverageFrameRate":null,"RealFrameRate":null,"ReferenceFrameRate":null,"Profile":"DTS-HD MA","Type":0,"AspectRatio":null,"Index":2,"Score":null,"IsExternal":false,"DeliveryMethod":null,"DeliveryUrl":null,"IsExternalUrl":null,"IsTextSubtitleStream":false,"SupportsExternalStream":false,"Path":null,"PixelFormat":null,"Level":0,"IsAnamorphic":null},{"Codec":"ac3","CodecTag":null,"Language":"eng","ColorRange":null,"ColorSpace":null,"ColorTransfer":null,"ColorPrimaries":null,"DvVersionMajor":null,"DvVersionMinor":null,"DvProfile":null,"DvLevel":null,"RpuPresentFlag":null,"ElPresentFlag":null,"BlPresentFlag":null,"DvBlSignalCompatibilityId":null,"Rotation":null,"Comment":null,"TimeBase":"1/1000","CodecTimeBase":null,"Title":"DD 5.1","Hdr10PlusPresentFlag":null,"VideoRange":0,"VideoRangeType":0,"VideoDoViTitle":null,"AudioSpatialFormat":0,"LocalizedUndefined":null,"LocalizedDefault":"Default","LocalizedForced":null,"LocalizedExternal":"External","LocalizedHearingImpaired":null,"DisplayTitle":"DD 5.1 - English - Dolby

Chris wrote:

Good debugging — that trail makes sense. One thing I can confirm from our side: SparkBox mounts the whole /dev/dri directory into the Jellyfin container (not just renderD128), so nothing on our end is blocking the A310 from being reachable — both render nodes should be visible inside the container. Worth double-checking two things: 1) In Jellyfin Dashboard - Playback - Transcoding, confirm the 'VA-API Device' field actually shows /dev/dri/renderD129 (not still 128 from before) and that you hit Save after changing it. 2) Run docker exec sb-jellyfin-media ls -l /dev/dri to confirm renderD129 is visible and has the same render group as renderD128 inside the container itself, not just on the host. Beyond that, which specific device Jellyfin's ffmpeg actually opens for a given stream is Jellyfin's own internal logic, not something SparkBox controls directly, so I don't want to guess further and risk sending you down the wrong path. I'm flagging this thread to Tom so it gets a proper look — will follow up here.