Help testing: Random Video Screensaver on Main Branch

pjft

@meleu Darn. 1920x1080 is also the resolution I had tested it on the Pi. No luck, then.

Replying to the notes:

No, it won't have any difference on the video itself, but it should render the text much sharper. The difference is:
- One option will render the video in VLC at its resolution (let's say, 320x240) and add captions at 320x240 resolution. The upscaling will then be done on ES, via the texture. The video will be rendered full screen, but the captions will show as upscaled blocky text - as you currently have it. This is less CPU intensive.
- The other option would force VLC to render the video at the full screen resolution (let's say, 1920x1080), and render the captions at that resolution. The video wouldn't have any perceived difference to the user, but the captions would look sharper as they had been rendered at a much higher resolution. This is more CPU intensive, though.
- An easy way to see what I'm referring to is to run the screensaver on the Pi, with the game info on. You'll see what I'm going for.
I like the text change - will use that instead.
As for the game info, I get where you're coming from. However, just for perspective, the videos will cycle every 30 seconds. As I mentioned, the game name shows during the first 8 seconds, and the last 4 seconds - so, 12 seconds out of the 30 seconds. In the worst case scenario, someone who takes a peek at the video and likes what they see, will have to wait 18 seconds to see the actual game name, though on average the time one would need to wait to see the game name will be 9 seconds. In 1/3 of those occasions they'll look at the video and the name will be showing, though. :) So it doesn't feel like a tremendous amount of time to wait. I added the captions precisely because of that use case, but having them permanently on the screen ended up being somewhat ugly, especially for games with longer titles. I am not keen on making that the default, and I'd hesitate to add an option to make it on all the time just because it's "yet another option" (though it's a possibility), so I'd probably suggest trying it out for a while and if after a few weeks that still bothers you a lot we can definitely change it at that time. Though, thinking about it, I can instead make if a selection of "Never/Normal/Always" instead of ON and OFF if it's something that critical. Let me know.
On the screensaver and making "stretch video" as the default, I do have to say I hesitate about that. I'm open to suggestions on that default. The main reasons that that is not the case is that, in particular for vertical games, it looks atrocious, and it does not match the actual game when the user chooses to launch it. I'm not that fixed on this particular default - as long as the option is there - so do let me know what your thoughts are and that's a simple change.

@Hex : I'll add that then. Thanks. As for the edge case, it will likely be a very rare occasion - that, truth be told, will be changed as soon as the user changes video - so if fixing that requires a lot of work, I'd not insist on it.

Thanks all!

meleu

@pjft one more suggestion: on system view, the "button help" below says for select "RANDOM VIDEO SCREENSAVER". My suggestion: "LAUNCH SCREENSAVER".

pjft

@meleu Sounds good.

Any further thoughts on the stretch defaults and subtitles, just so this is closed off?

pjft

So, I've added the option to show the game info "Always", "Never" and "Start & End". The default is still "Never", as it can cause problems for some Pi resolutions, unless the user disables overscan in config.txt.

I've left stretch as false by default. It will still cover the full screen, just with black bars, but keep the game's original proportions.

I edited the option and help text as well, and added the ALSA condition.

I need to confirm that this compiles and that all is good (blind coding, yay), but if all is good then that's the last of it.

Thanks all for the inputs and testing! I'll update when I've confirmed it compiles.

meleu

@pjft

Any further thoughts on the stretch defaults and subtitles, just so this is closed off?

The vertical screen games example (e.g. DonPachi) convinced me, I'll let it disabled (maybe it should be always disabled and the option removed?).

Regarding subtitles the options you provided are good. I'll choose the "ALWAYS" option.

pjft

@meleu Great.

Yeah, I usually leave it NOT stretched, but some people - maybe with 4:3 monitors and such - asked for the stretch option, and I can see how it does look good if you do have the right resolution. It's just the other ones that are an eyesore, but it's down to each person's preference :)

I'll update the PR later today, and then if a final round of testing can take place, that'd be perfect, though hopefully things should be good.

