Comments (19)
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.
from omxplayer.
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.
from omxplayer.
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...
from omxplayer.
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
from omxplayer.
What happens if you run a single dbus from the parent script and then a modified omxplayer script in a loop?
from omxplayer.
Is this still an issue with latest omxplayer and single dbus interface?
from omxplayer.
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?
from omxplayer.
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?
from omxplayer.
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
from omxplayer.
Hi, I've just fixed STDIN without dbus. See pull request above.
from omxplayer.
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.
from omxplayer.
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.
from omxplayer.
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
from omxplayer.
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!
from omxplayer.
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.
from omxplayer.
Yeah, it's not worth it for a 12ms penalty. Thanks.
from omxplayer.
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
from omxplayer.
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
from omxplayer.
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.cppmain.
Best regards
GergelyOn 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.
from omxplayer.
Related Issues (20)
- Playing audio to individual HDMI HOT 2
- Volume control while playing HOT 3
- install in other arm machine HOT 1
- Cannot play audio over bluetooth after reboot HOT 1
- Omxplayer and bluealsa
- DBus.Error.ServiceUnknown HOT 1
- Omxplayer with Argon One v2 ir remote
- Package 'libssl1.0-dev' has no installation candidate HOT 1
- when i make -j$(nproc),there have an error HOT 5
- omxplayer doesn't play live stream, playing local mp4 video works though HOT 1
- Will omxplayer stop working eventually? HOT 2
- DBUS Name Control problem HOT 1
- pi and sound HOT 1
- Any plans to adapt for Raspberry Pi 4?
- Fixes #939
- libva1 deprecated HOT 1
- omxplayer has 20s delay on raspberry pi live stream HOT 4
- OMXplayer freezes when trying to seek
- E: Package 'omxplayer' has no installation candidate HOT 1
- Compiling on Raspberry Pi 5 running Debian 12 32bits?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from omxplayer.