Far as I know, OMXolayer simply does not work together with game info displayed -- turn off one or both.
The remaining videos, it's almost certainly the video format. Use one of the scripts linked above to convert your existing videos. See this post to setup Skyscraper to detect and convert wrong-format videos on initial download, for future scrapes.
// Run the omxplayer binary
execve("/usr/bin/omxplayer.bin", (char**)argv, (char**)env);
Now if you fire up ES, launch the screensaver, and take a look in the process list while its running (in ssh session, ps -ef) you'll actually see all those args, something like this in the process list:
What I noticed is the volume is set to -3885. Now if I run that on the command line to simulate the screensaver I can play with the volume. For omxplayer, volume 0 should be 100% as it's measured in millibels according to the omxplayer help.
ok great I can hear it now! I researched %vol to db and the formula is db = 20*log(%vol) and that checks out because I had es at roughly 65% volume which equates to about -3742 millibels.
So I went back into es and set the volume to 100%, and now I can finally hear it on a default RetroPie install. The issue is the drop off is really steep (must be some bug in omxplayer on pi, that their millibels to volume curve is off) because if you set the volume level at say, 60% you won't hear much of anything from the speakers. I think this is also compounded by the fact that when you're playing around with the audio settings in es, many times it resets the volume back to zero because it's trying to sync up the level with alsa.
Anyway, hope this helps someone get their head around the screensaver audio.
p.s. also, in es audio settings, make sure you set the "omx player audio device" to alsa (or whatever works on your pi, or in your command line experiments), as that drives the argument sent into omxplayer above.
Does it get cleared on restart? As I have rebooted several times since the issue above.
Yes, /dev/shm is a RAM backed folder, restarting would clear it. The file is present after the game is run and it's also overwritten each time a game is launched, so if you want to get the actual error, you need to get the file immediately after the crashed game stops.
Closing the thread on this. There is nothing wrong with the randomizer. While there was exactly one (1) "Little Computer People" video, there were ~100 variations of the game in the XML referencing the same video. So it's probably by design. It would seem that each game listed in XML with a valid video has the potential to play. Like throwing 100 tickets into a casino raffle drum... You're more likely to win.
Ideally each video found should act as 1 potential. Not a big problem, but since games with multiple variants that reference the same video are more likely to play, making things seem less random than they truly are.
Mystery solved after spending way too much time staring at random videos.