Hold on before installing the Snap version: I would not use Snap for OBS on your system.

Your result:

Unparseable OBS Version (30.0.2.1-3build1)
No Output Session
Missing Modules (1)

does not prove OBS caused the GNOME crash.

• Unparseable OBS Version likely means the OBS log analyzer could not interpret Ubuntu’s package version suffix, -3build1. You were using Ubuntu’s repository build, not the current OBS-supported Ubuntu build.
• No Output Session means that particular uploaded log did not contain a successful recording/streaming attempt, so it cannot diagnose the crash that happens when you click Start Streaming.
• Missing Modules (1) may matter, but we would need the actual missing module name.

The important part: Ubuntu’s stock OBS package is old — your package is 30.0.2.1-3build1 — and OBS’s official Ubuntu installation method is their PPA, not Snap. OBS forum guidance also states that the Snap build is not an official OBS package; the official Linux routes include the Ubuntu PPA and official Flatpak. citeturn916714search0 citeturn916714search6

Better move: reinstall using the official OBS PPA

If you have not finished installing Snap yet, cancel that route.

Remove the Ubuntu/Snap version:

sudo apt remove obs-studio
sudo snap remove obs-studio 2>/dev/null

Your OBS settings should normally remain in your home configuration folder; do not delete ~/.config/obs-studio.

Then install from the official OBS Ubuntu PPA:

sudo add-apt-repository ppa:obsproject/obs-studio
sudo apt update
sudo apt install obs-studio

Then confirm the new version:

obs --version
apt policy obs-studio

The Ubuntu repository version 30.0.2.1-3build1 has been reported alongside missing Browser Source and NVENC trouble on Ubuntu 24.04; moving to the official OBS package is a sensible correction before diagnosing GNOME/NVENC any further. citeturn916714search3 citeturn916714search14

After reinstalling

Keep the diagnostic test simple:

Encoder: Software (x264)
Resolution: 1280×720
Frame rate: 30 FPS
Capture: game window

Start a short stream without the game first. If the desktop survives, try with the game. Only after that test NVENC again.

If it crashes even using the official OBS build and software encoding, then the failure is likely in the GNOME/capture/session path rather than OBS’s NVIDIA encoder.

Ah. That PipeWire warning may be more relevant than the version warning, especially because your whole GNOME session crashes only when OBS begins streaming.

PipeWire handles audio routing on your system, and can also be involved in video/screen-capture paths. Your earlier inxi report showed PipeWire and WirePlumber active, even though your desktop session is X11. fileciteturn0file0 OBS problems involving PipeWire commonly show up as black captures, portal errors, or crashes when a capture source activates; the exact log wording matters here. citeturn118791search1

Before installing the Snap version

I would stop and save a copy of the actual OBS log first. The analyzer summary is not enough.

OBS logs are usually here:

ls -lt ~/.config/obs-studio/logs/ | head

Copy the newest one to your Desktop:

cp "$(ls -t ~/.config/obs-studio/logs/*.txt | head -n 1)" ~/Desktop/obs-crash-test-log.txt

Then open it:

xed ~/Desktop/obs-crash-test-log.txt

Search inside for:

pipewire
warning
error
nvenc
ffmpeg
xcomposite
portal

Paste the PipeWire warning line and a few lines above and below it. That will tell us whether PipeWire was merely initialized, missing a source, denied a portal permission, or actually failing.

Why I would avoid Snap for this test

Snap can introduce another permissions/confinement layer between OBS, PipeWire, your window capture, NVIDIA encoding, and GNOME. That may fix nothing or give us a second problem to untangle.

Use the official OBS PPA installation instead:

sudo snap remove obs-studio 2>/dev/null
sudo apt remove obs-studio
sudo add-apt-repository ppa:obsproject/obs-studio
sudo apt update
sudo apt install obs-studio
obs --version

OBS’s official Linux instructions list its Ubuntu PPA and Flatpak routes; Snap is not the route I’d choose for troubleshooting this on Ubuntu. citeturn118791search1

After installing from the PPA

Do a minimal test without the game:

Encoder: Software (x264)
Resolution: 1280×720
Frame rate: 30
Scene: simple Display Capture or Window Capture

Then click Start Streaming.

• If GNOME crashes even with software encoding and no game, the issue points toward the capture/PipeWire/GNOME path.
• If that works, add the game capture.
• If that works, switch back to NVENC.
• If only NVENC causes the crash, then the NVIDIA encode path is implicated.

