Unified Refried Steam Video Transition Issue (LaunchBox 13.26)

shadowfire36 · 2026-03-16T16:32:21Z

I’ve been troubleshooting an ongoing video transition/loading issue in the Unified Refried theme in Big Box, specifically with Steam. All other platform wheels appear to work fine; Steam is the only platform giving me this issue. Steam wheel videos appear to have a bad loading or transition behavior that does not happen the same way on other platforms. I chose Nintendo 64 as my comparison platform because its wheel behaves correctly and gives me a known-good reference to compare against.

Known-good reference set

The Nintendo 64 video set has been my reference point because those videos do not show the same loading/transition issue. When I checked them with ffmpeg/ffprobe, the N64 files were typically closer to:

H.264 / AVC
640x480
4:3
59.94 fps
AAC
48 kHz stereo

That became the benchmark I was comparing the Steam set against.

First Steam rebuild method used

The first rebuild method I used for the Steam videos was a yt-dlp + ffmpeg workflow that downloaded gameplay clips from YouTube-based search results and cut out a section from each video.

The workflow was:

search by game title + gameplay/no commentary
use yt-dlp
primary format selector:
best[ext=mp4]/best
fallback format selector:
bv*+ba/b
merge output as MP4
cut only a section of the source video instead of downloading the whole thing
output to a separate ready-for-LaunchBox folder first

The clip timing logic I used in that workflow was:

if the source video was under 5 minutes, clip from 00:02:00 to 00:02:30
if the source video was 5 minutes or longer, clip from 00:05:00 to 00:05:30

So the first rebuilt Steam set was being made from:

yt-dlp search/download
YouTube-based source matching
section cutting
MP4 merge

Even after that first rebuild, many of the Steam files still did not match the Nintendo 64 set closely. Steam files in that set were commonly things like:

640x360
around 30 fps
mixed H.264 profiles/levels
mixed container metadata
mixed audio/sample rate behavior

So although I rebuilt the videos, the first rebuilt Steam set was still inconsistent compared to the N64 reference set and was still a likely cause of the glitching/loading issue.

Second pass / second method used

After that, I moved the original Steam videos out to:

C:\Program Files\LaunchBox\Videos\Steam_Originals

The second pass was focused on rebuilding/retesting the Steam set against the N64 reference and checking whether the files themselves were the problem.

On this pass, I was no longer just treating the issue as missing videos. I was specifically comparing the Steam outputs to the N64 outputs and checking:

encoding differences
frame rate differences
aspect ratio differences
possible corrupt/glitch behavior
whether the first few seconds of the Steam clips were part of the issue

I also tested the idea that the front of the Steam clips might be the problem, because some of the Steam videos appeared to have bad startup behavior before they displayed correctly. That led to the idea of making a third set by trimming the first 10 seconds off the originals.

I also tested ARRM as a replacement workflow, but it only reliably pulled images, not videos, so it was not a valid solution for the Steam video snap issue.

So in practical terms, the methods I’ve used on the video side were:

Method 1

yt-dlp + section-cut workflow

yt-dlp search
download gameplay/no commentary source
best[ext=mp4]/best first
bv*+ba/b fallback
merge to MP4
clip from either 2:00 or 5:00 depending on total duration

Method 2

rebuilt/retested Steam set against N64 reference

moved originals to Steam_Originals
compared outputs with ffmpeg/ffprobe
checked whether the files themselves were causing the problem
investigated trimming the first 10 seconds from the front of each original as another test path

Media-side findings

The media-side findings so far are:

the original Steam set was inconsistent
the first rebuilt Steam set created with yt-dlp section-cut logic was also inconsistent relative to the N64 set
the N64 set remained the known-good reference
some Steam videos may also have startup/glitch issues in the first several seconds

So on the media side alone, I still have reason to believe the Steam files themselves are at least part of the problem.

What I checked in the Unified Refried theme

