You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
i am having a similar problem like issue #61 but using MPEG4 video files instead:
Omxplayer is started through a script on startup, running in a loop playing video files from a folder on the raspberry, while output is set to HDMI (-o hdmi), where a tv is connected to. Randomly it kind of stops playing during playback, usually after 1 to 1 1/2 hours when several loops already have been passed.
Looking at the processes using ssh from another place due to resolve what is happening, either script and omxplayer seem to run normally, cause omxplayer processes still keep updated (finished playback processes seem to get closed and new playback processes seem to get started like usual) but with no hdmi/tv output anymore. It looks like frozen output (kind of).
Like Stu mentioned on issue #61 , enabling logging (-l) within the script does delay the output freezing for somewhat around 30 minutes.
Some facts which might help to surround the causing part:
• all video files are H264/MPEG4 with AAC audio encoded
• all video files do play without problems started one by one
• the script does loop all video files several times without problems before output suddenly freezes
The playback script which is started on startup:
===== script start =====
!/bin/bash
Turn off cursor
setterm -cursor off
Path to the directory containing the videos, variable
VIDEOPATH="/boot/VideoContent"
Application playing the videos, variable
PLAYER="omxplayer"
Playback loop, infinite
while true; do
if ps ax | grep -v grep | grep $PLAYER > /dev/null
then
sleep 1;
else
for entry in $VIDEOPATH/*
do
clear
omxplayer -o hdmi --no-osd -r -g -s --layout 2.0 $entry > /dev/null
done
fi
done
===== script end =====
If i only could find/catch/grab something (e.g. memory or gpu activity) to observe the output which really happens (which means no output/nothing when problem occurs), i could set a watchdog and trigger a clean reboot... that would help for now - even if it unfortunately would not remove the problem itself.
Any ideas?
Thanks in advance,
Cheers,
Olaf
The text was updated successfully, but these errors were encountered:
Hello everyone,
i am having a similar problem like issue #61 but using MPEG4 video files instead:
Omxplayer is started through a script on startup, running in a loop playing video files from a folder on the raspberry, while output is set to HDMI (-o hdmi), where a tv is connected to. Randomly it kind of stops playing during playback, usually after 1 to 1 1/2 hours when several loops already have been passed.
Looking at the processes using ssh from another place due to resolve what is happening, either script and omxplayer seem to run normally, cause omxplayer processes still keep updated (finished playback processes seem to get closed and new playback processes seem to get started like usual) but with no hdmi/tv output anymore. It looks like frozen output (kind of).
Like Stu mentioned on issue #61 , enabling logging (-l) within the script does delay the output freezing for somewhat around 30 minutes.
Some facts which might help to surround the causing part:
• all video files are H264/MPEG4 with AAC audio encoded
• all video files do play without problems started one by one
• the script does loop all video files several times without problems before output suddenly freezes
The playback script which is started on startup:
===== script start =====
!/bin/bash
Turn off cursor
setterm -cursor off
Path to the directory containing the videos, variable
VIDEOPATH="/boot/VideoContent"
Application playing the videos, variable
PLAYER="omxplayer"
Playback loop, infinite
while true; do
if ps ax | grep -v grep | grep $PLAYER > /dev/null
then
sleep 1;
else
for entry in $VIDEOPATH/*
do
clear
omxplayer -o hdmi --no-osd -r -g -s --layout 2.0 $entry > /dev/null
done
fi
done
===== script end =====
If i only could find/catch/grab something (e.g. memory or gpu activity) to observe the output which really happens (which means no output/nothing when problem occurs), i could set a watchdog and trigger a clean reboot... that would help for now - even if it unfortunately would not remove the problem itself.
Any ideas?
Thanks in advance,
Cheers,
Olaf
The text was updated successfully, but these errors were encountered: