Spksrc: [Package Request] Jellyfin

[ploughpuff]

• Name: Jellyfin
• Description: Jellyfin is a Free Software Media System
• Website: https://jellyfin.github.io/
• Software documentation: https://jellyfin.readthedocs.io/
• Build/Installation documentation: https://jellyfin.readthedocs.io/en/latest/administrator-docs/building/
• Source code: https://github.com/jellyfin/jellyfin
• License: GNU General Public License v2.0

[jindaxia]

Yes, Please

[fengz41]

Yes, Please

[s1oz]

Yes, Please

[fyngd]

Yes, Please

[WodKa78]

yes, please

[albertjane]

That would be lovely :)

[kozi48]

yes please

[James-Jie]

yes, please

[jpbaril]

One more here!

[1nTheZ0ne]

This is a vital alternative to Plex for users of the lower-end Synology products that do not support docker and that do not have the processing power to transcode video files.

[SquareBottle]

Yes please!

Also, here is a link to where the Jellyfin team says that a Synology package is one of the requests they receive most often in their subreddit and that they'd like to do it, but don't currently have the know-how.

[chickenandpork]

TL;DR: please review jellyfin/jellyfin#2328 and note down anything strangely worded or with poor tone; then me too! and thumbs-up that issue to ensure it gets response.

More detail:

There are two glaring issues with this:

1. Which of us who can build this can test it? We'd need testers who can test and respond quickly. Granted, this is the same problem we have with all cross-builds, just that we can test 0 of many architectures directly rather than 1.
2. The build is screwy: it's a docker-based build and tar-up-the-entire-dist-dir, and there's clear evidence their existing processes are "dirty" -- take apart the macOS build, and see all the non-mac stuff inside.

Their build process is hard to take apart in detail because it uses things like Azure pipelines, which are cool but not as well known as, say, auto tools. The number of people complaining traditionally about auto tools shows how many people know about it.

They offer pre-built binary packages, but ensuring compatible libraries when doing a spksrc <--> jellyfin architecture mapping becomes fragile, but supporting it when it breaks would be our burden, and we can't even test things (see issue 1 above)

Build a bridge from both river banks

To work together towards a common meeting point, they need to have a build that says:

1. I need these dependencies -- can I see them all here by trying to use them? awesome

I've created an issue jellyfin/jellyfin#2328 to hopefully describe what I think we'd need. Note that we'd probably need things like a dot-net toolchain, so there's a lot of building this bridge from both sides.

Call to action

me-to and thumbs-up that issue in jellyfin.

If you don't have the build ability, but you can test, well, if we can do this, then we can add a place to self-volunteer your test platform by architecture.

[ymartin59]

I would also refer to:

• https://github.com/jellyfin/jellyfin/issues/528
• #3715

so it sounds like a large effort will be needed (probably the same @m4tt075 did with Mono updates) before getting such a beast compiled and maybe with luck running on Synology DSM ... which generally runs on less resources than Windows workstation for which that application has been probably designed as a target.... (really enough RAM to run on Synology devices? it would make sense to confirm memory footprint on a standard Linux distribution...)
My opinion is that the chance of success does not worth the effort, except maybe for someone really interested in getting it for his own usage.

[chickenandpork]

Yeah, a jellyfin/jellyfin#528 would be easier to port and would imply they might support some part of the port.

That, and the mono/.net issue you raised, plus the fact that I can’t test it directly (just trying to donate a port I don’t use to help others) has fairly big risks.

Also, there are a number of dependencies I’d have to bring in.

It’s risky to work on than an unsupported port that I can’t support myself. I think I should pass.

[anthonylavado]

Some how Emby manages to do it - I know their packages are .NET Core. I just don’t know how.

Edit: I should add - they run their own repo to add, and presumably have some set of build tools, but there’s the thing - how does one even begin to build for Synology? That’s my stumbling block in trying to get something going.

[chickenandpork]

how does one even begin to build for Synology? That’s my stumbling block

At the end of the day, SPK is similar to the 3-part ar archive that makes up a Debian .deb (manifest, info, package.tgz) but with a few more metadata files, icons, system configs like open ports expanded out of Debian’s control file (IIRC).

In SynoCommunity/spksrc, we have a set of tools that make the creation quite predictable and maintainable, run by good old-fashioned make, but going outside these lines dramatically increases risk and maintenance burden.

Synology’s third party tools has a set of scripts that do things a little differently last time I checked; it might be useful, but it’s not our way, so give that a try but it’s too costly long-term for us in SynoCommunity to maintain.

Additionally, you can write the tar commands yourself, just like you can craft .deb files using manual ar commands, but it’s more prone to subtle errors until it works.

If you were to repack the binary drops, I would use whitelist or blacklist file name patterns to eliminate DLLs from Linux packages.

[eliasildi]

Si por favor

[publicarray]

Here is how to build the jellyfin server on macOS maybe this can help.

$ brew cask install dotnet-sdk
$ git clone https://github.com/jellyfin/jellyfin.git && cd jellyfin
$ dotnet publish Jellyfin.Server --configuration Release --self-contained --runtime osx-x64 --output="/tmp/jellyfin" "-p:GenerateDocumentationFile=false;DebugSymbols=false;DebugType=none;UseAppHost=true"
$ /tmp/jellyfin/jellyfin --version
Jellyfin.Server 10.5.0.0