Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Any way to run omxplayer without dbus? #62

Closed
sugatam opened this issue Sep 23, 2013 · 19 comments · Fixed by #219
Closed

Any way to run omxplayer without dbus? #62

sugatam opened this issue Sep 23, 2013 · 19 comments · Fixed by #219

Comments

@sugatam
Copy link

sugatam commented Sep 23, 2013

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

@shuckle50
Copy link

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
Copy link
Author

sugatam commented Oct 20, 2013

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
Copy link

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
Copy link
Author

sugatam commented Jan 11, 2014

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
Copy link

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

@popcornmix
Copy link
Owner

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

@SleepyBrett
Copy link

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
Copy link

KenT2 commented Mar 19, 2014

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
Copy link

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 added a commit to subogero/omxplayer that referenced this issue Jul 20, 2014
Keyboard:
Keyboard reading fully functional even in absence of dbus.
Store last keystroke in member m_action.
New method getEvent() returns and clears it.

OMXControl:
init returns error code -1 if dbus connection fails.

omxplayer:
If OMXControl failed to connect to dbus, read keystrokes directly
from Keyboard::getEvent().

Fixes popcornmix#62
Fixes popcornmix#131
@subogero
Copy link

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

@subogero
Copy link

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
Copy link
Author

sugatam commented Jul 21, 2014

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
Copy link

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
Copy link
Author

sugatam commented Jul 23, 2014

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
Copy link

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
Copy link
Author

sugatam commented Jul 23, 2014

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

@krattai
Copy link

krattai commented Jul 23, 2014

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
Copy link

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
Copy link

krattai commented Jul 24, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants