Video Splash Screen problems

edmaul69

@gopherguts420 try making an"sd" version of the video and see if that helps you. I had to do that when i ripped the hd playstation boot screen. Sd doesnt mean composite quality either. Still looks really good just a smaller file size.

gopherguts420

@edmaul69 I'll try that out but kinda out of my area of expertise lol. Thing is I've seen some of these splashes on other setups with no issues. Kinda puzzles me tbh

Oh and I should add that if I reboot within ES majority of the time it will play fine. Issue really only lies within cold startups

MWGemini

@gopherguts420 There is another (unrelated, as far as I know) feature that was recently added by @fieldofcows allowing for video previews of games. I've been helping to test it, but have noticed that two different video players (VLC and omxplayer) have different quirks as far as how they play videos. I have no idea which one is being used for the startup videos, but just wanted to mention this, since it may mean something to the folks here who are more knowledgeable than I am.

gopherguts420

@MWGemini I haven't messed with it anymore today but I did get around to setting Kodi up today, set it to boot first instead of ES and sure enough it plays fine every single time. Went back to ES first and the issue returned so I think I can narrow it down to an issue with ES? I mean it's gotta be something within the ES boot sequence that is conflicting I'd think

herb_fargus

@gopherguts420 probably the framebuffer depth. Omxplayer has a flag to define the depth (currently 10000 on the splash screen module) if you modify that number or remove it entirely it may resolve it.

gopherguts420

@herb_fargus I tried removing that bit of code yesterday, it actually made it worse. The ES splash would show up before the video was even done playing. I didn't try to adjust the value though. What would be a good direction to go in adjusting it?

herb_fargus

@gopherguts420 I really couldn't say. There are also some modifications with the latest video support with ES that may have affected depth as well so best bet would be to try different depth values and/or try re-encoding the video to dif codecs - mp4 h264 etc

gopherguts420

@herb_fargus I'll try those out. Thanks

petechik

Disabling overscan seems to correct the problem.
sudo nano /boot/config.txt
disable_overscan=1

Note* I was having the same problem, but only on certain TV's. Also booting into kodi would solve the issue. So I am assuming it has something to do with emulationstation loading and the signal it is sending out to the tv. Since disabling overscan fixes the issue, it must have something to do with how TV's utilize overscan. I am a noob when it comes to programming and technical stuff, so I don't know the technical cause of the issue, but maybe this info might help someone more familiar with Pi.

MonkeyKng

@petechik That worked perfectly to fix the HDMI cut out issues on the splashscreen video. However now the image spills over the TV size. If I enable the overscan limits (e.g. overscan_left, etc.) the issue returns. Is there a way to boot up with disable_overscan then after the video splashscreen ends and emulation station boots enable the overscan limits?

gopherguts420

So initially what solved my problem was disabling Plymouth by adding plymouth.enable=0 to the first line in boot/cmdline.txt but yesterday was setting up Kodi and the overscan borders were bugging me bad so I manually adjusted them until I was satisfied. I just removed what I added to cmdline.txt and the splash is still working perfectly fine.

petechik

Disabling Plymouth didn't fix the splash screen for me. I've tried all the solutions that I could find on the forums but nothing worked except disabling overscan. But that comes at the cost of not having overscan. I like Monkeykng's idea of disabling overscan until the splash screen is done. But I don't know how to go about doing that.

thekobk

could be the speed of the sd card. I have 2 pi's and the one in the main room has a pi drive, the pi drive can not keep up and has similar issues. using the same file on the other pi's i have no issues.

rommager

Hi, I have the same issue. I have an interesting observation to add - I have used all the video splash screens successfully on a PC monitor with an HDMI to DVI-D cable, and I don't get any video or audio dropout (using composite audio, since it's a monitor). But when I connect to my Samsung TV (not a Smart TV), I get drop out particularly on longer videos. On my buddy's Sharp Aquos TV, the video drops out and the audio "fuzzes" out about half way through. I also want to say when I preview the videos in the splash screen setup, they all play fine on the TV.

So, it appears the following are the case:

The problem varies from TV to TV
The problem does not appear to be related to the HDMI cable (preview plays without issue)
It's not the SD card (preview plays without issue)
Longer videos appear to be flakier than shorter videos
Does not appear to be power related

