Please test: Random Game selection/launch via Video Screensaver

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.

incunabula

Here are the output results for the commands you had listed above:

http://imgur.com/a/9D9rI

TMNTturtlguy

@pjft the base emulation station has been updated to allow us to run themes with video and without video in the same build, ie I can have standard carbon as well as carbon with video as theme options and a single gameslist that includes video in it. Carbon will now just show the image file and carbon video will run the video. This is a great update, anyway that your great work on the video screensaver and OMXPlayer can be incorporated into the new ES release? Here is the thread on the update to ES. https://retropie.org.uk/forum/topic/8485/how-to-stop-themes-from-seeing-video-mp4-files Thanks!

**Scannigan**

@pjft Nope wasn't using it for long, initial system view loads just fine, select a system and video previews load just fine, upon switching to another system, video preview will play fine, when selecting another game video will not populate, then if you come back out to system view system icons are white blocks and background is white, I'll ramp up the mem split and see what happens

pjft

@incunabula oh - that's underwhelming :P So much effort into trying to troubleshoot, haha. I'm glad you sorted it out on your end - I do imagine that the overscan layer will effectively add to the rendering pipeline, and now that you disabled it it can render the subtitles with little difficulty (it's yet another layer). Hope you enjoy it and have fun :)

I'd still rather have this fixed for everyone, but truth be told if we're not going to use OMX Player for the long run, it's probably fine for now. When we have FFmpeg support, then we'll fix things as they come.

@Scannigan Thanks for the detail, this is great.

Before you actually touch the memory split, just one more thought, if I may: could you actually check whether you really have the maximum set to 1000? If you do, could you try lowering it to 200, restarting ES, and then seeing if it loads the system view and a game list, and see how it goes? Then, if it doesn't work, to 250, restart ES, 300, restart ES gradually until you find a value where the theme actually effectively loads correctly and you can navigate back and forth with ease.

The train of thought is, following my previous comment on memory management, that the VRAM may need to be set as high as needed for the theme to load, but not a lot higher as it's that limit that forces the textures to be unloaded and refreshed. My assumption is that, if it is too high, you will eventually run out of memory just the same - but I am making an assumption, I can't tell for sure. This test would be very helpful as if there is indeed a problem with the memory management here it can be fixed in the main branch. The video may certainly be taking up video memory that is no longer available.

Thank you very much for looking into this! I do appreciate you taking the time here and trying to help figure this out for everyone.

@TMNTturtlguy Thank you for the encouraging words. Just to be clear, almost all of this work is actually @fieldofcows 's! He deserves all the credit. The only thing I actually did was to implement a few things on top of it - namely launching the game from the screensaver, being able to select a different random game with the controller, quickly, and the game name and system name on the screensaver video. Truly, he's the one to get all the credit for everything - I'm just putting together a proof of concept for the user experience, on top of his work, and following @Zigurana 's ideas around random game selection.

The long term goal is certainly for this to go to the base emulationstation. That being said, this is built on top of @fieldofcows 's work around video screensaver and video player implementation, so ultimately it depends on that to be integrated with the base emulationstation before my changes can be. I will not be adding to the base emulationstation other people's work, I don't feel it's correct. :)

As soon as the base emulationstation gets random video screensaver support from @fieldofcows , I'll be on top of it to implement these. Until then, there's no such chance.

He's also investigating using a different HW accelerated player (FFMpeg), so these OMXPlayer tweaks are just temporary. They're good for now, they do have known limitations - particularly in regards to not allowing overlays, which are key for themes - but if people want to use them for now, I provided this build for that purpose, and for people to test the interaction and see if it improves the experience in any way for them.

I received some valid comments around allowing the same for game images, as not everyone has videos, and that will certainly make it into the base emulationstation when this gets there. I may implement that as well on an experimental build later, as it is definitely a good idea. It just needs time, which I'm currently lacking :)

Anyway, thanks for the note, and rest assured, I do want this to make it to the base ES branch - provided that the community things it adds to the experience, otherwise I doubt it will be accepted. That's why it's critical that people test it out, use it, and validate that it is a positive addition, so that ultimately the RetroPie project owners (BuZz and herb_fargus, I believe) approve of the change.

Hope this clears it :)

TMNTturtlguy

@pjft thanks for the great info in your response. Can't wait to see what @fieldofcows and you come up with. In the mean time, is there anyway that you could incorporate the new ES updates into your code for the screen saver? I would take a stab at it myself, but i am not sure i can find any repository on the work that you and @fieldofcows have done to the base ES text files, and I am sure it is a lot of work! Thanks again.

pjft

@TMNTturtlguy Unsure. Certainly incorporating the new ES updates as a whole into this is quite similar in effort to incorporating this into the base ES :)

However, if you're just referring to allowing themes without video to not completely break if the gamelists have a video tag but the theme doesn't support it, I suspect that's more manageable. Is that what you're referring to?

Is it this particular change? @jdrassa - this seems to be fairly self contained. Any unforeseen dependencies from this particular code, or do you think it's fine for me to cherry-pick it and import it over to my test branch?

TMNTturtlguy

@pjft Yes, i am just referring to allowing themes without video to not break. Jdrassa posted an accepted fix 5 days ago in the thread you sent, however the code for that change was never published.

pjft

@TMNTturtlguy sure. If it's that, I'll send you a build later today for testing if you're willing to try it out. Would you be keen on testing my build with that change - if it's the small one I sent earlier?

Thanks.

TMNTturtlguy

@pjft you bet! let me know when you get it completed and i will test it out. Thanks

pjft

@TMNTturtlguy Here.

https://github.com/pjft/EmulationStation/releases/download/0.5themefix/emulationstation

Use the previous instructions in this post but use this link instead of the 0.4 one.

Let us know how it goes. I did NOT test it, just built it and sending it over. I'm assuming that was the right code to merge here, but it may not be the full story so hope this works.

TMNTturtlguy

@pjft Great! Thanks - I am in the middle of finishing up some final details on my current build, and then will back it up, and then install this and let you know. Unfortunately I am off to work, so I won't be able to get back to you right away. Thanks for putting this together.

pjft

Hi all,

I've updated the binary to include a few changes from the folder metadata fixes I've done for the main ES as well.

https://github.com/pjft/EmulationStation/releases/download/0.6-ssctl/emulationstation

Nothing major.

The next update on this front will be using random images for screensavers, but that should take some time - I have other things on my plate at the moment, some of them ES related, that are more pressing or interesting, hopefully. :)

I'll keep everyone up to date.

Have a great Sunday!