Can't make it work on Debian ARM64

[drunkinlove]

Checklist

• [X] I have checked the issue page for duplicates
• [X] I am running the latest version (download here)

Edition

Command Line Interface

Describe your issue here

Hi! I'm trying to use this on Debian 11 in a VM (UTM, latest) on an M2 Macbook (probably an obscure setup).

1. The TwitchDownloaderCLI-1.53.4-LinuxArm64.zip binary throws a Segmentation fault
2. When I try building from source using the LinuxArm64 profile, I get a binary that prints the following on launch:

You must install or update .NET to run this application.

App: /home/user/TwitchDownloader/TwitchDownloaderWPF/bin/Debug/net6.0-windows/publish/TwitchDownloaderWPF
Architecture: arm64
Framework: 'Microsoft.WindowsDesktop.App', version '6.0.0' (arm64)
.NET location: /home/user/.dotnet

No frameworks were found.

Learn about framework resolution:
https://aka.ms/dotnet/app-launch-failed

To install missing framework, download:
https://aka.ms/dotnet-core-applaunch?framework=Microsoft.WindowsDesktop.App&framework_version=6.0.0&arch=arm64&rid=debian.11-arm64

The compiled binary is located at TwitchDownloader/TwitchDownloaderWPF/bin/Debug/net6.0-windows/publish/TwitchDownloaderWPF.

Could you help me build this or make the precompiled binary work?

Add any related files or extra information here

No response

[ScrubN]

I do not own an arm machine to test the arm64 binary, that was added by a contributor, however if you could provide more details about the segfault and possibly even a .dmp file of the crash, I may be able to diagnose the issue.

As for TwitchDownloaderWPF, that is a Windows binary. I would suggest trying TwitchDownloaderCLI-1.53.4-LinuxArm.zip before trying to run the WPF application with wine.

[drunkinlove]

With the LinuxArm version, I get the following: -bash: ./TwitchDownloaderCLI: cannot execute binary file: Exec format error (which is weird, I thought it should run fine in compatibility mode?)

Here's the core dump that was generated after I set ulimit -c unlimited: https://drive.google.com/file/d/18vULdkkZewaEOpg0rgFWrdmC6pIBplfh/view?usp=share_link

I also get a segfault trying to run the arm64 version on arm64 Ubuntu Server. And weirdly, segfault again when trying the x64 version on an emulated x64 Debian. Could this be a fault of qemu?

[ScrubN]

Here's the core dump that was generated after I set ulimit -c unlimited: https://drive.google.com/file/d/18vULdkkZewaEOpg0rgFWrdmC6pIBplfh/view?usp=share_link

Unfortunately the dump lacks a heap snapshot, so the only information it can provide is the OS architecture and loaded system libraries.

[drunkinlove]

I tried using the x64 version of the app on Ubuntu with Apple virtualization framework (instead of qemu) and actually got a stack trace:

