Project

General

Profile

Actions

Bug #1239

closed

AutoKiosk got stuck and stopped playing videos

Added by Hammel about 2 months ago. Updated about 1 month ago.

Status:
Closed
Priority:
Immediate
Assignee:
Category:
Runtime
Target version:
Start date:
20 Oct 2025
Due date:
% Done:

100%

Estimated time:
Severity:
01 - Critical

Description

There is a log saved in /media/data/log/videofe.log.
I can see that it says it's stuck. Need a way to unstick it that is better than what I now have, obviously.

Actions #1

Updated by Hammel about 2 months ago

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

This might be the problem:

main[videofe.c:1073] INFO Reading database directory: /media
main[videofe.c:1079] INFO gtkrc: /root/data/gtkrc
main[videofe.c:1082] INFO Running from: /media
main[videofe.c:1114] INFO Kiosk mode is enabled.
getFiles[dbkiosk.c:114] INFO Find command: find . -type f | sort
getFiles[dbkiosk.c:131] INFO Filename: ./mmcblk0p1/COPYING.linux
getFiles[dbkiosk.c:131] INFO Filename: ./mmcblk0p1/LICENCE.broadcom

It looks at files outside of the /media/usb area. Maybe I messed that up testing appmgr updates. I need to verify that videofe installs with the problem /etc/videofe.cfg file pointint dbtop to /media/usb only.

Actions #2

Updated by Hammel about 2 months ago

This can happen if videofe is started before the USB sticks are properly mounted.

The way to avoid this is to check if any files were found in getFiles(). If not, pause for a few seconds, then retry. Do this no more than 3 times.
If not files are found, post a message saying so instead of just playing a blank screen.

Actions #3

Updated by Hammel about 1 month ago

A better way to do this is in kioskStartNextVideo() after shutting down the player processor:
  1. reload the db
    1. Drop the existing db - requires a a new function
    2. Rerun the dbLoadKiosk()
  2. Restart the player processor
  3. Then schedule startKiosk()

Also, in startKiosk() a check of the db length should be done and if the length is zero then display an image instead of running a video. Or maybe make a 10-20 second video that just displays an image. I might be able to use omxiv for this.

Actions #4

Updated by Hammel about 1 month ago

Actually, this is appears to be a problem with omxplayer itself. Checking running processes I can that omxplayer.bin and videofe are running but not doing anything.

$ ps | egrep "omxplayer|videofe" | egrep -v "egrep" 
 8841 root     11852 S    xterm -display :0.0 -fullscreen -fg black -bg black -e omxplayer.bin --no-keys -r '/media/usb/./s
 8842 root      140m S    omxplayer.bin --no-keys -r /media/usb/./sda1/02-marker-50.mp4
20996 root     1429m S    /usr/bin/videofe -k -a

The "S" means interruptable sleep.
If I wait awhile and do this again, I get this.

$ ps | egrep "omxplayer|videofe" | egrep -v "egrep" 
 5729 root      204m S    /usr/bin/videofe -k -a
 8841 root     11852 S    xterm -display :0.0 -fullscreen -fg black -bg black -e omxplayer.bin --no-keys -r '/media/usb/./s
 8842 root      140m S    omxplayer.bin --no-keys -r /media/usb/./sda1/02-marker-50.mp4

So videofe is being restarted but omxplayer is stuck. Killing omxplayer.bin allowed videofe to start playing videos again.
So the fix is to kill all omxplayer.bin instances in the unlikely event that videofe did not kill it's child correctly for some reason.

Actions #5

Updated by Hammel about 1 month ago

  • Status changed from In Progress to Closed
  • % Done changed from 10 to 100

Implemented a mechanism, called during init or when stalled, to cleanup any hung players in cases where our attempt to cleanup child processes didn't work for some reason.
This should allow clean restarts in cases where videofe thinks it's stalled because omxplayer is hung.

Code tested on hardware though a hang has not been encountered yet.
Code committed and pushed.
Closing issue - it can be reopened if a hung state causes this problem to reappear.

Actions

Also available in: Atom PDF