Bug #1239
closed
AutoKiosk got stuck and stopped playing videos
Added by Hammel about 2 months ago.
Updated about 1 month ago.
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.
- 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.
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.
A better way to do this is in kioskStartNextVideo() after shutting down the player processor:
- reload the db
- Drop the existing db - requires a a new function
- Rerun the dbLoadKiosk()
- Restart the player processor
- 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.
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.
- 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.
Also available in: Atom
PDF