Scrubber, seek, progress bar needed
fkbreitl opened this issue · 27 comments
Playing media is very limited without a scrubber bar, so it would be very useful to have one.
Even if the the real time update seems more difficult to implement it would be helpful being able to jump to any position at least in steps of some percent.
I saw that the omxplayer -i option provides the duration of the media file and the --pos option allows to jump directly to a position.
So there is already a way to implement this.
Yes, maybe i have some time in the future to implement something. Feel free to do it yourself.
That would be great. I am afraid I won't have time to do this soon.
By the way I realized that the Raspicast app is very advanced, but still lacking a web interface.
Both projects could possibly benefit from each other.
I am working on adding a dbus service as well as a video player ui (seekbar , duration, pause , mute ) on the fork in my repo. I will submit a pull request once i get it finished up. The core functionality is there now . Just need to finish up a little bit of javascript event stuff and it will be done.
Awesome, thanks.
Great, thank you!
pull request submitted! the guts are there for adding more stuff if wanted
Very cool, i will check this out today on my Raspb1. Maybe i'll do some minor style updates to match the overall style of the applications.
But the image look great, thank you.
That's fantastic!
I think this screen shot should also go on the main page.
And whats the idea behind the dbus service? I am not familiar with dbus and don't know what it is used for.
Omxplayer uses dbus as an "API" service to be able to control everything whats going on inside the application. It's exactly for tools like this web gui, the developers of omxplayer created it for such tools.
Ah, I see. Thank you!
So, this feature is in. Thanks to @donaldsteele for bringing up the basics and for the pull request. I've updated several other parts behind the scene to meet current standards. Just update and you should have the UI enhancements.
After busy days I finally found the time to get back to my raspberry and updated omxwebgui to v0.12.1.
However, the new version doesn't play and gives me many errors like:
[Sat Oct 7 08:52:24 2017] 192.168.1.20:55513 [200]: /index.php/index sh: 1: /home/pi/local/omxwebgui/src/View/../../dbus.sh: Permission denied
When looking into ls src/View/ I only find:
Index.php Settings.php
So what's the problem and how can I get it working?
Have you made sure that all files and folders have the same user:group? Seems like that the new dbus.sh isn't accessable.
Yes, all belong user pi.
But it looks like dbus.sh is searched in the wrong path. Its located in /home/pi/local/omxwebgui/ not in src/View/...
Another problem is that after stopping with Ctrl-c and restarting with
php -S 0.0.0.0:4321 -t /home/pi/local/omxwebgui
I get the error
[Sat Oct 7 13:06:07 2017] Failed to listen on 0.0.0.0:4321 (reason: Address already in use)
which appears because the dbus-daemon is still running as shown by sudo netstat -plnt:
tcp 1 0 0.0.0.0:4321 0.0.0.0:* LISTEN 20850/dbus-daemon
Shouldn't it terminate?
The path is ok, the ../../ say just parent of parent. The dbus is not the problem for you restart problem, dbus uses another port.
You must kill the service via kill command if CTRL+C doesnt kill all instances. Use ps -Af to find all running instances of the php script.
Than, give the dbus.sh file the chmod 0777, maybe this fix the dbus permission denied issue for you.
I see. chmod 0777 solved the issue. But doesn't this mean another user is executing dbus.sh and if so, is this correct? In this case the permissions of dbus.sh need to be updated and otherwise something else needs to be fixed.
And what is your best suggestion for stopping and restart omxwebgui (avoiding the Failed to listen issue)?
I generally use all my omxwebgui stuff with 0777 because i have it on a shared drive.
The dbus.sh will be executed in the same way as opening the omxplayer. So, dbus.sh should be able to have the same rights as omx-start.sh or omx-pipe.sh and it should work.
It depends with what user you start the php -S 0.0.0.0:4321 -t /home/pi/local/omxwebgui, this user also start the omxwebgui scripts. So, normally, it should do it also with 0755 permissions.
Ok, but my user is pi and it starts omxwebgui with php -S 0.... So it should have worked with the 0755 permission. Seems like something unexpected is going on which needs some debugging. At least the installation instructions and the update fails for the user pi.
The other issue regards the restarting of omxwebgui when Failed to listen... occurs. I have to find (with sudo netstat -plnt) and kill the process listening to 4321 two times, which doesn't seem to be the most convenient way.
That's true. I will do a installation on my Pi with default readme instructions. Maybe there is some problem that i currently have missed.
Ok, i've tested it on my Raspberry with the user pi, using the full automated installer from the readme.
This are my file permissions, especially the dbus.sh have 0744
And it work like a charm.
I've noticed that during installation the auto installer script does not set the execute privilege for the dbus.sh properly, but setting it to 0744 manually fix this issue.
I have to update the readme for installation and the auto installer script.
Great. I also tested the new installer and now it works as expected.
My only remaining problem is an easy way to terminate the omxwebgui after the dbus-daemon has started (by playing a file).
The dbus daemon is automatically started when requested by any application. Omxwebgui can't control this daemon. But what i can do is an easier way to terminate the omxwebgui server.
I see. My problem is the failing restart of the omxwebgui with the error "... Failed to listen on 0.0.0.0:4321...". I don't know how this is generally avoided when dbus is used but a standard solution should already exist and also be used by omxwebgui.
If you want I can create a new issue for this task.
Ok, I have created the new issue #22 for this problem to not make this issue too long.
Thinking more about the fix in the installer.sh I would suggest to use the following instead:
chmod +x dbus.sh
This is a bit safer since it only touches the user's exec permission and if something else goes wrong, it doesn't change any other files (unless they are named dbus.sh). Moreover it makes it more clear what's happening.
Good suggestion, i will use chmod +x *.sh instead. It's luck that all the omx scripts have worked before, without the execution privilege. With the execution permission it will prevent any error that may come along.