Fails to load / start [linux]

[hiisukun]

Bug report

• I understand the difference between Streamlink and Streamlink Twitch GUI.
• This is a bug report and I have read the contribution guidelines.

Environment details

Operating system and version:

Fedora 31 (Linux 5.3.16)

Streamlink Twitch GUI version:

1.9.0

Streamlink version:

1.3.0

Configuration details:

Fedora 31 has python3 as default (ie. the python command) but python2 is still installed.

Description

When I launch streamlink with the regular menu shortcut, nothing happens. Running it in the console shows it starting, then just hanging.

Expected / Actual behavior

Streamlink launches and the window pops up where I can select streams etc.

Reproduction steps

Run streamlink-twitch-gui from the menu item.

Log output

This is the output:

Fontconfig warning: "/usr/share/fontconfig/conf.avail/05-reset-dirs-sample.conf", line 6: unknown element "reset-dirs"
[314035:314035:0107/185301.031728:ERROR:component_loader.cc(165)] Failed to parse extension manifest.
[314055:314055:0107/185301.078135:ERROR:sandbox_linux.cc(371)] InitializeSandbox() called with multiple threads in process gpu-process.
[314073:314073:0107/185301.119947:FATAL:nw_content_renderer_hooks.cc(53)] Failed to load node library (error: libatomic.so.1: cannot open shared object file: No such file or directory)
#0 0x7fa273f59df9 <unknown>

The terminal hangs waiting at that point, until I ctrl+c.

I think I recognise the fontconfig line (and maybe it isn't important?) as a long standing Fedora default. I moved that file out of the directory, and it didn't help streamlink launch.

Additional comments, screenshots, etc.

• I have streamlink installed via pip, and I did a force reinstall/upgrade
• Moving the fontconfig error file didn't matter
• Launching streamlink 1.8.1 didn't help (it also hung!)
• Renaming ~/.config/streamlink-twitch-gui didn't help
• Renaming ~/.cache/streamlink-twitch-gui didn't help
• I did a dnf reinstall libatomic (which was already installed) and this also didn't help. Package version is 9.2.1

[hiisukun]

I've done a dnf upgrade and upgraded various components, but the problem persits. I'm not on kernel Linux 5.4.7 in case that is useful.

[hiisukun]

So I noticed my libatomic was 32bit. I installed libatomic.x86_64 and now streamlink is back working. User error, or requirements changed over time, or an unrelated package removed this library? I'm not sure since I don't use this gui often enough.

Closing this issue! : )

[bastimeyer]

libatomic is required by NW.js' libnode.so, which according to a quick search is a recent addition to NodeJS. On Arch, libatomic is provided via the gcc-libs package. I can't help with these kinds of dependency problems though, because I'm not a Fedora user and don't have any knowledge about its package base.

You can check the list of shared system libraries by using the ldd utility on the main NW.js executable (renamed to streamlink-twitch-gui) or its included shared libraries in the libs subdirectory. If there's one which could not be loaded, make a reverse file search with your distro's package manager and find out which package you're missing.

Since NW.js is basically Chromium+NodeJS+stuff, having Chromium and NodeJS installed on your system will usually help with missing dependencies if you're using a distro where no Streamlink Twitch GUI package is available for.

---

I know that these problems would not exist if there were packages available for most of the major Linux distros like Debian/Ubuntu, Fedora, etc, but unfortunately, including Streamlink Twitch GUI into these distros is not possible due to being built on top of a pre-built NW.js, and changing that is a whole new rabbit hole. Having a custom package repo is also not a proper solution (I tried in #319, but it's very much outdated now), because I would either have to pay high monthly fees, which I absolutely won't do, or it would be very limited in terms of file traffic and storage space. BinTray is the only hoster I know which offers a free service, but it's just not enough for NW.js applications (unless they've lifted some of these limitations).

And even then, having to know each package name of NW.js' dependencies for all these various distros and the versions of the non-rolling distros is something I don't want to spend time on. I need dedicated package maintainers for that.

The only solution seem to be Flatpack, Snap and/or AppImage, so I can have universal packages, but I haven't spent much time on reading how to create and distribute those, because it's quite complex. I should give AppImage a go though, because among those three, it just makes more sense, as it is a complete standalone solution. (#616)

[hiisukun]

G'day @bastimeyer ! Thanks for the lengthy response. And thank you for the excellent software too.

I think packaging is still quite a lot of work for project maintainers, particularly if targetting both deb and rpm, and likely not worth the effort as a solo maintainer.

From my limited perspective, I wholeheartedly agree with #616 - with the small comment that Flatpak is seeing a little more adoption than Snap. I have used AppImage successfully for a few pieces of software and it was very painless. Just a giant file to execute directly, it seemed, and in the three or four occasions I've done that there were no issues at all.

When installing streamlink-twitch-gui on a new system, I have used the add-menuitem.sh .. so you could consider adding an ldd check into that script? The linkage is actually to lib/libnode.so so it would like something like:

if command -v ldd >/dev/null 2>&1 ; then 
    # Found ldd command
    LIBCHECK=$(LD_LIBRARY_PATH=${HERE}/lib ldd ${HERE}/lib/libnode.so | grep "not found")
    if [ ! -z "${LIBCHECK}" ]; then
        # Missing a required libary
	echo "[!] Streamlink twitch gui requires a library that your system does not have installed."
        echo "    Try using your package manager to search for and install them: "
	echo "${LIBCHECK}"
    fi
fi                                                                                                               

You have the option of assuming ldd will be present (does anyone have coreutils without glibc common? surely not!) which can skip the first if/then block.

I know this won't solve the issue for everyone, as it is kinda hidden in the add menu item script, but I don't think you should spend the time to do package management. Cheers again : )

[bastimeyer]

so you could consider adding an ldd check into that script?

There already was a launch script which did that because of an issue with old Ubuntu releases, but it got removed again (#615):
0841a5d#diff-275a8edf0d9a930191f0d933eebfc423

I don't want to add this again, especially not if it's just a simple check with a warning message. Adding a troubleshoot page to the wiki sounds like a better idea to me.