API suggestions

[thisispete]

would be really great to be able to jump to a specific time, and a specific percent instead of just ff / rw. controls.

In addition (since they will be needed for those calculations) would be nice to expose the total length and current playback position in the get status, or some other method for creating a playback timeline progress bar UI

found some related dbus control commands in another project: https://github.com/popcornmix/omxplayer/blob/master/dbuscontrol.sh

 duration=`dbus-send --print-reply=literal --session --reply-timeout=500 --dest=org.mpris.MediaPlayer2.omxplayer /org/mpris/MediaPlayer2 org.freedesktop.DBus.Properties.Get string:"org.mpris.MediaPlayer2.Player" string:"Duration"`
[ $? -ne 0 ] && exit 1
duration="$(awk '{print $2}' <<< "$duration")"

position=`dbus-send --print-reply=literal --session --reply-timeout=500 --dest=org.mpris.MediaPlayer2.omxplayer /org/mpris/MediaPlayer2 org.freedesktop.DBus.Properties.Get string:"org.mpris.MediaPlayer2.Player" string:"Position"`
[ $? -ne 0 ] && exit 1
position="$(awk '{print $2}' <<< "$position")"

 seek)
dbus-send --print-reply=literal --session --dest=org.mpris.MediaPlayer2.omxplayer /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.Seek int64:$2 >/dev/null;;

 setposition)
dbus-send --print-reply=literal --session --dest=org.mpris.MediaPlayer2.omxplayer /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.SetPosition objpath:/not/used int64:$2 >/dev/null;;

[vabatta]

Actually I was starting developing a dbus controlled wrapper but I stopped develop it. You can see that the structure is already up for that in the development branch. Watching the source after that time, I think that moving back to vanilla JS would be better than all of those crappy compilers-pre-post work. Could think about the develop of it.

[vabatta]

@thisispete I will publish 0.2.0 which brings some performance improvements, better consistency and a backed DBUS controller for actions. Actually I'm doing some tests and implementing the last features. At the moment I don't know if force the user to have / use DBUS to control the instance or let him choose between keyboard / keyboard + DBUS. The problem is method consistency.

[thisispete]

cool! excited to check it out. Maybe give the choice in a config file, or is there a way to write it as a plugin type architecture? ie I'm writing an app that won't have keyboard control, I only need the methods exposed, and want all the options dbus has available.. maybe there's a way to separate them out? I haven't dug too far into your code to see how that might work, just throwing out ideas :)

[stulees]

@vabatta Curious on when you might be publishing 0.2.0 with the backed DBUS controller?

[vabatta]

@stulees After a lot of debugging, at the time, I found a problem which still stay unsolved and prevented me to publish the new version with the DBUS controller.

[MortenHe]

@vabatta Curious on when you might be publishing 0.2.0 with the backed DBUS controller?

[vabatta]

@vabatta Curious on when you might be publishing 0.2.0 with the backed DBUS controller?

This project is dead. I am not maintaining this repo anymore as I don't have the time. I still have the unpushed and incomplete code of the DBUS controller draft, which had (and still has) an unsolved problem about the underlaying piping of commands from NodeJS to the OmxPlayer through the DBUS line.