[mythtv-users] After upgrade to Ubuntu 20.04, frontend crashes X

[Stephen Worthington]

On Sun, 20 Sep 2020 16:23:17 -0700, you wrote:

>> I can not see anything wrong in the log.  But I am only using 20.04 on
>> virtual machines at present, not on my real MythTV boxes using the
>> Nvidia drivers.
>
>> Is the crash happening just by running the mythfrontend GUI, or when
>> you play a recording or video?  When you login via another TTY, is
>> that using Ctrl-Alt-Fx keys to swap to a different screen, or is it
>> via SSH?  What PID are you killing to try to get the screen to unblank
>> - is it the mythfronted one?  If so, did you check that
>> mythfrontend(.real) actually stopped?  There is a bug that means
>> mythfrontend needs to be given two kill commands of the ordinary "kill
>> -15" type to actually get it to stop - it mostly shuts down except for
>> one final thread on the first kill -15 and the second kill -15 then
>> shuts down that last thread.  Did you try kill -9 on mythfrontend?
>> What distro are you running (Ubuntu, Xubuntu, ...)?  What GUI are you
>> using (Gnome, XFCE4, ...)?  What display manager are you using (gdm,
>> lightdm, ...)?  What sort of screen is being used (it appears to be
>> 4k)?  Your video card appears to be an Nvidia GT640 running 390.138
>> drivers.  I did not think that a GT640 was able to do 4k.
>
>Hi, Stephen -
>Thanks for the reply.
>
>The screen goes completely black immediately after I fire up the GUI.  It
>doesn't give me the chance to attempt to play a recording or a video.
>
>I can log onto another tty by using Ctrl-Alt-Fx or via SSH.
>
>Tried to kill the pid associated with mythfrontend.real; tried both -15,
>which didn't work, and  and -9 (which did kill it).  I didn't try using -15
>twice.

Right, so it would be useful to know if 2x "kill -15" works - that
tells us that mythfrontend is not actually locked up, it is just that
the screen display is not working.

You might also like to install a copy of my killm program which does
the 2x kill -15 automatically and if mythfrontend.real does not stop
then, goes on to do a kill -9 one second later:

sudo su
cd /usr/local/bin
wget http://www.jsw.gen.nz/mythtv/killm
chown root:root killm
chmod u=rwx,go=rx killm
exit

If you do "killm x" (any non-empty parameter), it will also kill the
mythfrontend script to stop it from automatically restarting
mythfrontend.real.

>I'm using Ubuntu (was on 18.04 with Gnome; then updated to 20.04 which
>apparently brought Unity back).  The display manager is gdm.

Ubuntu 20.04 is still using gnome as far as I know.  It just looks a
bit like Unity did.

>The display is an LG 32" 4K monitor.  The old reliable GT640 will do 4K,
>albeit at 30 fps max.  Under 18.04, I had the GUI and playback running at
>1920x1080, and after the upgrade, I changed the settings - to keep the GUI
>at HD but the actual playback at 4k - I figured I'd be OK, since the video
>card  does up to 30fps.   But it crashes before the GUI even comes up, so I
>don't think that 4k per se is the problem - but I'm sure I could be wrong.

My best guess from the evidence so far is that the GUI is being
started in a mode the monitor does not actually support.  There is
long history of TVs and monitors having bad EDID data and advertising
modes they do not actually support.  So you should be able to get
mythfrontend.real to work well enough for you to change its GUI
settings by using an override on the command line to put it in a
usable mode.

https://www.mythtv.org/wiki/Override_settings

I have never done this, and the documentation is decidedly lacking,
but I think you should try using a --geometry option, maybe 1920x1080
or 1280x720.

Another thing to try is to use xrandr from ssh.  To make xrandr work
from ssh you have to log in as the same user that the desktop is being
run from.  Then you can use commands like this:

xrandr -d :0

to access the :0 display.  That command should tell you what mode X is
running in and what other modes it will allow you to switch to.  And
you should be able to select a different mode (with the --mode option)
to see if it will switch to that and start working.