You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: SOLVED
It was an empty CMOS battery.
Reason: SSL Server connection failed because the CERT was not yet valid (wrong date)
I leave this open for a while,
because there may be a very very slim argument
that the shim player wants to be date/ntp aware.
(use case: no CMOS battery like a Raspi)
feel free to close this.
Description of setup
I set up a box with Ubuntu, simple Xorg autologin setup, for a single purpose shim player.
The shim player starts, after autologin, via an autostart hook in the GUI Desktop X session, and connects to Jellyfin.
After full config, I enabled Ubuntu's own overlayroot.
So this thing is supposed to be robust.
No session change is written after inital config.
All updates deactivated...
Server and shim player are both local. No internet in between. All cable. A reliable network.
Problem
Currently I don't know how to reconstruct solidly.
Every other/third reboot the shim player fails to connect to Jellyfin.
If I replug the device, it works again.
Does somebody have an idea what this might be? Especially: Is there something about the auth mechanism in the connection that inherently does not like overlayroot? (Like refreshed session keys, that overlayroot will delete)
Because if not, it's probably a different range of things, like boot timing or net stack dependencies.
To Reproduce
sometimes after boot.
reboot will often fix.
(but is overlayroot)
Expected behavior
An overlayroot should present the same conditions every time.
So login should always work.
Screenshots
See attached screenshot if fails.
Desktop
root@playa:~# uname -a
Linux playa 6.5.0-26-generic #26~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Mar 12 10:22:43 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
root@playa:~# cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.4 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
root@playa:~# cat /etc/overlayroot.conf
overlayroot="tmpfs:swap=1,recurse=0"
#overlayroot=""
playa@playa:~$ pip show jellyfin_mpv_shim
Name: jellyfin-mpv-shim
Version: 2.6.0
Summary: Cast media from Jellyfin Mobile and Web apps to MPV.
Home-page: https://github.com/jellyfin/jellyfin-mpv-shim
Author: Ian Walton
Author-email: [email protected]
License: GPLv3
Location: /usr/local/lib/python3.10/dist-packages
Requires: jellyfin-apiclient-python, python-mpv, python-mpv-jsonipc, requests
Required-by:
... hm it seems the dog may not be buried deep.
Looking at the dates in the logs, I suspect [[CMOS battery empty] && [race condition with ntpdate at boot]].
... will investigate
SOLVED.
replaced CMOS battery. This was it.
I leave this open for a while, because there may be a very very slim argument that the shim player wants to be date/ntp aware.
(use case: no CMOS battery like a Raspi)
feel free to close this.
labor4
changed the title
Ubuntu Headless, Autologin, Overlayroot: Connection Fail every other boot
Ubuntu Headless, Autologin, Overlayroot: Connection Fail every other boot [SOLVED]
Jun 6, 2024
Hi
Description of setup
I set up a box with Ubuntu, simple Xorg autologin setup, for a single purpose shim player.
The shim player starts, after autologin, via an autostart hook in the GUI Desktop X session, and connects to Jellyfin.
After full config, I enabled Ubuntu's own overlayroot.
So this thing is supposed to be robust.
No session change is written after inital config.
All updates deactivated...
Server and shim player are both local. No internet in between. All cable. A reliable network.
Problem
Currently I don't know how to reconstruct solidly.
Every other/third reboot the shim player fails to connect to Jellyfin.
If I replug the device, it works again.
Does somebody have an idea what this might be?
Especially: Is there something about the auth mechanism in the connection that inherently does not like overlayroot? (Like refreshed session keys, that overlayroot will delete)
Because if not, it's probably a different range of things, like boot timing or net stack dependencies.
To Reproduce
sometimes after boot.
reboot will often fix.
(but is overlayroot)
Expected behavior
An overlayroot should present the same conditions every time.
So login should always work.
Screenshots
See attached screenshot if fails.
Desktop
Error Messages
fail.log.txt
success.log.txt
The text was updated successfully, but these errors were encountered: