Please test: Random Game selection/launch via Video Screensaver

incunabula

Updating omxplayer didn't seem to help and I've also tried 2 other themes but the blanking continues. I may try with a fresh image soon; the one I'm testing with is a few months old and somewhat cluttered.

pjft

@incunabula thanks for the effort in testing! The detail you sent helps a lot. Don't worry about a new image, it'll be a waste of time. It's definitely OMX Player related.

I have an idea that might fix that, and I'll put together a new build tomorrow for you to test. I ran into a similar problem during development with the subtitles, hence that being one of my suggestions. :)

Truth be told, after I changed a couple of things it went away, so I thought it was fixed. Obviously I was wrong.

If it doesn't work then, I may be out of options. We'll see.

Does it not try to set that resolution when there are no subtitles? What resolution does it attempt to use in that case? And what's the resolution of your screen?

Thanks! Talk tomorrow:)

incunabula

@pjft Without the captions it's running 1920 x 1080 which is what I normally run es in. Will switching to ffmpeg allow the captions feature? Seems like that would be the best of both worlds if so - hardware decoding and the nifty features we want (I was reading the es video preview thread earlier).

**Scannigan**

@pjft By jove you've done it!! That worked a treat. One final thing, is there a way to make the screensaver full screen?

pjft

@incunabula Hopefully :) That's where we want to go. @fieldofcows is investigating that. I don't see why not. In fact, if we get that running, we might not need to do this hackily via subtitles, but maybe via a proper overlay!

I changed the fullscreen rendering from OMX. Test out this new build and see how it goes. It's a shot in the dark, as I don't have visibility into the inner workings of OMX Player :/

https://github.com/pjft/EmulationStation/releases/tag/v0.4

i.e.

mkdir /home/pi/tmp-es
cd /home/pi/tmp-es
rm emulationstation
wget https://github.com/pjft/EmulationStation/releases/download/v0.4/emulationstation
chmod +x emulationstation
cd /opt/retropie/supplementary/emulationstation
sudo cp /home/pi/tmp-es/emulationstation /opt/retropie/supplementary/emulationstation

@Scannigan I'm happy it's working out! The video should be as full screen as EmulationStation (i.e. if ES has some borders for you, the video will also do it). Or do you mean that the video should be stretched? The reason it isn't is because different games had different resolutions - and truth be told, none of them were 16:9 :) That's why there are always side borders at least.

Happy to consider stretching if it helps, though I found it made games look deformed.

**Scannigan**

@pjft ES is full screen I think the image would need to be stretched, if it's too much trouble don't worry about it, I'm sure I can live with it :)

pjft

@__Scannigan__ I see.

I'm sure it's not a big deal to implement that, just another option though.

I'll look into making that change and publishing a new build.

pjft

@__Scannigan__

If you run the previous commands but use the link to this binary on wget, it should now have an option in "Other Settings" for stretching the video on the screen saver.

https://github.com/pjft/EmulationStation/releases/download/0.4stretch/emulationstation

Best.

incunabula

