Any way to run omxplayer without dbus?

[sugatam]

Can we add a commandline switch to fall back to old behavior?

[shuckle50]

I vote for this, too.
I have removed dbus anyway from my system as I try to run minimal setup, so adding it now for omxplayer sounds strange. My setup is a monitoring screen with no human interaction.

[sugatam]

I started looking into this - I'm a bit ticked off that dbus wasn't introduced with a conditional compile. Now it is all messed up - I was exploring replacing m_omxcontrol.getEvent with the direct getchar() call, but the rewrite with threaded keyboard handling and some of the actual logic (like volume adjustments) in OMXControl are making it hard. I wish the whole things was done with a USE_DBUS ifdef.

[andyjagoe]

You can change the omxplayer startup script in /usr/bin/omxplayer to comment the DBUS calls to address this. It's what we've done to eliminate dbus-daemon not being properly shut down after playing some videos...

#59 (comment)

[sugatam]

Back when I tried this, I could not control omxplayer via the keyboard/STDIN if dbus wasn't running. Looking at the code, the reading from STDIN has been scrapped completely (or had been last I looked), and my request was to bring that back, at least via an #ifdef if not a runtime switch. It was simple and it worked

[cleverca22]

What happens if you run a single dbus from the parent script and then a modified omxplayer script in a loop?

[popcornmix]

Is this still an issue with latest omxplayer and single dbus interface?

[SleepyBrett]

I've come back to some players that are playing video after video and find a state where there are three processes in ps ( omxplayer script, omxplayer bin and dbus-deamon ), but no video is playing, it's effectively hung until I kill the omxplayer script.

It's causing me a lot of heartache currently. Not being very familiar with dbus-deamon is this something that is caused by dbus deamon?

[KenT2]

Sounds more like the problem with omxplayer crashing at times as in issues #124 and #12 . Are you using a version of omxplayer which includes @jehutting fixes?

[SleepyBrett]

I was seeing these issues on a release build from february (0.3.4?) I've since upgraded two players to omxplayer_0.3.5git20140318d37454c_armhf.deb and on one of the PIs I've seen one hang overnight, then after going in and killing the omxplayer.bin process another hang within two hours. The second one hasn't had an issue.

It sounds a lot like #124 and #12

[subogero]

Hi, I've just fixed STDIN without dbus. See pull request above.

[subogero]

The issue was, that even the STDIN commands were forwarded to DBUS, and so all interactive control could be implemented via DBUS in OMXControl.cpp. Except, if DBUS didn't work. I've added a shortcut, Keyboard.cpp::getEvent() now has an identical interface like OMXControl, and the former is used if OMXControl::init() fails to connect to DBUS.

[sugatam]

Thanks a lot! This is exactly the fix I was looking for. I might make a change to add a new commandline arg to even bypass the attempt to connect to dbus.

[subogero]

We should get this into the official master ASAP. I'm still using an old huceke omxplayer on my production home server/media centre for this very reason.

Do you think skipping DBUS altogether could speed up omxplayer startup? If so, I very much agree with your proposed option. It could shorten gaps between tracks when using omxd. Shall I prepare the new option? I'm in the flow, you know. Toolchain up and running

[sugatam]

I have no intention of running dbus period, so skipping the connection attempt based on a commandline arg makes sense for me. It'd be wonderful if you add support for that. Like you, I'm pinned to a checkout - I believe the revision just before the dbus changes came in, because of this. I still feel the wholesale change to dbus shouldn't have been blessed without at least a conditional compile leaving it out, but thanks to your work that is a moot point.

I agree that it would make a lot of lives easier if this went into master asap. Thanks again for your work!

[subogero]

I've made some measurements. The failed DBUS connection attempt takes exactly 12 ms. In other words about 1/100th of a second. I think a new command line options is not worth the effort, especially now that the lack of DBUS is detected automatically. What do you think?

Anyway, I'll write to popcornmix to ask him to merge the changes.

[sugatam]

Yeah, it's not worth it for a 12ms penalty. Thanks.

[krattai]

wait... what... ? So I'm running a version that incessantly makes dbus
calls which aren't closing cleanly, so I'm having to loop a memory clean
in cron.

What I'm hearing is, if I uninstalled dbus, this would not happen and
omxplayer would still play properly?

On the "fix" note, are we talking about omxplayer doing a check for dbus
and using it or not using it, depending if it is installed? Or are we
talking about omxplayer simply no longer using dbus?

hope someone can clarify.

Cheers,

Kevin

On Wed, 2014-07-23 at 09:30 -0700, sugatam wrote:

I have no intention of running dbus period, so skipping the connection
attempt based on a commandline arg makes sense for me. It'd be
wonderful if you add support for that. Like you, I'm pinned to a
checkout - I believe the revision just before the dbus changes came
in, because of this. I still feel the wholesale change to dbus
shouldn't have been blessed without at least a conditional compile
leaving it out, but thanks to your work that is a moot point.

I agree that it would make a lot of lives easier if this went into
master asap. Thanks again for your work!

—
Reply to this email directly or view it on GitHub.

http://ca.linkedin.com/in/kevinrattai/

https://plus.google.com/+KevinRattai/

https://community.spiceworks.com/people/kevinrattai

[subogero]

Hi Kevin,

Just to clarify. DBUS remains. We try not to break anything.
So we attempt to connect to DBUS as before.
If the connection fails, the keyboard control no longer reaches
the main loop via DBUS, but using a new direct route.
If DBUS is fine, it's as before: Keyboard.cpp > DBUS > OMXControl.cpp > main.

Best regards
Gergely

On Wed, Jul 23, 2014 at 04:22:40PM -0700, Kevin Rattai wrote:

wait... what... ? So I'm running a version that incessantly makes dbus
calls which aren't closing cleanly, so I'm having to loop a memory clean
in cron.

What I'm hearing is, if I uninstalled dbus, this would not happen and
omxplayer would still play properly?

On the "fix" note, are we talking about omxplayer doing a check for dbus
and using it or not using it, depending if it is installed? Or are we
talking about omxplayer simply no longer using dbus?

hope someone can clarify.

Cheers,

Kevin

[krattai]

OK, thanks Gergely.

I'll have to try to go through the other omxplayer issues to see if
there's another resolution for dbus-daemon -fork failures to shut down.

Cheers,

Kevin

On Wed, 2014-07-23 at 21:46 -0700, SZABÓ Gergely wrote:

Hi Kevin,

Just to clarify. DBUS remains. We try not to break anything.
So we attempt to connect to DBUS as before.
If the connection fails, the keyboard control no longer reaches
the main loop via DBUS, but using a new direct route.
If DBUS is fine, it's as before: Keyboard.cpp > DBUS > OMXControl.cpp

main.

Best regards
Gergely

On Wed, Jul 23, 2014 at 04:22:40PM -0700, Kevin Rattai wrote:

wait... what... ? So I'm running a version that incessantly makes
dbus
calls which aren't closing cleanly, so I'm having to loop a memory
clean
in cron.

What I'm hearing is, if I uninstalled dbus, this would not happen
and
omxplayer would still play properly?

On the "fix" note, are we talking about omxplayer doing a check for
dbus
and using it or not using it, depending if it is installed? Or are
we
talking about omxplayer simply no longer using dbus?

hope someone can clarify.

Cheers,

Kevin

—
Reply to this email directly or view it on GitHub.