linux: Fix checkLinuxSystemInfo for Win/Mac

[mihawk90]

Description

Add an early return in checkLinuxSystemInfo for Windows or Mac logs, since it's unlikely® for them to return Linux specifics.

• alternative to linux: Fix checkLinuxSystemInfo detection #193

Motivation and Context

After #177 went live we've seen "No Distribution" logged for Windows and Mac, which is not ideal.

How Has This Been Tested?

$ cat linux-detections.sh 
#!/bin/bash

echo "===== Windows ====="
./loganalyzer.py --url "https://obsproject.com/logs/fol11bBs0Ia9ZfcZ" | grep '\--------------------------------------' -B4

echo "===== Mac ====="
./loganalyzer.py --url "https://obsproject.com/logs/1zSVQL3PxQlAFiBq" | grep '\--------------------------------------' -B4

echo "===== Fedora ====="
./loganalyzer.py --url "https://obsproject.com/logs/3G0ITqDVvenAhDbA" | grep '\--------------------------------------' -B4

echo "===== Missing os-release ====="
./loganalyzer.py --file missing-osrelease.log | grep '(Missing)' -A4

echo "===== Flatpak ====="
./loganalyzer.py --url "https://obsproject.com/logs/UJFGU6nrOPkN0oTI" | grep "Flatpak" -A4

$ head -n 16 missing-osrelease.log 
14:19:53.309: Command Line Arguments: --enable-media-stream --enable-multitrack-video-dev
14:19:53.309: Using EGL/X11
14:19:53.309: CPU Name: AMD Ryzen 9 5900X 12-Core Processor
14:19:53.309: CPU Speed: 3863.871MHz
14:19:53.310: Physical Cores: 12, Logical Cores: 24
14:19:53.310: Physical Memory: 15893MB Total, 6240MB Free
14:19:53.310: Kernel Version: Linux 6.17.4-200.fc42.x86_64
14:19:53.310: Distribution: Missing /etc/os-release !
14:19:53.310: Desktop Environment: KDE (KDE)
14:19:53.310: Session Type: x11
14:19:53.310: Window System: X11.0, Vendor: The X.Org Foundation, Version: 1.21.1
14:19:53.311: Current Date/Time: 2025-10-29, 14:19:53
14:19:53.311: Browser Hardware Acceleration: true
14:19:53.311: Qt Version: 6.9.2 (runtime), 6.9.2 (compiled)
14:19:53.311: Portable mode: false
14:19:53.338: OBS 32.0.1 (linux)

$ ./linux-detections.sh 
===== Windows =====
Critical: 
Warning:  
Info:     Windows 11 25H2 (OK), Hardware-accelerated GPU Scheduler, Third-Party Plugins (1)

--------------------------------------
===== Mac =====
Critical: 96.2% Rendering Lag
Warning:  
Info:     Third-Party Plugins (4)

--------------------------------------
===== Fedora =====
Critical: 
Warning:  Old Version (31.1.1), Wrong Color Range
Info:     No Output Session, Third-Party Plugins (2), Virtual Camera not available, Distribution: "Fedora Linux" 42 | Wayland | DE: KDE (KDE)

--------------------------------------
===== Missing os-release =====
Info:     No Output Session, Third-Party Plugins (6), Virtual Camera not available, Distribution: (Missing) | X11 | DE: KDE (KDE)

--------------------------------------
 
Details
--
Distribution: (Missing) | X11 | DE: KDE (KDE)
    No distribution detected. This can lead to undefined behaviour. Please
    consult your distribution's support channels on how to fix this.<br> 

===== Flatpak =====
Info:     No Output Session, Virtual Camera not available, Flatpak | Wayland | DE: KDE (KDE)

--------------------------------------
 
Details
--
Flatpak | Wayland | DE: KDE (KDE)
    You are using the Flatpak. Plugins are available as Flatpak extensions,
    which you can find in your Distribution's Software Center or via
    <code>flatpak search com.obsproject.Studio</code>. Installation of external
    plugins is not supported.<br>

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[mihawk90]

OK so, since it came up on Discord, I tested what an imaginary "borked" Linux install would even be logged as (which is what the else block was supposed to cover).
So I emptied out my /etc/os-release, and well...

$ cat /etc/os-release 

$ grep "Distribution" ~/.config/obs-studio/logs/2025-10-29\ 14-03-57.txt
14:03:57.136: Distribution: Unknown Unknown

So this whole else case was basically a no-op anyway.

Hence return early.

I think it's safe to assume that if OBS doesn't log a Distribution line at all, something else is likely to break or have broken first so we don't need it in the Analyzer (if OBS even starts in that case, who knows).

edit:
Another test (notice the empty NAME and VERSION_ID:

$ cat /etc/os-release 
NAME=
VERSION="42 (KDE Plasma Desktop Edition)"
RELEASE_TYPE=stable
ID=fedora
VERSION_ID=
VERSION_CODENAME=""
PLATFORM_ID="platform:f42"
PRETTY_NAME="Fedora Linux 42 (KDE Plasma Desktop Edition)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:42"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f42/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=42
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=42
SUPPORT_END=2026-05-13
VARIANT="KDE Plasma Desktop Edition"
VARIANT_ID=kde

$ grep "Distribution" ~/.config/obs-studio/logs/2025-10-29\ 14-19-53.txt 
14:19:53.310: Distribution: (null) (null)

Turns out OBS is pretty resilient against weird stuff 🫠

[mihawk90]

Added another commit for the case of /etc/os-release not being present at all, and logs the previous "No distro" helptext in that case.

OBS logs this intentionally:

https://github.com/obsproject/obs-studio/blob/c025f210d36ada93c6b9ef2affd0f671b34c9775/libobs/obs-nix.c#L295-L299

But this felt a little long for the bot and analyzer output in general, so we're shortening it to (Missing). Unknown and (null) are already logged for different cases (see above), and I wanted to retain the distinction of no file being present at all.

Tested with a modified log (see PR description)

---

Note:
The := operator is new in Python 3.8. If the Analyzer runs on an older version I can adjust it.

[RytoEX]

Relying on a check for /etc/os-release feels unfortunate, but I don't have any better ideas at the moment, and I'd like to avoid user confusion.

[mihawk90]

Relying on a check for /etc/os-release feels unfortunate

That's built into OBS and unrelated to the loganalyzer itself.
Pen just suggested since the check exists in OBS we might as well handle it explicitly. Although that being said in the last 5-ish years in linux-support I have never seen this in the wild, so I didn't even know this existed.

[RytoEX]

Relying on a check for /etc/os-release feels unfortunate

That's built into OBS and unrelated to the loganalyzer itself. Pen just suggested since the check exists in OBS we might as well handle it explicitly. Although that being said in the last 5-ish years in linux-support I have never seen this in the wild, so I didn't even know this existed.

Fair enough.