@pjft I tried the 0.4 release and the issue persists :( I want to try it on a fresh image so i'll let you know how that goes.

pjft

@incunabula I'm sorry to hear that.

I'll provide you with a full set of commands to run later for the purpose of troubleshooting.

Would you have a video of the behavior, for me to see what's happening? I take it you haven't edited your config.txt file in any way that you know of, in regards to the video output?

Also, could you run the following commands and register their output? (Taken from here).

Run “tvservice –m CEA” to give a list of CEA supported modes.
Run “tvservice –m DMT” to give a list of DMT supported modes.
Run “tvservice -s” to give you the current state.

Then, the following:

Run “tvservice –d test.txt” to capture a monitor’s EDID.
Pass this file to edidparser. Run “edidparser test.txt”.

Thanks.

Edit: I also found this about updating your kernel, might be worth a shot if you have a backup of your pi or a second card:

http://stevenhickson.blogspot.ie/2013/02/updating-your-raspberry-pi-packages.html?m=1

What's the output of

uname -a

For you?

I'll send over the commands for further digging later. Thanks for the help here.

Also, what pi model are you on? 2? 3? I take it you have never changed the GPU memory split settings, right?

pjft

@incunabula hi!

If you're moderately comfortable with playing in the command line and editing files, see this other thread:

https://retropie.org.uk/forum/topic/7739/video-splash-screen-problems/

Some people who seemed to have similar issues sorted it out by tweaking the config.txt file. See if any of that helps and let us know.

Ignore the references to 10000 - that's on the OMX Player side. I'll send the list of commands later to test. On my phone at the moment.

In particular:

sudo nano /boot/config.txt

Set

disable_overscan=1

Does it help? If not, revert it back to how it was before (I take it it was 0?).

**Scannigan**

@pjft Thanks so much, this is fothermucking amazing!

Noticed a few other settings that weren't there before which is nice :)

Did stumble across the following errors though after screensaver looping one video and controls becoming unresponsive, it's only happened once so far.

lvl0: Error creating SDL window!
Could not create GLES window surface
lvl0: Renderer failed to initialize!
lvl0: Window failed to initialize!

pjft

@__Scannigan__ Thanks - glad it worked out.

I'm curious about that error. I usually don't like to dismiss them and say they're not related to this, given how many times I've been wrong in the past :)

However, that stack trace is in the main.cpp file, and it's a stack trace from failing to initialize the renderer, which then fails to initialize the window.

It may also happen when restarting ES after launching a game, but we shouldn't have a log of that message: "Window failed to initialize".

Did this per chance happen after you launched a game from the screensaver? Had you quit ES at any point in time and launched it again?

Is it working fine otherwise?

Thanks!

**Scannigan**

@pjft I was skipping through screensaver videos then then would just loop, I think i'd just rebooted ES to be fair

pjft

@__Scannigan__ Thanks. That usually may happen if a OMXPlayer process just gets left in memory - meaning that it won't react anymore to the controls because there's nothing really attached to it. For instance, if you kill the ES process while it's running the screensaver, that may happen as the OMXPlayer process is separate.

You're saying that you were just browsing the videos and skipping videos very quickly when that happened? Let me know if it happens again. I don't think the ES code would run in a multi-threaded way such that it'd be possible to be launching the process and trying to kill it before we know the process ID. But it's all possible. Let me know what you find.

@incunabula So, OMXPlayer debugging.

First, some not-so-good news. As I mentioned, we don't control much with OMX Player. It seems that this is not an isolated problem, and can happen when there are too many elements/layers being handled by dispmanx . It's an interesting thread to read, if you're interested in it, but that's the summary. Video mode may affect the outcome.

Going back to our troubleshooting, though. The command we're calling to render the video is templated around

omxplayer --layer 10010 --loop --no-osd --aspect-mode [letterbox/stretch] --win 0,0,<width>,<height> --subtitles <subtitle_path> <video_path>

So, for instance, one example for me would be

omxplayer --layer 10010 --loop --no-osd --aspect-mode letterbox --win 0,0,1920,1080 --subtitles /home/pi/.emulationstation/tmp/last_title.srt /home/pi/RetroPie/videos/arcade/yard.mp4

