sudo sv restart frontend is probably the most "proper" way. And we have that tied to the Alt+f shortcut. But if that is not working that it would seem to indicate that Xorg is what is wedged and not just mythfrontend. When it freezes are you able to open a xterm or ssh in?.

SSH into the box is always available.From the frontend a Ctrl-X does start an xterm, there is a a few second delay on launch as to when the cat walks across the keyboard and hits some key combination with enter key and successfully launches a few hundred xterms in under two seconds.

[quoteAnother note is that one change in R8.4 was that when the frontend shuts down now it tries to kill all mythfrontend explicitly. Before it relied on Xorg taking them down but I have seen some situations where the mythfrontend process didn't quit when Xorg went away.[/quote]

My new hobby of watching htop, shows the some unamed process is temporarily able to gain privileged access to the cpu after the mythfrontend processes go 100% critical. I believe the PPID or PPGRP is 5 of the mystery process with a life of about 5 seconds. After this process goes away, within another 5 seconds the mythfrontend 100% behavior returns.

Also note the sv restart does kill the old mythfrontend process and starts a new one but the new process jumps to 100% like the old one. The main terminal is dead once once the mythfrontend goes 100%, and only ssh is available.

When attempting to reboot in this state, the current process is the following:

The background shutdown is because the foreground shutdown never returns. However the at this point the background shutdown -r command is still being blocked. Killing the following process constantly allows the background shutdown process to trigger:

Ok I have figured out a way to restart the frontend after a video playback with 100% success.

sv stop frontend

this makes mythfrontend go to 100%

htop

wait for the mythfrontend process to go from 100% to termination on its own. it takes about 90 seconds

sv start frontend

My guess why restart and manual performing a stop/start fail is because the mythfrontend never fully shutdowns and then a new mythfrontend starts up and attaches to the same process or device that original mythfrontend is waiting to be terminated, causing the race condition.

Each drop of LinHes is changing the pattern of how to recover from a video freeze without running into 100% CPU usage.

I am using the following command to recover is good success:

Code:

pkill -9 -o -f "su - mythtv -l -c /usr/LH/bin/LinHES-start"

Note that the CPU still jumps to 100% on an inner zombie process still gets trigger by the above kill command. However after about 20 seconds when the sv process automatically kicks off a new frontend, sv or X somehow is able to kill the 100% zombie process. The zombie process seem to be owned by the LinHES-start process and has no process name, however maybe the process is actually owned by the sv process or transferred to it.

The previous drop of LinHES, the 100% process in the zombie mythfrontend process was called AudioBaseOutput from recollection. Killing that inner process on a video freeze would free the video freeze without restarting the frontend entirely. The new drop, it not displaying any inner AudioBaseOutpt process on video hang.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum