Package Details: jellyfin-desktop 2.0.0-2

Git Clone URL: https://aur.archlinux.org/jellyfin-desktop.git (read-only, click to copy)
Package Base: jellyfin-desktop
Description: Jellyfin Desktop Client
Upstream URL: https://github.com/jellyfin/jellyfin-desktop
Licenses: GPL
Submitter: nvllsvm
Maintainer: nvllsvm
Last Packager: nvllsvm
Votes: 102
Popularity: 10.44
First Submitted: 2025-12-14 11:07 (UTC)
Last Updated: 2025-12-14 11:18 (UTC)

Pinned Comments

nvllsvm commented on 2025-12-14 11:28 (UTC)

jellyfin-media-player has been renamed to jellyfin-desktop.

Please switch to using the jellyfin-desktop package https://aur.archlinux.org/packages/jellyfin-desktop. v2.0.0 now uses qt 6

Latest Comments

1 2 3 4 5 6 .. 14 Next › Last »

OdinVex commented on 2026-01-16 18:29 (UTC) (edited on 2026-01-17 02:37 (UTC) by OdinVex)

@nvllsvm, It's definitely that header. Others I've reached out to are now confirming their situations and their users can use the client, provided that header isn't present. We might find time to see if it's a combination of that header and others in hopes of narrowing down.

Number one reported bug so far is mouse buttons for forward/back events are always fired twice (on press, on release), and sometimes the client crashes when using them too quickly (very rare).

Another issue reported is that Jellyfin-Desktop won't start on the same monitor it was last on (and won't start on the monitor the cursor is on).

Another issue, a user right-clicks to find their mouse sometimes and when they left-click to close the context menu any video they're watching will pause/unpause. That shouldn't happen if the context menu was opened.

OdinVex commented on 2026-01-13 23:47 (UTC) (edited on 2026-01-14 00:40 (UTC) by OdinVex)

@nvllsvm, Narrowed down the headers using poor-man's debugging (remove half of suspected causes, see if issue persists, narrow which half, repeatedly halving whichever side until few remain) just wondering if one might be an issue (not with the old client). No longer getting any crashes with "Cross-Origin-Opener-Policy: same-origin" removed. It's a frontend header added for shared services, wondering if it's conflicting with something and hanging a script (JavaScript is always thread-blocking, reason?). Pretty much spitballing around, edit: but no crashing with it removed, hopefully not a coincidence. Will ask others to remove theirs (or make more permissive) to test.

Edit: All on vacation. -_- Decided to disconnect client from internet and run, no crash ever, only occurs if online and after "WebEngineLoadRequest starting", before [dateFnsLocale] updating date-fns locale en.

OdinVex commented on 2026-01-13 23:32 (UTC) (edited on 2026-01-13 23:36 (UTC) by OdinVex)

@nvllsvm, I meant upstream as in the GitHub repository. I can say it always happens after the URI is resolved, "WebEngineLoadRequest starting: https://.../web/". I started tinkering a while ago and may be onto something. I suspect it may have to do with response headers (we're all coincidentally using reverse-proxies with similar headers). Either that or I've just gotten lucky for a while (no crashes without headers, crashes with, but rarely no crash with, so nothing solid, wondering if the extra headers are just mucking with time and maybe that's what affects it).

nvllsvm commented on 2026-01-13 23:20 (UTC)

I am upstream lol (andrewrabert)

OdinVex commented on 2026-01-13 23:18 (UTC)

@nvllsvm, I was going to find time to clone the latest source and debug the issue myself if possible (not familiar with upstream). JD crashes before anything can be produced (it's more of a complete hangup and only a SIGKILL can terminate it). Everyone else I know of personally that has tried JD has the same experience.

In short, 9/10 times trying to start it (or if a clean install after typing in server URI and then trying to connect) it'll just hang. Appears to be hanging on/during that first connect. SIGKILL (kill -9 ...) is all that works to terminate it. There's too many upstream Issues related to crashing, so I haven't yet filed one. I was going to try to debug from my side and if successful let upstream know and they can sort out if it a fix helps close other issues.

nvllsvm commented on 2026-01-13 23:13 (UTC)

@OdinVex. Mind linking to the specific GitHub issue you're experiencing? I understand that the app has frequently frustrated you so I'd take another look.

Debug logs would be helpful in the issue you will link. Things have been pretty reliable for me (sans the egregious Qt WebEngine memory leak https://github.com/jellyfin/jellyfin-desktop/issues/1091), so I'll need your help to see what's going on.

OdinVex commented on 2026-01-13 23:02 (UTC)

@nvllsvm, Did, it's just for people that experience crashes with jellyfin-desktop. Once it's fixed I'll remove the older working one.

nvllsvm commented on 2026-01-13 23:00 (UTC)

@OdinVex - do whatever you want

OdinVex commented on 2026-01-13 21:57 (UTC)

If the 99% crash-on-startup isn't fixed soon I'll just re-upload jellyfin-media-player to provide a usable client until then.

FabioLolix commented on 2026-01-10 19:15 (UTC)

Please rename source archives to be non-conflicting and reusable, this can be done with jellyfin-desktop-${pkgver}.tar.gz::

i.e. source=("jellyfin-desktop-${pkgver}.tar.gz::https://github.com/[...]


At first sight license should be GPL-2.0-only