But first, capture that actual PipeWire warning before changing the installation, because it may be the clue we need.

There we go. That fits the evidence much better than blaming the game or the NVIDIA driver.

Your earlier system check showed the RTX 3060 and NVIDIA driver operating correctly. fileciteturn0file0 The failure only occurred when streaming started, and replacing OBS with a clean install made the crash disappear. So the likely chain was:

broken/old/incomplete OBS build
→ stream output activates
→ capture/encoder/PipeWire/GNOME interaction fails
→ GNOME session throws the gray “Oops” logout screen

The strange version string:

30.0.2.1-3build1

was probably Ubuntu’s repository-packaged build rather than the version/interface you were used to. Whether it was corrupted or simply incompatible with your current streaming path, the reinstall replaced the troublemaker.

Since the Snap build is currently working, I would not touch it now. Finish what you were trying to do. Later, for your notes, record:

OBS stream crash fix:
Old OBS package/version: 30.0.2.1-3build1
Symptom: Starting stream crashed GNOME session to gray “Oops” logout screen.
Fix: Removed/reinstalled OBS through Snap.
Result: Streaming works normally again.
Game compatibility left on GE-Proton 10-15.

That is exactly the kind of “what the hell did I do last time?” note that saves you hours after a long break.

One small caution: if you later need OBS plugins or run into screen-capture permission weirdness, the official PPA or Flatpak may be worth revisiting. But for today: working beats theoretically ideal. Go claim your stream back.

This is usually fixable from the live USB, but the exact command depends on whether the install is UEFI or legacy BIOS. I’ll give you the safe detection step first, then both repair paths.

Yes — likely GRUB either installed to the wrong place, the firmware is looking at the wrong boot entry, or the EFI entry was not created correctly.

From the Linux Mint live desktop, open Terminal.

1. Identify disks and partitions

Run:

lsblk -f

Look for:

• Your installed Linux Mint root partition, probably ext4
• An EFI partition, usually vfat, around 100 MB to 1 GB, often mounted as /boot/efi

Also run:

sudo parted -l

You are looking for whether the disk uses GPT/UEFI or MBR/legacy BIOS.

2. Check if the live USB is booted in UEFI mode

Run:

[ -d /sys/firmware/efi ] && echo "UEFI mode" || echo "Legacy BIOS mode"

If it says UEFI mode, use the UEFI repair below.

---

UEFI GRUB repair

Assume:

Root partition = /dev/sda2
EFI partition  = /dev/sda1
Disk           = /dev/sda

Yours may be different. Replace these with what lsblk -f shows.

Mount the installed system:

sudo mount /dev/sda2 /mnt

Mount the EFI partition:

sudo mount /dev/sda1 /mnt/boot/efi

Bind system folders:

for i in /dev /dev/pts /proc /sys /run; do sudo mount --bind "$i" "/mnt$i"; done

Enter the installed system:

sudo chroot /mnt

Now reinstall GRUB:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=LinuxMint --recheck
update-grub

Exit and unmount:

exit
for i in /run /sys /proc /dev/pts /dev; do sudo umount "/mnt$i"; done
sudo umount /mnt/boot/efi
sudo umount /mnt

Reboot:

sudo reboot

Remove the USB when prompted.

---

Legacy BIOS GRUB repair

Use this only if the system is not UEFI.

Assume:

Root partition = /dev/sda2
Disk           = /dev/sda

Mount root:

sudo mount /dev/sda2 /mnt

Bind folders:

for i in /dev /dev/pts /proc /sys /run; do sudo mount --bind "$i" "/mnt$i"; done

Chroot:

sudo chroot /mnt

Install GRUB to the disk, not a partition:

grub-install /dev/sda
update-grub

Exit and unmount:

exit
for i in /run /sys /proc /dev/pts /dev; do sudo umount "/mnt$i"; done
sudo umount /mnt

Reboot:

sudo reboot

---

If you want the “most likely” path

On most modern machines, it is probably UEFI. So the likely flow is:

lsblk -f
[ -d /sys/firmware/efi ] && echo "UEFI mode" || echo "Legacy BIOS mode"

Then mount the Linux root partition to /mnt, mount the EFI partition to /mnt/boot/efi, chroot, and run:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=LinuxMint --recheck
update-grub

The important thing is: do not guess /dev/sda1 and /dev/sda2 blindly. Run lsblk -f first and tell me what it shows if you are unsure.