[I don't fully know the resolution - I'm assuming it is 1920 and 1080, but I never forced an output of that - it's computed on the fly based on the individual screen dimensions]. If you remove the whole "--win 0,0,width,height" it will render fullscreen, which was how it was in 0.3 . In 0.4 I just forced it to use the explicit screen dimensions hoping it'd help with the resolution settings.

So, what can we test to help sort this out?

Exit EmulationStation
Create a fake subtitle file

cd /home/pi
mkdir tmp_sub
nano subtitle.srt

and paste there

1
00:00:01,000 --> 00:00:08,000
Test Game
<i>Test System</i>

2
00:00:29,000 --> 00:00:35,000
Test Game
<i>Test System</i>

exit with Ctrl+X, and Y(es)

After this, run

tvservice -s

to get the current screen's resolution.
4. Now run OMX Player with the screen resolution we got, with NO subtitles:

omxplayer  --layer 10010 --no-osd --aspect-mode letterbox --win 0,0,<your width>,<your height> <path to one of your videos - ex: /home/pi/RetroPie/<where you store videos>/<video>.mp4  >

If all went well, try adding subtitles now:

omxplayer --layer 10010 --no-osd --aspect-mode letterbox --win 0,0,<your width>,<your height> --subtitles /home/pi/tmp_sub/subtitle.srt <path to one of your videos - ex: /home/pi/RetroPie/where you store videos/video.mp4 >

If all is well so far, let's proceed to the next tests. If not, try playing with the resolution - reduce it a bit, see if it helps. Try another video.

Now, let's launch EmulationStation, and set its screensaver to Black, so it doesn't start the video one. Leave it in the System View screen, and let it go to screensaver (i.e. have the screen turn black).
Login to the Pi via SSH, and now let's manually run the same two commands from 4. and 5. I expect 4. to run well, and 5. to have problems. If it doesn't, take note of the command you ran and send it over, and stop the test for the time being. But I expect that to be weird.
If it does, let's now troubleshoot 5. by tweaking with the options, and see if anything does help - one at a time, though, so revert previous changes before trying new ones.
8.1. Increase layer number (from 10010 to something larger - 15000, 20000, something).
8.2. Force "stretch" aspect mode, by replacing "letterbox" with "stretch"
8.3. Removing the "aspect mode" option altogether (i.e. remove --aspect-mode letterbox)
8.4. Force Black screen behind it by adding "-b" as an option, before the video path. (i.e. it cannot be the last option, but can be anywhere before that).
8.5. Remove the --win <resolution> option altogether.
8.6. Add option "-z" before the video path. (i.e. it cannot be the last option, but can be anywhere before that).
8.7. Add option "--nodeinterlace" before the video path. (i.e. it cannot be the last option, but can be anywhere before that).
8.8. Add option "--no-ghost-box" before the video path. (i.e. it cannot be the last option, but can be anywhere before that).
8.9. Add option "--nativedeinterlace" before the video path. (i.e. it cannot be the last option, but can be anywhere before that).
8.10. Add option "-r" before the video path. (i.e. it cannot be the last option, but can be anywhere before that).

You may find the controls here - namely using "q" for quitting, assuming you're using a USB keyboard connected to the Pi. Or, if in ES, just exit the screensaver by pressing any button in the controller. Worst case scenario, run from the command line:

killall omxplayer.bin

I'm also curious about the output of

vcgencmd dispmanx_list

when the problem is happening, if you can login via SSH and get that.

Sorry about the long list of tests. Truth is, as it doesn't happen with me, I can't really do a lot to test out, and it's easier to ask you to test a few combinations and see if any are successful instead of providing you several different builds with tiny tweaks. Especially as it seems we're in different time zones altogether :)

The goal here is to determine whether:
a) we can replicate the problem manually with ES and OMXPlayer on top, and
b) if so, if we can find out a way to avoid it as well, manually.

If we can, I'll update the way we call OMXPlayer and send you a new build, hoping that it solves it for good for you. :)

Thanks for the time and effort here. Also, if you do have the change to run the commands I sent you in a previous post, about getting the TV modes for your screen, that'd be good as additional info. As well as trying the disable_overscan option as well!

Finally, if we can't get anything sorted here, worst case scenario you can disable the subtitles option and we can hope that the ffmpeg work from fieldofcows produces a positive result that works for all. I do hope I can help in the interim, though.

I can also get back the option of letting VLC do the screensaver rendering, but the captions are really lousy with that option - i.e. really, REALLY blocky, low resolution text. But if it may help, I'm happy to provide that as a worst case scenario.

