Bug (solved): OMXPlayer on Stretch-based builds stutters on composite
-
@matchaman I don't have composite, so I can't comment much, but I'd expect that it's either Stretch related or config.txt related.
-
I tried today with a brand new Raspbian (stretch) image. Videos do not stutter at all on omxplayer (outside PIXEL desktop). Same settings, brand new RetroPie 4.3.17 test image, same stuttering problem.
Both cases on Pi 3 and 3 B+, zero difference... while stable RP 4.3 shows no problems at all.
What's going on? :(
-
@matchaman so, plain Raspbian works well, RetroPie image stutters, is that it? Interesting.
Things to consider:
Compare config.txt
Check omxplayer dependencies and compare versions across both (dependencies and omxplayer)I'm assuming it's the same hardware you're running it on.
-
I kept checking that settings were the same and then I used the exact config.txt out of paranoia :p no change...
I tried checking dependencies with ldd /usr/bin/omxplayer but I get "not a dynamic executable" on both setups. As for version, both are the same (latest from July 2017).
And yes, it's both a model 3B and a 3B+ and always these two particular units. Before getting back a 3B model I thought it had to do with the hardware which is not the case...
-
@matchaman said in Bug: OMXPlayer on 3B+ stutters on composite:
I tried checking dependencies with ldd /usr/bin/omxplayer but I get "not a dynamic executable" on both setups. As for version, both are the same (latest from July 2017).
omxplayeris actually a shell script wrapper around theomxplayer.bin, so that's why you get this message.
Can you check if you have the same kernel on both systems ?uname -ashould show it from a command line. -
It seems highly likely that the new 4.14 kernel is the explanation. Jools' testing builds include the new kernel (which is upgraded via a standard apt-get upgrade), but I'm guessing that the stretch or stretch lite image/installation is still using the 4.9 kernel.
I suggest checking the kernel revision on both builds:
uname -aEdit: @mitu beat me to it ;)
-
On the Raspbian setup I get:
Linux raspberrypi 4.14.30-v7+ #1102 SMP Mon Mar 26 16:45:49 BST 2018 armv71 GNU/Linux
On RetroPie I get:
Linux retropie 4.14.30-v7+ #1102 SMP Mon Mar 26 16:45:49 BST 2018 armv71 GNU/Linux
As for the dependences with omxplayer.bin I'll have to compare by taking photos of the screen, which I'll do shortly.
Meanwhile, could anyone please check with composite? I can't be the only user that uses composite for 240p on a CRT...
-
Unfortunately I don't have a cable to check.
See these lines: https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/supplementary/emulationstation.sh#L282-L289
Can you try to comment those lines (that are added via the iniSet function) from your /boot/config.txt and reboot?
-
Big discovery!
I exited EmulationStation with F4 the moment I booted into it (without entering a system). When I tried omxplayer, the video plays smoothly! Then I entered ES again, browsed for a moment, went back and stuttering came back as usual.
Here's a video I just recorded:
Something runs along with omxplayer and makes it run slow. What's completely crazy about this is that when I use HDMI, everything runs perfectly:
@psyke83 just edited these out, I'm getting the good old white screens of death :P
-
@matchaman I wonder whether the GPU split changes things for you, and/or whether installing ES on the fresh image manages to replicate the issue.
-
Please check behaviour without the lines in config.txt, as I asked, but also, I notice that the issue starts occurring after video playback starts inside ES itself when you returned to ES. If you disable omx support in the ES menu, does it clear the bug when launching omxplayer via the shell the second time?
-
@pjft this is a brand new image I installed yesterday again, the only thing changed is that I uploaded my media overnight and my theme (which is basically carbon video).
@psyke83 I disabled the gpu_mem lines, altogether and one by one. Nothing changed except for 1024=256 causing a "white screen of death" (occurred on both units).
I disabled omxplayer for ES (both themes videos and screensaver), rebooted, looked around systems (videos run fine but browsing feels a bit slow which I believe is normal without omxplayer), exited ES, video runs great again on omxplayer.
Something makes omxplayer stutter once it runs inside ES and only when the output is via composite (any sdtv setting). Via HDMI on any resolution, this issue does not happen at all. But what could it be? It definitely didn't happen on 4.3 stable with all updates last month :/
-
Update:
I had the audio almost off and didn't notice something very serious once omxplayer runs inside ES: not only omxplayer remains stuttery outside ES but the whole system slows down like it's heavily underclocked! This is getting weirder...
Sorry for the length of the video but I explain it here in practice:
-
@matchaman I can't watch any of the videos for the moment, but that's good then. Can you SSH into it and run"top", and see what exactly takes up the CPU when you play a video?
-
Here's a capture of top before omxplayers runs inside ES:
And another afterwards, with what appears to be system-wide slowdown:
-
@matchaman Why is there a
pythonprocess keeping the CPU busy ? Do you have a BGM script running ? Are there any errors reported bydmesgafter the slowdown ? -
@mitu @matchaman well spotted, was going to ask the same (didn't know about the bgm music script using python though).
The system does not appear to be in significant load though.
Can you install htop and run htop instead of top to assert the process trees?
-
@mitu It's the background music player. I disabled this previously, it was the first thing I suspected that could interfere with omxplayer. Disabling it didn't change anything so I enabled it again. No errors on dmesg either.
@pjft I installed PuTTY to make matters easier. Here's what I got with htop
Before omxplayer in ES:
After:
-
I came back from a friend who bought a 3 B+ model. He uses a brand new 4.3.17 test image, nothing added other than ROMs for systems. I asked him to scrape with videos for a system, switched to omxplayer in ES, used a jack to RCA cable and here we go... same problem!
I consider this a global issue :( someone who can use composite, PLEASE give me your input...
-
Excuse me for "spam-bumping" this but it's a real issue that needs to be addressed.
I installed a clean image of 4.3 Jessie (on my 3 B model obviously) without any updates and the problem does not exist, as I expected.
I am now updating components one by one to see what causes this and if it's exclusive to Stretch-based RP (in case everything is updated and the issue does not appear).
Edit 1: I'm starting with the RetroPie Setup script. The bug does not appear yet. (WOW it shows 4.4 :D) let's keep updating...
Edit 2: RetroArch. Obviously no change, as expected.
Edit 3: runcommand... no change. RP conf menu... no change.
Edit 4: Updating EmulationStation... holding my breath... NO CHANGE! :O
Edit 5: Doing a general update, including kernel and other OS packages... nope. Nothing. Everything works perfectly. What a headache :/
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.