Bug #682

kiosk and autokiosk mode shouldn't restart xterm between instances of omxplayer

Added by Hammel about 2 years ago. Updated 12 months ago.

Status:ClosedStart date:28 Nov 2018
Priority:ImmediateDue date:
Assignee:Hammel% Done:


Category:Image display
Target version:PiBox - 1.1.0 - Upgrades
Severity:02 - High


Currently the code exits the terminal when omxplayer completes playing a video so that the next video can be started in a new process (the terminal window). But that causes some displays, like the projector used for playing holiday videos on the window, to show their input device screen in autokiosk mode.

To fix this, and get a cleaner playback of multiple videos (especially because omxplayer doesn't yet support a playlist), VideoFE needs to keep omxplayer running through its playlist and use DBus commands to tell omxplayer what to play and when to start and exit.

Bounties for this kind of functionality
  1. https://www.bountysource.com/issues/65536954-feature-request-when-the-video-ends-pause-on-the-last-frame
  2. https://www.bountysource.com/issues/26831647-original-playlist

Associated revisions

Revision c9149995
Added by Hammel about 1 year ago

RM #682: Add status and openuri commands to dbuscontrol.sh to allow kiosks to manage playlists without restarting omxplayer.

Revision 26c084c4
Added by Hammel 12 months ago

RM #682: Fix kiosk modes so they keep omxplayer running and get a smooth switch between playlist items. Also fix FF to not kill the player if it tries to go past the end of the video in kiosk mode.


#1 Updated by Hammel about 1 year ago

  • Description updated (diff)

This can be handled by using the DBus interface using OpenUri. It will require launching the player and knowing when it's done playing the current video. This requires additional DBus interfaces that run while VideoFE runs - ie it queries and manages omxplayer on a continues basis.

  • Get video length: Duration
    • This has to be run immediately after OpenUri
  • Get current position: Position
    • This is queried continuously until position matches Duration
  • Call OpenURI with the next video
  • Repeat

The Duration and Position can also be handled with a single call: Status

The trick will be to pause the video right at the end, like on the last frame. Alternatively, the player can just finish the video and sit waiting for another command (like Exit). This may require modifying omxplayer itself to support a "Don't Exit" option.

Note that VideoFE has it's own dbuscontrol.sh script right now. It would need to be updated to support any additional commands.

#2 Updated by Hammel about 1 year ago

  • Priority changed from Normal to Immediate
  • Target version changed from 2.0 - Harkonnen to 1.1.0 - Upgrades
  • Severity changed from 03 - Medium to 02 - High

Moving this up to the 1.1 release because I think I could fix this fairly easily. I will want to create a patch to a specific GIT hash, however, so I won't be pulling from master again (unless/until I can push any changes upstream).

#3 Updated by Hammel about 1 year ago

  • Description updated (diff)

#4 Updated by Hammel about 1 year ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

Okay, it's not so obvious how to fix this in omxplayer. I don't quite see how the inbound dbus message resets the player to start on a new file. I can see how the file is set in main() but not how it gets reset via dbus.

So the first thing to try will be to start omxplayer running via videofe (in the media server) and try to change the video manually (via an updated dbuscontrol.sh) and see what happens. Also, use the modified dbuscontrol.sh pause the playing video and get the status information to see how we can tell we're at the end.

#5 Updated by Hammel about 1 year ago

  • % Done changed from 10 to 20

I experimented with the dbus interface. It works quite nicely so no need to modify omxplayer to run a playlist.

I've added "status" and "openuri" cases to dbuscontrol.sh in the videofe tree. This script is only installed in kiosks and auto-kiosks because normally videofe is used to choose the next video. I tested both status and openuri and they work fine.

The status return data is in microseconds for Duration and Position.

To fix the kiosk's I need to do the following in videofe.
  1. Add a timer that goes off each second to get status.
  2. Check if the difference between Duration and Position is < 5000000 (5 seconds - this could be configurable).
  3. If yes, start the next video with openuri
    1. then restart the timer

That's all there is to it. Fine tuning is possible using a configurable option that could be set in seconds or milliseconds (to get 1.5 seconds, for example).

#6 Updated by Hammel 12 months ago

  • % Done changed from 20 to 60

This works now but introduces a different problem: FF past the end of the video causes omxplayer to exit.

The way to handle this is to check how much time is left and only do the FF if it's >X seconds. But only do this on kiosks because we can FF past the end of a video in media center mode and it does the right thing (returns to playlist).

Another problem I found is that the MOV files generated by my camera did not work with omxplayer when trying to get the duration and position info. Converting them to mp4 with ffmpeg fixed that problem.

Next up is test that I didn't break media center mode with these changes.

#7 Updated by Hammel 12 months ago

  • Status changed from In Progress to Closed
  • % Done changed from 60 to 100
Verified working on
  • Media system mode
  • kiosk mode
  • auto-kiosk mode.

It's a nice improvement on the playback since I don't have to restart omxplayer every time I get a new video to play.

Changes committed and pushed.
Closing issue.

Also available in: Atom PDF