Setup: Using a Pi 3 (CanaKit), and RetroPie 4.2.

IRgEEK

@rommager @gopherguts420

Hey guys, didn't know if you solved your issues so thought I'd share this.

In my case, my startup videos would break all up the last few seconds, and sometimes the display would just go black.

The way I solved it was to edit /opt/retropie/configs/all/autostart.sh script so that emulationstation wouldn't launch until the video player finished playing the startup video.

Not perfect, but now all startup vids play fine without me having to disable overscan etc.

*** Added wait below to autostart.sh before emulationstation line ***
while pgrep omxplayer & > /dev/null;
do sleep 1;
done

emulationstation #auto

Hopefully helps somebody. thx!

IRgEEK

@thekobk I thought was my SD card as well at first, but even with the fastest SD I could find, I was having same issues on longer startup videos. It seems my pi just couldn't handle playing videos and launching emulationstation at same time so I added a delay. See my other reply. Maybe not perfect but works :-)

rommager

@IRgEEK

Yeah, it actually makes sense, somewhat. I am guessing the pi gets pretty busy doing IO when loading emulationstation, and struggles to keep up with everything needed to keep a stable HDMI signal while booting? Maybe? But still, when I am connected to my monitor with a HDMI to DVI cable and analog audio, I get no issues at all...

I can see how this tweak will work, but the main beef I have is that the video splash is intended to give you something to watch while ES loads. Still, it is still a perfectly viable option because ES only takes a few seconds to load.

Still, two other possibilities come to mind. I wonder if they will work better?

Start omxplayer with a higher priority or niceness?
Start omxplayer on a different CPU core when available for the Pi2/3? This may not be an option for the pi zeroes, as I don't think the zeroes have multi core CPUs.

Either one of these might do the trick, but I also am not a Linux expert, so I don't know if these are viable options or not.

rommager

I tried the niceness idea by modifying the script /etc/init.d/asplashscreen

I tried adding the following into the omxplayer line in the asplashscreen script:
sudo nice --1 omxplayer...
sudo nice --10 omxplayer...
sudo nice --20 omxplayer ...
sudo ionice -c 2 omxplayer ...
sudo ionice -c 1 omxplayer ...

None of these modifications seemed to correct the issue. As stated by other users, I did try disabling overscan, and the videos do play though without completely dropping out, but there is a point in all videos where the sound drops for about half a second during boot. It's an improvement, but now the video goes off the edge of the TV screen.

Curiously, when I re-enabled overscan, the video splash screens continued to play the same way. Maybe I just need to cold boot the pi to make the problem resurface.

At any rate, I now know playing with the niceness doesn't seem to fix things. I do now have another theory on the issue. I have noticed that EmulationStation still starts in the background, and accepts input while the splash is playing. I am wondering if EmulationStation starting is corrupting the HDMI playback of the video. My thought is that EmulationStation initializes video modes and brings up its graphical screen when it launches, and those changes in video modes might be what is corrupting the HDMI signal while the video is playing. That behavior would explain why delaying the EmulationStation launch until after omxplayer terminates corrects the issue. That would also seem to explain why setting niceness doesn't fix the issue.

It may be that the best fix may be IRgEEK's fix to delay EmulationStation until after the video.

At this point, I think it does not seem to be an SD card, CPU, or an IO issue. I am suspecting it has more to do with EmulationStation changing the video mode in the background while the video is playing. I am not sure why it seems to work flawlessly on a monitor versus a TV though.

yodajjh

I added the fokowing to autostart.ch, and I can't get emulationstation to auto load. I get a "line 6: syntax error: unexpected end of file". I edited the file with notepad. The contents of the file are as follows:

while pgrep omxplayer &>/dev/null;
do sleep 1;
done

emulationstation #auto

Those fixed my video issue w/ the splash screen, but I've been unable to get emulation station to auto load. Would any of you have any suggestions to fix?

Thanks!

yodajjh

I added the following to autostart.ch, and I can't get emulationstation to auto load. I get a "line 6: syntax error: unexpected end of file". I edited the file with notepad. The contents of the file are as follows:

while pgrep omxplayer &>/dev/null;
do sleep 1;
done

emulationstation #auto

Those fixed my video issue w/ the splash screen, but I've been unable to get emulation station to auto load. Would any of you have any suggestions to fix?

Thanks!