[jellyfin] Unable to start service on ds414

[jasonfenglu]

Setup

Package Name: jellyfin
Package Version: 10.7.6-3

NAS Model: ds414
NAS Architecture: Armadaxp
DSM version: DSM 6.2.4-25556

Expected behavior

It should be activated after turned on in GUI.

Actual behavior

Not being activated.

Steps to reproduce

1. Start jellyfin from Package Center

Package log

cat /var/packages/jellyfin/target/var/jellyfin.log

Mon Aug 16 12:50:56 CST 2021
Starting jellyfin command env LD_LIBRARY_PATH=/volume1/@appstore/jellyfin/lib /volume1/@appstore/jellyfin/share/jellyfin --service  --package-name synology  -d /volume1/@appstore/jellyfin/var/data  -C /volume1/@appstore/jellyfin/var/cache  -c /volume1/@appstore/jellyfin/var/config  -l /volume1/@appstore/jellyfin/var/log  -w /volume1/@appstore/jellyfin/web  --ffmpeg /var/packages/ffmpeg/target/bin/ffmpeg
[12:51:08] [INF] [1] Main: Jellyfin version: 10.7.6
[12:51:08] [INF] [1] Main: Environment Variables: ["[JELLYFIN_LOG_DIR, /volume1/@appstore/jellyfin/var/log]", "[DOTNET_BUNDLE_EXTRACT_BASE_DIR, /var/packages/jellyfin/target/var//dotnet_bundle_extract]"]
[12:51:08] [INF] [1] Main: Arguments: ["/volume1/@appstore/jellyfin/share/jellyfin.dll", "--service", "--package-name", "synology", "-d", "/volume1/@appstore/jellyfin/var/data", "-C", "/volume1/@appstore/jellyfin/var/cache", "-c", "/volume1/@appstore/jellyfin/var/config", "-l", "/volume1/@appstore/jellyfin/var/log", "-w", "/volume1/@appstore/jellyfin/web", "--ffmpeg", "/var/packages/ffmpeg/target/bin/ffmpeg"]
[12:51:08] [INF] [1] Main: Operating system: Linux
[12:51:08] [INF] [1] Main: Architecture: Arm
[12:51:08] [INF] [1] Main: 64-Bit Process: False
[12:51:08] [INF] [1] Main: User Interactive: True
[12:51:08] [INF] [1] Main: Processor count: 2
[12:51:08] [INF] [1] Main: Program data path: /volume1/@appstore/jellyfin/var/data
[12:51:08] [INF] [1] Main: Web resources path: /volume1/@appstore/jellyfin/web
[12:51:08] [INF] [1] Main: Application directory: /volume1/@appstore/jellyfin/share/
[12:51:13] [INF] [1] Emby.Server.Implementations.AppBase.BaseConfigurationManager: Setting cache path: /volume1/@appstore/jellyfin/var/cache
[12:51:15] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Defined LAN addresses : [127.0.0.1/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16]
[12:51:15] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Defined LAN exclusions : []
[12:51:15] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Using LAN addresses: [127.0.0.1/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16]
[12:51:15] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Using bind addresses: []
[12:51:15] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Using bind exclusions: []
[12:51:15] [INF] [1] Emby.Server.Implementations.ApplicationHost: Loading assemblies

Other logs

If starting jellyfin from command line by:

sudo env LD_LIBRARY_PATH=/volume1/@appstore/jellyfin/lib /volume1/@appstore/jellyfin/share/jellyfin --service  --package-name synology  -d /volume1/@appstore/jellyfin/var/data  -C /volume1/@appstore/jellyfin/var/cache  -c /volume1/@appstore/jellyfin/var/config  -w /volume1/@appstore/jellyfin/web  --ffmpeg /var/packages/ffmpeg/target/bin/ffmpeg

The outputs are:

[12:59:23] [INF] [1] Main: Jellyfin version: 10.7.6
[12:59:23] [INF] [1] Main: Environment Variables: ["[JELLYFIN_LOG_DIR, /volume1/@appstore/jellyfin/var/data/log]"]
[12:59:23] [INF] [1] Main: Arguments: ["/volume1/@appstore/jellyfin/share/jellyfin.dll", "--service", "--package-name", "synology", "-d", "/volume1/@appstore/jellyfin/var/data", "-C", "/volume1/@appstore/jellyfin/var/cache", "-c", "/volume1/@appstore/jellyfin/var/config", "-w", "/volume1/@appstore/jellyfin/web", "--ffmpeg", "/var/packages/ffmpeg/target/bin/ffmpeg"]
[12:59:23] [INF] [1] Main: Operating system: Linux
[12:59:23] [INF] [1] Main: Architecture: Arm
[12:59:23] [INF] [1] Main: 64-Bit Process: False
[12:59:23] [INF] [1] Main: User Interactive: True
[12:59:23] [INF] [1] Main: Processor count: 2
[12:59:23] [INF] [1] Main: Program data path: /volume1/@appstore/jellyfin/var/data
[12:59:23] [INF] [1] Main: Web resources path: /volume1/@appstore/jellyfin/web
[12:59:23] [INF] [1] Main: Application directory: /volume1/@appstore/jellyfin/share/
[12:59:24] [INF] [1] Emby.Server.Implementations.AppBase.BaseConfigurationManager: Setting cache path: /volume1/@appstore/jellyfin/var/cache
[12:59:25] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Defined LAN addresses : [127.0.0.1/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16]
[12:59:25] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Defined LAN exclusions : []
[12:59:25] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Using LAN addresses: [127.0.0.1/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16]
[12:59:25] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Using bind addresses: []
[12:59:25] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Using bind exclusions: []
[12:59:25] [INF] [1] Emby.Server.Implementations.ApplicationHost: Loading assemblies
Illegal instruction

