Glad 10.11.11 fixed the login. Since it’s the same with hardware acceleration on or off, decoding isn’t the bottleneck, it’s likely delivery or frame timing. Two quick checks: in your Jellyfin dashboard, is that session Direct Play or Transcode? And does the same file play smoothly in plain mpv/VLC (Fathom uses libmpv underneath)? That’ll tell us if it’s server/network vs. something on the Fathom side.
TraceApps@lemmy.world 1 day ago
Thanks, that narrows it down a lot. Fathom renders through libmpv and currently leans on its default frame timing, where a well-tuned client instead syncs frames to the display refresh.
Two questions would let me pin it down:
Which official client are you comparing against: the web client in a browser, or the Jellyfin Media Player desktop app? It matters because a browser hands video to a hardware overlay that is tear-free by design, while Jellyfin Media Player runs the same engine Fathom does, just configured differently.
What OS are you on, and what is your monitor’s refresh rate (60, 120, 144Hz)? On Linux, which desktop or compositor?
On the fix side, the next dev build adds a “Smooth Motion (Display Sync)” option under Settings > Playback > Advanced that paces frames to your monitor’s refresh. That is the usual cure for this kind of judder, so please try it when you have a moment.
The same build also adds a Diagnostics screen under Settings > About. Open it, turn on Diagnostic Logging, start the video again, let the stutter happen for a few seconds, then use “Copy Diagnostics” and paste the result here. That shows me the exact decode path and frame timing instead of me guessing. It strips out anything sensitive before copying.
github.com/Fathom-Media/fathom/…/v0.9.1-dev.3