TwitchDownloaderCLI 1.53.4 Copyright (c) lay295 and contributors
[STATUS] - Fetching Video Info [1/5]Unhandled exception. System.AggregateException: One or more errors occurred. (The SSL connection could not be established, see inner exception.)
 ---> System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
 ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid because of errors in the certificate chain: UntrustedRoot
   at System.Net.Security.SslStream.SendAuthResetSignal(ProtocolToken , ExceptionDispatchInfo )
   at System.Net.Security.SslStream.CompleteHandshake(SslAuthenticationOptions )
   at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](TIOAdapter , Boolean , Byte[] , Boolean )
   at System.Net.Http.ConnectHelper.EstablishSslConnectionAsync(SslClientAuthenticationOptions , HttpRequestMessage , Boolean , Stream , CancellationToken )
   --- End of inner exception stack trace ---
   at System.Net.Http.ConnectHelper.EstablishSslConnectionAsync(SslClientAuthenticationOptions , HttpRequestMessage , Boolean , Stream , CancellationToken )
   at System.Net.Http.HttpConnectionPool.ConnectAsync(HttpRequestMessage , Boolean , CancellationToken )
   at System.Net.Http.HttpConnectionPool.CreateHttp11ConnectionAsync(HttpRequestMessage , Boolean , CancellationToken )
   at System.Net.Http.HttpConnectionPool.AddHttp11ConnectionAsync(HttpRequestMessage )
   at System.Threading.Tasks.TaskCompletionSourceWithCancellation`1.WaitWithCancellationAsync(CancellationToken )
   at System.Net.Http.HttpConnectionPool.GetHttp11ConnectionAsync(HttpRequestMessage , Boolean , CancellationToken )
   at System.Net.Http.HttpConnectionPool.SendWithVersionDetectionAndRetryAsync(HttpRequestMessage , Boolean , Boolean , CancellationToken )
   at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage , Boolean , CancellationToken )
   at System.Net.Http.HttpClient.<SendAsync>g__Core|83_0(HttpRequestMessage , HttpCompletionOption , CancellationTokenSource , Boolean , CancellationTokenSource , CancellationToken )
   at TwitchDownloaderCore.TwitchHelper.GetVideoInfo(Int32 videoId)
   at TwitchDownloaderCore.VideoDownloader.DownloadAsync(CancellationToken cancellationToken)
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean )
   at System.Threading.Tasks.Task.Wait(Int32 , CancellationToken )
   at System.Threading.Tasks.Task.Wait()
   at TwitchDownloaderCLI.Modes.DownloadVideo.Download(VideoDownloadArgs inputOptions)
   at CommandLine.ParserResultExtensions.WithParsed[T](ParserResult`1 result, Action`1 action)
   at TwitchDownloaderCLI.Program.Main(String[] args)

Is this insightful? The ARM versions seem to fail similarly.

[superbonaci]

I've downloaded Debian 11 (Xfce) ARM64 to run inside UTM, my ARM machine is Apple M1. It runs perfectly fine.

ARM unlike x86 or x86_64 is different for each CPU, so maybe yours is incompatible. If you were so kind to tell us which CPU is yours?

My CPU reported by hyfetch is:

CPU: 0x00 Architecture: aarch64 (4)

Maybe the cause is UTM. I've downloaded mine from Apple Store.

[drunkinlove]

@superbonaci hi! I'm on M2. hyfetch says the same (and I got a nice flag):

OS: Debian GNU/Linux 11 (bullseye) aarch64
CPU: 0x00 Architecture: aarch64 (4)

I installed UTM through the .dmg on their github.

This is kind of irrelevant, but the x64 version of TwitchDownloader worked for me today all of a sudden, I could download a VOD. (This is in docker by the way, not UTM. Also ignore that remark about Apple backend vs qemu as qemu also uses the former as I now understand).

I still get a segfault in ARM64 Debian (UTM) though.

[superbonaci]

@drunkinlove I'm not sure what you are doing, are you on MacOS 14.0? Could you try with the same debian iso as me Debian 11 (Xfce) ARM64? Are you using this version https://github.com/lay295/TwitchDownloader/releases/download/1.53.4/TwitchDownloaderCLI-1.53.4-LinuxArm64.zip?

I don't think the M1 vs the M2 can be the responsible...

Does you native binary work on MacOS https://github.com/lay295/TwitchDownloader/releases/download/1.53.4/TwitchDownloaderCLI-1.53.4-MacOS-x64.zip?

[drunkinlove]

@superbonaci I'm on Sonoma, yes, and I'm using the binary you linked. My Debian image is the ARM64 version from the official website. I'll try the one hosted by UTM if I have time... I'd rather not use unsigned apps on this Mac besides what's already installed, which is why I run stuff in VMs.

[superbonaci]

@drunkinlove yes find some time for it please. Maybe the ARM64 from Debian website is for another cpu.

[drunkinlove]

@superbonaci I tried this and it worked! 🤔 This is the first app I've had problems with on the official Debian image; ffmpeg, python, mp4box and others ran fine. Although I'm pretty sure I had to build everything else from source

[superbonaci]

@drunkinlove there are 3 ARM versions of debian for ARM: https://cdimage.debian.org/debian-cd/current/

• arm64
• armel
• armhf

Maybe you should ask in Debian Forums or follow the UTM guide for Debian. There must be some bug somewhere.

[drunkinlove]

The armel/armhf are for 32-bit architectures:

Debian fully supports three ports to different flavours of little-endian ARM hardware:

The ARM EABI (armel) port targets a range of older 32-bit ARM devices, particularly those used in NAS hardware and a variety of *plug computers. The newer ARM hard-float (armhf) port supports newer, more powerful 32-bit devices using version 7 of the ARM architecture specification. The 64-bit ARM (arm64) port supports the latest 64-bit ARM-powered devices.

My problem might be related to the SSL certificate chain and probably lies in the installation method. I'll report if I learn something new...

[superbonaci]

@drunkinlove hope you find the bug. I'd love to help you testing several Debian distros, but I'm already into lots of bugs that need fix.

The armel/armhf are for 32-bit architectures:

Yep but if your arch is 64 bit should run them no problem, unless they are not backwards compatible.