From the output of "illegal instruction", I am guessing the problem relates to arm compiling?

[publicarray]

Duplicate of publicarray#28

and dotnet/runtime#56706

[publicarray]

Can you swap the /volume1/@appstore/jellyfin/lib/stdlib++.so.6.0.22 file with a armel version e.g. from https://packages.debian.org/sid/armel/libstdc++6/download
if that makes any difference please let me know.

armhf vs armel.
From what I understand it should be armhf but armel might have better compatibility with older chips. Your CPU does have a hardware floating-point instruction, so it should be armhf but other than a core .NET devs getting a core dump there is nothing else I can do.

[publicarray]

I've compiled a armel version here: https://seby.io/files/jellyfin_armv7-6.1_10.7.6-3.spk

[jasonfenglu]

I've compiled a armel version here: https://seby.io/files/jellyfin_armv7-6.1_10.7.6-3.spk

Still not working using GUI to start.
Here is the log:

admin@niobe:~$ sudo cat /var/packages/jellyfin/target/var/jellyfin.log
Password:
Mon Aug 16 22:17:31 CST 2021
Starting jellyfin command env LD_LIBRARY_PATH=/volume1/@appstore/jellyfin/lib /volume1/@appstore/jellyfin/share/jellyfin --service  --package-name synology  -d /volume1/@appstore/jellyfin/var/data  -C /volume1/@appstore/jellyfin/var/cache  -c /volume1/@appstore/jellyfin/var/config  -l /volume1/@appstore/jellyfin/var/log  -w /volume1/@appstore/jellyfin/web  --ffmpeg /var/packages/ffmpeg/target/bin/ffmpeg
/volume1/@appstore/jellyfin/share/jellyfin: error while loading shared libraries: /volume1/@appstore/jellyfin/lib/libstdc++.so.6: internal error

[publicarray]

Ok thanks for confirming. So It's up to the .NET developers if they want to spend resources for this CPU.
We can only mark the CPU architecture as unsupported 😢

[jasonfenglu]

So sad to hear that, and thank you for the help.

[jasonfenglu]

Ok thanks for confirming. So It's up to the .NET developers if they want to spend resources for this CPU.
We can only mark the CPU architecture as unsupported 😢

Sorry for closing and reopening the issue.
Does this means that the package from SynoCommunity will be temporary removed and put that back if .NET is supporting this CPU in the future?
I am wandering if I can still receive update from SynoCommunity if I install the package from Package Center.

[publicarray]

Does this means that the package from SynoCommunity will be temporary removed and put that back if .NET is supporting this CPU in the future?
I am wandering if I can still receive update from SynoCommunity if I install the package from Package Center.

Yea that will work, but I don't have a time frame. If you can get someone from Microsoft or a Jellyfin dev to look at it to gain more traction that would make it go quicker. But since it's hardware specific, without the hardware or a couple of core dumps for the devs I don't think this will progress.

[jak8]

Publicarray's app (not docker version) is still up in the community section with no qualifications. Tried loading and running it 4 times on a DS1817 and it refuses to start. Suggest he removes it .

[publicarray]

I'm sorry to hear that @jak8, but the package is tested as working with a x64 CPU and should also work on aarch64. Some armv7 should also work, but the alpine CPU architecture that you have is known to have issues with .NET framework as the architecture doesn't have some of the necessary CPU features used by .NET.

[jak8]

Thanks for that Seb, I will never buy an arm7 unit again as they have such major limitations. I did suspect it was the CPU which was in effect the culprit. Maybe mention of this on the associated instructions would help. Quite why Synology advertise its use on this unit, the DS1817, is beyond me but I am losing much faith in them as a corporation. Take care Jak

…

On Thu, 15 Dec 2022 at 09:05, Sebastian Schmidt ***@***.***> wrote: I'm sorry to hear that @jak8 <https://github.com/jak8>, but the package is tested as working with a x64 CPU and should also work on aarch64. Some armv7 should also work, but the alpine CPU architecture that you have is known to have issues with .NET framework as the architecture doesn't have some of the necessary CPU features used by .NET. — Reply to this email directly, view it on GitHub <#4790 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD6G6OAI6ADD4MUCEYLDGL3WNLNODANCNFSM5CG7IS7A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mreid-tt]

@jak8, I've been trying to solicit feedback to confirm compatibility with .NET builds of Radarr, Lidarr and Sonarr v4 running on ARMv7 architectures. As you are running on an alpine architecture, if you have the time perhaps you can check out #5574 and add your feedback on the test packages I've shared. Appreciate the support.

[mreid-tt]

@jak8, @jasonfenglu, there is some evidence to suggest (#5432 (comment)) that upgrading from DSM6 to DSM7 on some ARMv7 archs (except armada370) may allow jellyfin to start successfully. Do let me know if this is the case for you.

[mreid-tt]

With the release of Jellyfin 10.8.9 to the SynoCommunity repository, it removes all support for 32-bit architectures (includes all ARMv7 archs). As such, I recommend that this ticket be closed as these platforms will no longer be supported moving forward.