Can you run EmulationStation with debug logging and upload the log ? Exit ES, then run it with emulationstation --debug, reproduce the issue and then post the log file on pastebin.com.
The log file is in $HOME/.emulationstation/es_log.txt.

I've tried the steps you mention in reproducing the error, but as far as I see omxplayer stops once the screensaver is stopped.

Do you have any additional configurations in ES - namely any external scripts tied to the ES Scripting API ?

Please add some info about your setup, as requested in https://retropie.org.uk/forum/topic/3/read-this-first.

What does 'crash' mean ? EmulationStation freezes (without accepting any input) or it crashes with an error do the command line ?

@GreenHawk84 which version of Emulationstation are you running?

There has been a corner case [1], which escaped my mind in the first place, but then has been corrected by @pjft .

If your ES is below 2.10 (which I assume):

Either update to 2.10 onwards If you don't want to update use this workaround: Edit your ~/.emulationstation/es_settings.cfg while ES is not running and check the value of SlideshowScreenSaverCustomImageSource. Make it read false (you can also do it during ES is running in the Screensaver Options Menu).

Rationale: Your behaviour can happen on ES < 2.10 if you set your slideshow screensaver to use a custom image source and then switch to video screensaver (without disabling the image source flag).

Please report back if it solves your issue. And if it does, mark this topic with [solved] in your initial posting header.

[1] https://github.com/RetroPie/EmulationStation/commit/a8ccd0a75ba81b3e4af88ed3ebcfe08e57520ab6

0 pjft committed to RetroPie/EmulationStation Fix video screensaver launch game controls Video screensaver wasn't launching games when the Image screensaver had been set to use custom images, even if not in use. Introduced in #673 . Reported in https://retropie.org.uk/forum/topic/29291/video-screensaver-black-screen-with-omx-on-and-controls-not-working/

@sleve_mcdichael said in Video slideshow has blank screen between some videos:

They're read from the gamelist, right? Or no?

Yes.

After this PR will be merged, it will be possible to use a separate folder for videos, just like for images, in the screensaver.

@sleve_mcdichael said in Bug: ES video screensaver game info aligned center regardless of setting:

See?

I don't, really. The alignment for subtitles is an OMX feature only - which is not supported by omxplayer anymore on the Pi4 - so there's little to do on the ES side here.

@iandaemon Mainly the file size that I'd save in using Gifs rather than a video format - oh and I could make my own backgrounds and animations easily myself too.

alt text

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.

@sleve_mcdichael

Default will skip roms that have any piece of data from this source, and “only missing” will skip roms that have any piece of data from any source?

Yes, I had actually forgotten that point, it's quite an important distinction.

And you're welcome. Have fun with it!

In case anyone googles and finds this ... I did get to the bottom of it by looking into the source code (by source code I mean the RetroPie ES version, stable branch)

You can see here in VideoPlayerComponent.cpp where it launches omxplayer with a bunch of args:

VideoPlayerComponent.cpp:

// 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:

pi 2143 1 7 01:16 ? 00:00:08 --layer 10010 --loop --no-osd --aspect-mode stretch --vol -3885 -o alsa --win 0,0,800,480 --orientation 0 /home/pi/RetroPie/roms/neogeo/media/videos/trally.mp4

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.

So I quit es and ran this:

omxplayer.bin --layer 10010 --loop --no-osd --aspect-mode stretch -o alsa --vol -0 --win 0,0,800,480 --orientation 0 /home/pi/RetroPie/roms/neogeo/media/videos/trally.mp4

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.

No, at the moment this is not implemented in EmulationStation, the videos are always read from the gamelist.

@stuckinthe90s You are using a disposable email address which is bouncing. Please switch to a working non disposable address or I will have to remove/disable your account.

I think it would be a great idea. If it's not possible to implement it, could it be done using the theme system? 🤔

@RedMarsBlueMoon said in Would the (ES) screen saver shut game off?:

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.

Re: Looking for log/clue why ES video screensaver may get stuck w/black screen

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.