On the theme side, I searched the relevant XAML files for transition and animation behavior, including:

ImageVideoTransitionSelector
TransitionPresenter
Storyboard
BeginTime
Duration
FlowControl
DiscImage
Blackscreen
VideoBlackScreenImage
StretchVideo
Panel.ZIndex

I compared these files between Nintendo 64 and Steam:

WheelGamesView\Nintendo 64.xaml vs WheelGamesView\Steam.xaml
Wheel2GamesView\Nintendo 64.xaml vs Wheel2GamesView\Steam.xaml
Wheel3GamesView\Nintendo 64.xaml vs Wheel3GamesView\Steam.xaml
Wheel4GamesView\Nintendo 64.xaml vs Wheel4GamesView\Steam.xaml

XAML comparison results

WheelGamesView

Steam and Nintendo 64 were effectively the same except for art paths. I did not find any meaningful transition difference there.

Wheel4GamesView

Steam and Nintendo 64 were also effectively the same. I did not find any meaningful transition difference there either.

Wheel2GamesView

Steam had extra DiscImage rotation animation lines that Nintendo 64 did not have.

Wheel3GamesView

Steam also had extra DiscImage rotation animation lines that Nintendo 64 did not have.

Those extra Steam-only lines were:

At this point, the only actual behavior difference I found between the working Nintendo 64 setup and the problematic Steam setup inside Unified Refried was the extra DiscImage rotation animation in:

Wheel2GamesView\Steam.xaml
Wheel3GamesView\Steam.xaml

That makes those two Steam XAML files the strongest suspects on the theme side.

I also created PowerShell commands to back up the Steam wheel files and remove the DiscImage rotation lines automatically from those two files. I also verified that WheelGamesView and Wheel4GamesView did not show meaningful transition differences versus Nintendo 64.

Best summary

After checking both the media files and the XAML theme files, the strongest theme-side issue I found so far is that Steam has extra DiscImage rotation animations in Wheel2GamesView and Wheel3GamesView that Nintendo 64 does not have.

At the same time, the Steam video set itself has also been inconsistent. My first rebuild method used a yt-dlp section-cut workflow with MP4 merging and 2:00 / 5:00 start logic depending on source duration, but that rebuilt set still did not naturally match the N64 reference style. On the second pass, I moved the originals out, compared the Steam outputs directly against the N64 outputs, and started investigating whether the startup section of the Steam clips themselves was part of the issue.

So at this point, the issue may be a combination of:

inconsistent Steam video files and encoding/output behavior
Steam-specific Wheel2GamesView / Wheel3GamesView theme behavior in Unified Refried

Environment / device

This is being tested on LaunchBox 13.26 on an ROG Ally X (Xbox version). Because this is a handheld setup and not a desktop PC, I’m also trying to determine whether the issue is being influenced by the device itself, video decoding behavior, or performance differences when Steam videos load compared to Nintendo 64.

Edited 2 hours ago by shadowfire36

JoeViking245 · 2026-03-16T17:48:48Z

Pretty sure you can rule out the animation effect of the Disc images. That's a fairly basic WPF storyboard animation. May look impressive in code. But is essentially as simple for WPF to do as it is for it place text on the screen. You could comment out those 2 lines in the 2 files having them and test from there.

But if you're seeing the same issue in BB between all WheelxGamesView views (e.g. You see it using Wheel2 and also when using Wheel4), that will rule out the animation being an issue.

To supplement the extensive testing you've done thus far, grab an N64 reference video, make copies of it matching the filenames of your Steam videos. Move you original Steam videos to somewhere safe and place the 'copies' in their place.

Yeah, in this test, all Steam games' videos will "be the same video". But each game is accessing/loading a separate "file". Hope that makes sense.

This should rule out or confirm that the Steam videos, original, converted, trimmed or otherwise are the underlying issue. Which you may have deduced already and be a moot test.

Sign In