Let me know your results - looking forward to it!

**Scannigan**

Now I'm getting a shed load of glGetError 0x505 errors bud

pjft

@__Scannigan__ Hm.

The only reference I get to that error seems to be related to video memory, and in the code, it seems to be related to the Texture handling to avoid the WSOD problems. In particular, it means out of video memory.

The tips in that answer I linked to point to the raspi-config Video split, which seem to suggest that this is the wiki page that could help you, specifically for heavier themes which seems to be your case. However, from the text, I'm unsure this still applies and how, given that it states we currently override that setting? I infer that you'd open your config.txt file and edit the amount of memory for video:

sudo nano /boot/config.txt

then find the override for gpu_mem_1024 (should state 256) and maybe increasing it to 384 or even 512 will help for heavier themes. @dankcushions (sorry for adding you here - please let me know if this is not adequate forum etiquette :/ ) will certainly correct me if that's not the case, but he seems to be the main participant in several memory split posts here in the community as well as on the wiki page, and as such I wouldn't want to be the one giving you incorrect information. Well, not any more than what I already do :)

I'm not sure if it would help, given that I did not work on the WSOD fix myself, but could you also try increasing VRAM and see if it also helps? Maybe trying that first, and if not, then going for the memory split.

Either way, I'm curious as to what do you do before this actually happens. If it's after some use (how long?), then maybe there's a memory leak on the whole texture mapping rearchitecture, but I would not be keen in jumping the gun on that without learning more. Would you have used the previous WSOD-fixed build for long periods of time navigating/using ES without any such issues, I imagine? Or were your ES interactions briefer than now, given the screensaver?

Thanks for testing it out.

**Scannigan**

Before the screen saver, the original WSOD fix wasn't throwing up any errors and was working very well, i've got the ES VRAM limit to 1000 and vid split to 128 if I recall

pjft

@__Scannigan__ Thx. Rendering the videos will certainly make use of GPU memory, likely more than with the previous VLC build as that was all CPU processed, so it may be that, with the current heavy theme and textures and videos, it runs out of memory at occasion. Would love to learn when it happened, though - can you share more details? Screensaver? Navigation in ES? Were you using it for long? Short time?

What Pi are you on? Your split is probably 256 at least if you're on a Pi 2 or 3. I'd certainly not oppose increasing it to 384 or 512 the way I described earlier, for testing at least.

I'm unsure about the 1000 for VRAM, as the Pi 3 would have 1024MB available memory - i.e. wondering what implications are there for that. Anyway, I'm not the right person to comment on that particular setting. Let me loop in the right person.

@fieldofcows - I'm reading your code on the TextureDataManager and TextureData, in particular where glGetError() is called, and I am unsure whether I am reading it right, so please forgive my naivety here.

On the Texture load function, it seems we're only releasing memory if the memory the loaded textures are currently taking up more memory than the value we have manually set for it, is that correct?

Is it possible that the user can "designate" more memory for VRAM than the one that the system will effectively be able to allocate to it, and we'll end up trying to load or render a texture but running out of memory? Would love your perspective.

I'm thinking that the limit for the slider is 1GB, and that's the max memory for a Pi 2 and 3. Wondering if it should also have a comparison with the actual available memory, or if the system actually handles it correctly by swapping.

Please ignore and push back if that is incorrect or a non-factor. I certainly don't want to be bothering people for no reason, but I'd love your input here.

EDIT: it might also be that the troubleshooting I'm doing is throwing us in the wrong direction. I'm just not sure OMXPlayer uses OpenGL in any way, so - even though I certainly imagine it can contribute to running out of video memory faster - the error seems to end up being on the ES rendering pipeline.

Thanks!

incunabula

@pjft Disabling overscan fixed it! I didn't proceed with the further steps but I can if it will help in some way. Right now I'm just enjoying the show on my pi :) FYI, I'm running it on a Pi 3 with VRAM limit set to 200mb using the Carbon theme.