Also, have you tried it on your Pi 1/0? OMX Player should make these pretty smooth, though I imagine you don't want to go through compiling these test builds for 4 hours or so before they're final. :)

Hex

@pjft I would like to reconfirm that you are testing that the device starts with ALSA all caps and not equals.

Hex

@pjft what happens to the subtitles if overscan is enabled? Are they not visible or just no video?

pjft

@Hex correct, starts with, but I believe the option in the code is lower case? I'll re-check what's being used but I thought I saw it as lower case.

pjft

@Hex it'll depend. In some cases it works perfect - my old TV is one such case. That being said, the fact that it requires an extra layer from OMX Player may cause the HDMI signal to drop - I believe you experienced it earlier?

Removing the subtitles or disabling overscan (which is, for the GPU pipeline's purpose, just an additional forced black layer to allow for a forced margin) will allow the subtitles to not cause the HDMI signal to drop.

It's only for OMX Player though.

Hex

I didnt know OMX had subtitles.

pjft

@Hex same as with VLC, if you choose to display the game info.

Actually, did you manage to get the screensaver working on your pi? Your signal was dropping if I recall correctly?

I'd like to know if you're still experiencing that. I'd hate for that to be the case, but I could consider allowing VLC to be used for the screensaver on the Pi, if there are cases where OMX Player just load signal and there's no workaround, though that's really a recipe for overheating...

pjft

It compiles. Updated the PR.

Refactored the options - merged some, moved audio-related ones to the Sound menu, and added an explicit option on the Pi to use VLC as screensaver should people choose to (default: OFF).

TMNTturtlguy

@pjft I updated your build and I am not sure that I am getting the most up to date version? I made sure to do a clean install. I am not seeing any of the revised menu options on the pi 3? I believe above you mentioned a VLC option for the PI, as well as moving audio options under sound, and 3 different subtitle options. I am currently running on Pi3 4:3 monitor. Thanks

pjft

@TMNTturtlguy hm. It should but I'll check as I'm putting the boys to bed at the moment. What version does it claim to be? It should be 2.2.1 I think. If not, maybe it's the wrong branch, or maybe I messed something up - certainly possible.

TMNTturtlguy

@pjft It's 2.2.0RP - I am using the same branch that the PR was created with:
RetroPie-ScreenSaver-Merge

I have it saved in @meleu script. The first time i ran it, I had it ignore make clean to speed it up, I didn't see the updates, so I reran it and installed it clean, same results.

Thanks

pjft

@TMNTturtlguy sounds good, I'll check. I must have messed something up then.

pjft

@TMNTturtlguy hm.

The code seems to be there though:

https://github.com/pjft/EmulationStation/blob/RetroPie-ScreenSaver-Merge/es-app/src/EmulationStation.h

It's 2.2.1 that you should be seeing.

Could you open that file locally on the Pi and check whether the content is the same?

TMNTturtlguy

@pjft dumb question - but i am not sure where to find that! Your branch is currently in /opt/retropie/supplementary/es_pjft_retropie-screensaver-merge/ on the pi. I don't have a file named EmulationStation.h there.

pjft

Not a dumb question at all. I suppose @meleu would know where the code is compiled to. That's where you'd want to look into.

I've just done a final push to the PR, updating a few things that had gone missing. All seems to be good to go on my end, but more testing is always encouraged and appreciated.

@Hex : the Alsa test works fine, and actually when you change it and exit the options menu the video player is restarted immediately with the new audio option, so no worries about that. Do test it, but it seems to work well.

I do get an error on my end - I believe when set to alsa:hw:1,0 for "ALSA lib pcm_hw.c:1667:(_snd_pcm_hw_open) Invalid value for card".

Unsure if it's because it's not a valid option or if it's because I don't have an external card, but thought you'd like to know.

@TMNTturtlguy one thing you may want to do is to just do it old school style.

https://retropie.org.uk/forum/post/82820

I didn't test those instructions but they should work.