Mailing List Archive: After upgrade to Ubuntu 20.04, frontend crashes X

After upgrade to Ubuntu 20.04, frontend crashes X

Sep 19, 2020, 12:58 PM

Post #1 of 11 (1360 views)

Side note - had to rejoin with a different email address after your
listserv decided to ban my old one (which I've used on this list for over
ten years) because someone else in my mail server's IP block got onto
Spamhaus's naughty list.

In any case - one of my frontends (v31), which was running fine on Ubuntu
18.04, crashes X after the upgrade to 20.04. The screen just goes black,
and I have to log in via the CLI on another tty if I want to do anything,
but I can't kill the pid even then, so I have to reboot if I have to use X.

It is using the same NVidia driver as it did under 18.04.

I have a couple of other machines (including my main media server, which is
a backend/frontend, and two other frontends) that I'd like to upgrade but
am waiting to get his fixed first.

This is the log dump. I see a couple of things that *might* be an issue,
but am not sure.

Display: Found screen number 0 (HDMI-0)
CoreContext opengl/mythrenderopengl.cpp:421 (DebugFeatures) OpenGL: OpenGL
vendor : NVIDIA Corporation
CoreContext opengl/mythrenderopengl.cpp:422 (DebugFeatures) OpenGL: OpenGL
renderer : GeForce GT 640/PCIe/SSE2
CoreContext opengl/mythrenderopengl.cpp:423 (DebugFeatures) OpenGL: OpenGL
version : 4.6.0 NVIDIA 390.138
CoreContext opengl/mythrenderopengl.cpp:424 (DebugFeatures) OpenGL: Qt
platform : xcb
CoreContext opengl/mythrenderopengl.cpp:427 (DebugFeatures) OpenGL: EGL
display : No
CoreContext opengl/mythrenderopengl.cpp:428 (DebugFeatures) OpenGL: EGL
images : No
CoreContext opengl/mythrenderopengl.cpp:430 (DebugFeatures) OpenGL: Qt
OpenGL format : OpenGL 4.6
CoreContext opengl/mythrenderopengl.cpp:431 (DebugFeatures) OpenGL: Qt
OpenGL surface : RGBA: 8880 Depth: 24 Stencil: 0
CoreContext opengl/mythrenderopengl.cpp:432 (DebugFeatures) OpenGL: Max
texture size : 16384
CoreContext opengl/mythrenderopengl.cpp:433 (DebugFeatures) OpenGL: Max
texture units : 192
CoreContext opengl/mythrenderopengl.cpp:434 (DebugFeatures) OpenGL: Shaders
: Yes
CoreContext opengl/mythrenderopengl.cpp:435 (DebugFeatures) OpenGL: NPOT
textures : Yes
CoreContext opengl/mythrenderopengl.cpp:436 (DebugFeatures) OpenGL:
Multitexturing : Yes
CoreContext opengl/mythrenderopengl.cpp:437 (DebugFeatures) OpenGL:
Rectangular textures : Yes
CoreContext opengl/mythrenderopengl.cpp:439 (DebugFeatures) OpenGL: Buffer
mapping : Yes
CoreContext opengl/mythrenderopengl.cpp:440 (DebugFeatures) OpenGL:
Framebuffer objects : Yes
CoreContext opengl/mythrenderopengl.cpp:441 (DebugFeatures) OpenGL: 16bit
framebuffers : Yes
CoreContext opengl/mythrenderopengl.cpp:442 (DebugFeatures) OpenGL: Unpack
Subimage : Yes
CoreContext opengl/mythrenderopengl.cpp:443 (DebugFeatures) OpenGL:
GL_RED/GL_R8 : Yes
CoreContext opengl/mythrenderopengl.cpp:398 (Init) OpenGL: Initialised
MythRenderOpenGL
CoreContext opengl/mythrenderopengl.cpp:399 (Init) OpenGL: Using full range
output
CoreContext mythuihelper.cpp:762 (PruneCacheDir) MythUIHelper: Pruning
cache directory: /home/rcs/.mythtv/cache/remotecache
CoreContext mythuihelper.cpp:819 (PruneCacheDir) MythUIHelper: Kept 0
files, deleted 0 files, stat error on 0 files
CoreContext mythuihelper.cpp:762 (PruneCacheDir) MythUIHelper: Pruning
cache directory: /home/rcs/.mythtv/cache/thumbnails
CoreContext mythuihelper.cpp:819 (PruneCacheDir) MythUIHelper: Kept 7
files, deleted 0 files, stat error on 0 files
CoreContext mythuitext.cpp:294 (SetCutDown) 'buttontext' (base.xml:2243):
<scroll> and <cutdown> are not combinable.
SendMessage mythcorecontext.cpp:469 (ConnectCommandSocket)
MythCoreContext::ConnectCommandSocket(): Connecting to backend server:
192.168.1.9:6543 (try 1 of 10)
mythfrontend[42783]: I SendMessage mythcorecontext.cpp:1691
(CheckProtoVersion) CheckProtoVersion(): Using protocol version 91 BuzzOff
mythfrontend.real: mythfrontend[42783]: I CoreContext
devices/mythcecadapter.cpp:144 (Open) CECAdapter: Using physical address
1.0.0.0 from EDID
mythfrontend[42783]: E CoreContext devices/mythcecadapter.cpp:173 (Open)
CECAdapter: Failed to load libcec.
CoreContext schemawizard.cpp:117 (Compare) Current MythTV Schema Version
(DBSchemaVer): 1361
CoreContext decoders/mythvdpauhelper.cpp:71 (HaveVDPAU) VDPAUHelp:
Supported/available VDPAU decoders:
CoreContext decoders/mythvdpauhelper.cpp:74 (HaveVDPAU) VDPAUHelp: MPEG1
(Max size: 4032x4048)
CoreContext decoders/mythvdpauhelper.cpp:74 (HaveVDPAU) VDPAUHelp: MPEG2
Simple (Max size: 4032x4048)
CoreContext decoders/mythvdpauhelper.cpp:74 (HaveVDPAU) VDPAUHelp: MPEG2
Main (Max size: 4032x4048)
CoreContext decoders/mythvdpauhelper.cpp:74 (HaveVDPAU) VDPAUHelp: MPEG4
Simple (Max size: 2048x2048)
CoreContext decoders/mythvdpauhelper.cpp:74 (HaveVDPAU) VDPAUHelp: MPEG4
Advanced Simple (Max size: 2048x2048)
CoreContext decoders/mythvdpauhelper.cpp:74 (HaveVDPAU) VDPAUHelp: VC1
Simple (Max size: 2048x2048)
CoreContext decoders/mythvdpauhelper.cpp:74 (HaveVDPAU) VDPAUHelp: VC1 Main
(Max size: 2048x2048)
CoreContext decoders/mythvdpauhelper.cpp:74 (HaveVDPAU) VDPAUHelp: VC1
Advanced (Max size: 2048x2048)
CoreContext decoders/mythvdpauhelper.cpp:74 (HaveVDPAU) VDPAUHelp: H264
Baseline (Max size: 4032x4080)
CoreContext decoders/mythvdpauhelper.cpp:74 (HaveVDPAU) VDPAUHelp: H264
Main (Max size: 4032x4080)
CoreContext decoders/mythvdpauhelper.cpp:74 (HaveVDPAU) VDPAUHelp: H264
High (Max size: 4032x4080)
CoreContext decoders/mythvdpauhelper.cpp:74 (HaveVDPAU) VDPAUHelp: H264
Extended (Max size: 4032x4080)
CoreContext decoders/mythvdpauhelper.cpp:74 (HaveVDPAU) VDPAUHelp: H264
Constrained (Max size: 4032x4080)
CoreContext decoders/mythvdpauhelper.cpp:74 (HaveVDPAU) VDPAUHelp: H264
Constrained High (Max size: 4032x4080)
CoreContext decoders/mythvdpauhelper.cpp:74 (HaveVDPAU) VDPAUHelp: H264
High 444 (Max size: 4032x4080)
CoreContext decoders/mythvaapicontext.cpp:496 (HaveVAAPI) VAAPIDec: VAAPI
functionality checked failed
CoreContext decoders/mythnvdeccontext.cpp:539 (HaveNVDEC) NVDEC: No NVDEC
decoders found
CoreContext decoders/mythv4l2m2mcontext.cpp:378 (HaveV4L2Codecs) V4L2_M2M:
No V4L2 decoders found
CoreContext mythmainwindow.cpp:1902 (RegisterMediaPlugin) Registering
Internal as a media playback plugin.
CoreContext mediamonitor-unix.cpp:211 (CheckMountable)
MMUnix:CheckMountable: DBus interface error: The name
org.freedesktop.UDisks was not provided by any .service files
CoreContext mediamonitor-unix.cpp:211 (CheckMountable)
MMUnix:CheckMountable: DBus interface error: The name
org.freedesktop.UDisks was not provided by any .service files
CoreContext mediamonitor-unix.cpp:211 (CheckMountable)
MMUnix:CheckMountable: DBus interface error: The name
org.freedesktop.UDisks was not provided by any .service files
CoreContext mediamonitor-unix.cpp:211 (CheckMountable)
MMUnix:CheckMountable: DBus interface error: The name
org.freedesktop.UDisks was not provided by any .service files
CoreContext mediamonitor-unix.cpp:211 (CheckMountable)
MMUnix:CheckMountable: DBus interface error: The name
org.freedesktop.UDisks was not provided by any .service files
CoreContext mediamonitor-unix.cpp:211 (CheckMountable)
MMUnix:CheckMountable: DBus interface error: The name
org.freedesktop.UDisks was not provided by any .service files
CoreContext mediamonitor-unix.cpp:211 (CheckMountable)
MMUnix:CheckMountable: DBus interface error: The name
org.freedesktop.UDisks was not provided by any .service files
CoreContext mediamonitor-unix.cpp:211 (CheckMountable)
MMUnix:CheckMountable: DBus interface error: The name
org.freedesktop.UDisks was not provided by any .service files
CoreContext mediamonitor-unix.cpp:211 (CheckMountable)
MMUnix:CheckMountable: DBus interface error: The name
org.freedesktop.UDisks was not provided by any .service files
CoreContext mediamonitor-unix.cpp:211 (CheckMountable)
MMUnix:CheckMountable: DBus interface error: The name
org.freedesktop.UDisks was not provided by any .service files
CoreContext mythplugin.cpp:123 (MythPluginManager) No plugins directory
/usr/lib/mythtv/plugins
CoreContext main.cpp:1224 (RunMenu) Found mainmenu.xml for theme
'MythMediaStream'
CoreContext themechooser.cpp:1034 (ThemeUpdateChecker) Checking for theme
updates every hour
CoreContext housekeeper.cpp:663 (RegisterTask) Registering HouseKeeperTask
'HardwareProfiler'.
CoreContext housekeeper.cpp:737 (Start) Starting HouseKeeper.
CoreContext mythdisplay.cpp:426 (GeometryChanged) Display: New screen
geometry: 3840x2160+0+0
CoreContext mythdisplay.cpp:402 (PhysicalDPIChanged) Display: Qt screen
pixel ratio changed to 52.10
CoreContext bonjourregister.cpp:115 (BonjourCallback) Bonjour: Service
registration complete: name 'Mythfrontend on yoda' type
'_mythfrontend._tcp.' domain: 'local.'
CoreContext signalhandling.cpp:299 (handleSignal) Received Terminated: Code
0, PID 43508, UID 1000, Value 0x00000000
CoreContext mythuihelper.cpp:762 (PruneCacheDir) MythUIHelper: Pruning
cache directory: /home/rcs/.mythtv/cache/remotecache
CoreContext mythuihelper.cpp:819 (PruneCacheDir) MythUIHelper: Kept 0
files, deleted 0 files, stat error on 0 files
CoreContext mythuihelper.cpp:762 (PruneCacheDir) MythUIHelper: Pruning
cache directory: /home/rcs/.mythtv/cache/thumbnails
CoreContext mythuihelper.cpp:819 (PruneCacheDir) MythUIHelper: Kept 7
files, deleted 0 files, stat error on 0 files
CoreContext bonjourregister.cpp:29 (~BonjourRegister) Bonjour:
De-registering service '_mythfrontend._tcp.' on 'Mythfrontend on yoda'
CoreContext mythpainter.cpp:36 (Teardown) MythPainter: 36 images not yet
de-allocated.
CoreContext opengl/mythpainteropengl.cpp:84 (ClearCache) Clearing OpenGL
painter cache.
CoreContext opengl/mythrenderopengl.cpp:147 (~MythRenderOpenGL) OpenGL:
MythRenderOpenGL closing
CoreContext mythdisplay.cpp:200 (~MythDisplay) Display: Deleting
CoreContext AirPlay/mythraopdevice.cpp:71 (Cleanup) RAOP Device: Cleaning
up.
CoreContext AirPlay/mythairplayserver.cpp:393 (Cleanup) AirPlay: Cleaning
up.
CoreContext main.cpp:293 (cleanup) Shutting down UPnP client...
CoreContext platforms/mythpowerdbus.cpp:72 (~MythPowerDBus) PowerDBus:
Closing interfaces
CoreContext mythcontext.cpp:1659 (~MythContext) Waiting for threads to exit.
CoreContext mythcontext.cpp:1665 (~MythContext) Exiting

Any thoughts? .

--

__________________________________
Bob Sully

Re: After upgrade to Ubuntu 20.04, frontend crashes X [ In reply to ]

jam at tigger

Sep 19, 2020, 4:40 PM

Post #2 of 11 (1360 views)

Permalink

> On 20 Sep 2020, at 3:58 am, Bob Sully <malibyte56@gmail.com> wrote:
>
> Side note - had to rejoin with a different email address after your listserv decided to ban my old one (which I've used on this list for over ten years) because someone else in my mail server's IP block got onto Spamhaus's naughty list.

Bob after endless bitching to bluehost, my server, they told me "We are a web hosting company, mail is a freeby thrown in ..". but they have a farm of mail servers each on own IP.
If a mail to mythtv-users bounces immediately resend. I usually get another (clean) server.
James
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Re: After upgrade to Ubuntu 20.04, frontend crashes X [ In reply to ]

stephen_agent at jsw

Sep 19, 2020, 8:33 PM

Post #3 of 11 (1360 views)

Permalink

On Sat, 19 Sep 2020 12:58:34 -0700, you wrote:

>In any case - one of my frontends (v31), which was running fine on Ubuntu
>18.04, crashes X after the upgrade to 20.04. The screen just goes black,
>and I have to log in via the CLI on another tty if I want to do anything,
>but I can't kill the pid even then, so I have to reboot if I have to use X.
>
>It is using the same NVidia driver as it did under 18.04.
>
>I have a couple of other machines (including my main media server, which is
>a backend/frontend, and two other frontends) that I'd like to upgrade but
>am waiting to get his fixed first.
>
>
>This is the log dump. I see a couple of things that *might* be an issue,
>but am not sure.

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.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Re: After upgrade to Ubuntu 20.04, frontend crashes X [ In reply to ]

malibyte56 at gmail

Sep 20, 2020, 4:06 PM

Post #4 of 11 (1348 views)

Permalink

>> Side note - had to rejoin with a different email address after your
listserv decided to ban my old one
>> (which I've used on this list for over ten years) because someone else
in my mail server's IP block >got onto Spamhaus's naughty list.

> Bob after endless bitching to bluehost, my server, they told me "We are a
web hosting company,
> mail is a freeby thrown in ..". but they have a farm of mail servers each
on own IP.
> If a mail to mythtv-users bounces immediately resend. I usually get
another (clean) server.
> James

Thanks' James. I have had this come up a couple of times with other
listsertvs, just tried once more and then quit after it happened again.
I'll give it more tries next time. :-)

Regards - Bob
--

Re: After upgrade to Ubuntu 20.04, frontend crashes X [ In reply to ]

malibyte56 at gmail

Sep 20, 2020, 4:23 PM

Post #5 of 11 (1341 views)

Permalink

> 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.

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.

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.

Thanks again for your help!

Regards -
Bob

--

__________________________________
Bob Sully

Re: After upgrade to Ubuntu 20.04, frontend crashes X [ In reply to ]

stephen_agent at jsw

Sep 21, 2020, 2:17 AM

Post #6 of 11 (1341 views)

Permalink

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.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Re: After upgrade to Ubuntu 20.04, frontend crashes X [ In reply to ]

malibyte56 at gmail

Sep 21, 2020, 11:39 PM

Post #7 of 11 (1336 views)

Permalink

>>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

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

>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.

Thanks again, Stephen. I downloaded your killm utility.

Before running mythfrontend:

rcs@yoda: ~]$ xrandr
Screen 0: minimum 8 x 8, current 3840 x 2160, maximum 16384 x 16384
VGA-0 disconnected (normal left inverted right x axis y axis)
DVI-D-0 disconnected (normal left inverted right x axis y axis)
HDMI-0 connected primary 3840x2160+0+0 (normal left inverted right x axis y
axis) 1872mm x 1053mm
3840x2160 30.00*+ 30.00 29.97 25.00 23.98
1920x1080 60.00 59.94 29.97 23.98 60.00
1600x900 60.00
1280x1024 60.02
1280x800 59.81
1280x720 60.00 59.94
1152x864 60.00
1024x768 60.00
800x600 60.32
720x480 59.94
640x480 59.94 59.93
DVI-D-1 disconnected (normal left inverted right x axis y axis)

Running mythfrontend --geometry 1920x1080+200+200 (after myth update today)
does not cause the X display to go black, as it did before; now it simply
freezes up. Ctrl-Alt-F1 to log back in gives me the gdm login screen, but
after username/password, I now have the black screen again. After
Ctrl-Alt-F3 and login via the CLI:

[rcs@yoda: ~]$ sudo su -
[sudo] password for rcs:
root@yoda:~#
killm
root@yoda:~# exit

Going back to the X screen -> still all black, unresponsive.

Now, after logging in via ssh from another machine OR via Ctrl-Alt-Fx from
the affected machine (same result):

[rcs@yoda: ~]$ xrandr -d :0
Invalid MIT-MAGIC-COOKIE-1 keyCan't open
display :0
[rcs@yoda: ~]$ xrandr
Can't open display

<scratching my head>
Thanks again -
Bob

Re: After upgrade to Ubuntu 20.04, frontend crashes X [ In reply to ]

stephen_agent at jsw

Sep 22, 2020, 4:03 AM

Post #8 of 11 (1336 views)

Permalink

On Mon, 21 Sep 2020 23:39:01 -0700, you wrote:

>>>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
>
>>If you do "killm x" (any non-empty parameter), it will also kill the
>>mythfrontend script to stop it from automatically restarting
>>mythfrontend.real.
>
>>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.
>
>
>Thanks again, Stephen. I downloaded your killm utility.
>
>Before running mythfrontend:
>
>rcs@yoda: ~]$ xrandr
>Screen 0: minimum 8 x 8, current 3840 x 2160, maximum 16384 x 16384
>VGA-0 disconnected (normal left inverted right x axis y axis)
>DVI-D-0 disconnected (normal left inverted right x axis y axis)
>HDMI-0 connected primary 3840x2160+0+0 (normal left inverted right x axis y
>axis) 1872mm x 1053mm
> 3840x2160 30.00*+ 30.00 29.97 25.00 23.98
> 1920x1080 60.00 59.94 29.97 23.98 60.00
> 1600x900 60.00
> 1280x1024 60.02
> 1280x800 59.81
> 1280x720 60.00 59.94
> 1152x864 60.00
> 1024x768 60.00
> 800x600 60.32
> 720x480 59.94
> 640x480 59.94 59.93
>DVI-D-1 disconnected (normal left inverted right x axis y axis)

That looks OK - it is using 4k@30 mode which is likely the default for
the monitor.

>Running mythfrontend --geometry 1920x1080+200+200 (after myth update today)
>does not cause the X display to go black, as it did before; now it simply
>freezes up.

I am not sure why you used the +200+200 offsets. You would not
normally what to offset the screen unless you had a specific reason. I
do not think that should cause any problems, but it would be worth
trying again with +0+0. It would also pay to directly run
mythfrontend.real rather than running it via the mythfrontend script.
I am not sure how well the script passes on command line parameters to
the mythfrontend.real program. However, I think that neither of those
will actually help with the original problem.

A black screen is what normally happens when a screen is being sent a
signal that it can not cope with, typically where it has a clock rate
that is too high. A screen being sent a wrong signal that has a low
enough clock rate will normally create a distorted display, but you
will be able to see things change on screen when you do commands, even
if the distortion makes it impossible to make any sense of the output.

A freeze up where the current text on the screen stops being updated
is a different symptom - it suggests that the software running the
display has locked up or crashed somewhere. If the problem is in the
program that is sending data to the display, killing that program will
normally fix the problem. If the problem is in the display drivers,
as is likely the case here, then once the bug in the display drivers
has been triggered, there is very little that can get back a working
display unless you are able to completely shut down and restart X and
the display drivers.

> Ctrl-Alt-F1 to log back in gives me the gdm login screen,

Ctrl-Alt-F1 should give you a text mode screen with a login prompt,
nothing to do with gdm or the GUI screens. Is that what is happening?

The GUI screen is on Ctrl-Alt-F7 normally, and Ctrl-Alt-Fx where
1<=x<=6 are all text screens. The text screens do have to use the
display drivers, but only a bare minimum of the display driver code.
They do not use any of the X and GUI software such as the display
manager.

>but
>after username/password, I now have the black screen again. After
>Ctrl-Alt-F3 and login via the CLI:
>
>[rcs@yoda: ~]$ sudo su -
> [sudo] password for rcs:
> root@yoda:~#
>killm
> root@yoda:~# exit
>
>Going back to the X screen -> still all black, unresponsive.

It would pay to check here that mythfrontend.real has actually been
killed. If the display drivers have suffered a crash or lockup,
mythfrontend.real may still be running, despite having been sent a
kill -9. This happens when there are system memory areas that have
not been deallocated, so the system can not actually shut down the
program. If that is what has happened, it has become a "zombie"
program and may only be able to be got rid of by a reboot, or maybe if
you were able to completely shut down X and restart it. This command
will show any mythfrontend programs that are running:

ps -e | grep mythfront

Unfortunately, I do not know of a way to shut down and restart X when
using gdm as the display manager. If you switch to lightdm, then
restarting lightdm will normally do a full restart of X and bring up
the GUI login screen:

sudo systemctl restart lightdm

I have never had that command work for gdm though - gdm seems to be
more complicated than lightdm. Switching to lightdm is usually
straightforward if you want to try that. If it is not installed,
install it:

sudo apt install lightdm

The install may ask if you want to select the display manager, if so,
then select lightdm. If it does not ask that, then run:

sudo dpkg-reconfigure gdm3

and when asked select lightdm as the display manager. To switch back
to gdm from lightdm, just do:

sudo dpkg-reconfigure gdm3

and select gdm3 as the display manager.

If it is enabled, Ctrl-Alt-Backspace should also restart X. I know
how to enable it for XFCE4 (Xubuntu), but not for Gnome. Maybe an
Internet search can tell you.

>Now, after logging in via ssh from another machine OR via Ctrl-Alt-Fx from
>the affected machine (same result):
>
>[rcs@yoda: ~]$ xrandr -d :0
> Invalid MIT-MAGIC-COOKIE-1 keyCan't open
>display :0

I have never had that message, but I am guessing that it means that X
is crashed so there is no working display to connect to.

>[rcs@yoda: ~]$ xrandr
> Can't open display

This is as expected. Without a -d option, xrandr does not have a
display it can open. When xrandr is run from a terminal on the GUI,
it can automatically find the display it is running on. When it is
run from a non-GUI terminal such as from ssh or Ctrl-Alt-Fx, there is
no default display and it will always need a -d option to tell it
which X display to connect to.

><scratching my head>
>Thanks again -
>Bob

You can try different geometry settings to see if you get better
results, or try using xrandr to change the mode to a 1920x1080 one:

xrandr -d :0 --output HDMI-0 --mode 1920x1080_60

for example. Finding the exact syntax for each mode is a bit of a
problem. If you add this to your /etc/X11/xorg.conf file:

Section "Screen"
Option "ModeDebug" "true"
EndSection

then X will list all the valid modes in the /var/log/Xorg.0.log file
like this:

[ 48.862] (II) NVIDIA(GPU-0): Validating Mode "1400x1050_60":
[ 48.862] (II) NVIDIA(GPU-0): Mode Source: X Server
[ 48.862] (II) NVIDIA(GPU-0): 1400 x 1050 @ 60 Hz
[ 48.862] (II) NVIDIA(GPU-0): Pixel Clock : 122.00 MHz
[ 48.862] (II) NVIDIA(GPU-0): HRes, HSyncStart : 1400, 1488
[ 48.862] (II) NVIDIA(GPU-0): HSyncEnd, HTotal : 1640, 1880
[ 48.862] (II) NVIDIA(GPU-0): VRes, VSyncStart : 1050, 1052
[ 48.862] (II) NVIDIA(GPU-0): VSyncEnd, VTotal : 1064, 1082
[ 48.862] (II) NVIDIA(GPU-0): Sync Polarity : +H +V
[ 48.862] (II) NVIDIA(GPU-0): Viewport 1400x1050+0+0
[ 48.862] (II) NVIDIA(GPU-0): Horizontal Taps 1
[ 48.862] (II) NVIDIA(GPU-0): Vertical Taps 1
[ 48.862] (II) NVIDIA(GPU-0): Core Formats 0xfff
[ 48.862] (II) NVIDIA(GPU-0): Base Formats 0xfff
[ 48.862] (II) NVIDIA(GPU-0): Distributed Rendering 1
[ 48.862] (II) NVIDIA(GPU-0): Overlay Formats 0xff6
[ 48.862] (II) NVIDIA(GPU-0): Mode "1400x1050_60" is valid.

Only ones with the "Mode "xxxx" is valid." are able to be used. The
others will have a line in the same location telling why they were
rejected. Should the need arise, the information in each of these
text blocks can be directly translated to a Modeline entry for
xorg.conf. The above data would translate to:

Modeline "1400x1050_60" 122.00 1400 1488 1640 1880 1050 1052 1064
1082 +hsync +vsync

If you can get the mode to change using xrandr, you should try
switching to all the valid modes you find in Xorg.0.log that you might
want to use, to see which ones work and which ones do not. If, as I
suspect, there are some modes that X thinks are valid but do not
actually work, and that is what is causing your problem, then you will
need to set up your xorg.conf to exclude the bad modes, or to adjust
their settings so that they are valid. Doing that is a tedious
process, so first just see if some bad modes are in fact the problem.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Re: After upgrade to Ubuntu 20.04, frontend crashes X [ In reply to ]

malibyte56 at gmail

Oct 21, 2020, 12:57 PM

Post #9 of 11 (1283 views)

Permalink

Hi, Stephen -

Sorry for the delay. I was away for a couple of weeks and have been
extremely busy since getting back.

I was since able to cleanly update another frontend (exact same hardware)
to v31 under 20.04 just by running ubuntu's dist-upgrade process.

So, I was wondering which files I can copy from the working frontend to the
malfunctioning one to try and resolve the issue on the first machine.
Thanks!

Bob

Re: After upgrade to Ubuntu 20.04, frontend crashes X [ In reply to ]

malibyte56 at gmail

Nov 3, 2020, 1:53 PM

Post #10 of 11 (1253 views)

Permalink

<bump>
To restate -
I have two frontend machines, both running identical hardware and operating
systems (Intel i7-4770k processors, Gigabyte motherboards (same model),
32GB RAM, NVidia 640GT video. Both run Ubuntu 20.04 and Myth v31, using
vdpau.

Both are running 4K video (though different monitors).

After updating the first machine (hostname Yoda) to 20.04 and v31 (from
18.04/v31), I tried to change some of the parameters (start the GUI in HD,
but go to 4K for actual playback; before it was playing back at HD
resolution also, but since I upgraded to 4K, I figured I should be able to
use the whole screen, not just a quarter of it). Well, as summarized
earlier, firing up mythfrontend on this machine now hard crashes X.

The second machine (hostname Solo) cleanly updated to 20.04 from 18.04 and
mythfrontend works beautifully on it, at HD for the GUI and 4K for playback.

It seems that the easiest fix here is simply to copy Solo's configuration
to Yoda. However, I don't see any files which would appear to fix this.
Config.xml doesn't seem to contain anything relevant to the problem, and
none of the .xml files in the themes directory have changed for several
years, if at all.

Can someone give me a list of files, if any, I can copy from Solo to Yoda
to deal with this?
There is no database on the frontends that I can find...is the config info
for the frontends kept in the DB on the backend?

Backend is also running v31 on 20.04.

Scratching my head...any info would be appreciated. Thanks.
--

__________________________________
Bob

Re: After upgrade to Ubuntu 20.04, frontend crashes X [ In reply to ]

rramesh2400 at gmail

Nov 3, 2020, 4:36 PM

Post #11 of 11 (1252 views)

Permalink

On 11/3/20 3:53 PM, Bob Sully wrote:
> <bump>
> To restate -
> I have two frontend machines, both running identical hardware and
> operating systems (Intel i7-4770k processors, Gigabyte motherboards
> (same model), 32GB RAM, NVidia 640GT video. Both run Ubuntu 20.04 and
> Myth v31, using vdpau.
>
> Both are running 4K video (though different monitors).
>
> After updating the first machine (hostname Yoda) to 20.04 and v31
> (from 18.04/v31), I tried to change some of the parameters (start the
> GUI in HD, but go to 4K for actual playback; before it was playing
> back at HD resolution also, but since I upgraded to 4K, I figured I
> should be able to use the whole screen, not just a quarter of it).
> Well, as summarized earlier, firing up mythfrontend on this machine
> now hard crashes X.
>
> The second machine (hostname Solo) cleanly updated to 20.04 from 18.04
> and mythfrontend works beautifully on it, at HD for the GUI and 4K for
> playback.
>
> It seems that the easiest fix here is simply to copy Solo's
> configuration to Yoda. However, I don't see any files which would
> appear to fix this. Config.xml doesn't seem to contain anything
> relevant to the problem, and none of the .xml files in the themes
> directory have changed for several years, if at all.
>
> Can someone give me a list of files, if any, I can copy from Solo to
> Yoda to deal with this?
> There is no database on the frontends that I can find...is the config
> info for the frontends kept in the DB on the backend?
>
> Backend is also running v31 on 20.04.
>
> Scratching my head...any info would be appreciated. Thanks.
> --
>
> __________________________________
> Bob
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

I had exact same problem. Frontend would occasionally hesitate and die
or simply hang the machine to a point that I have to hard reset.

After some trying to debug for a while, I gave and installed debian 10
and installed myth v31 and it is working well so far.

Regards
Ramesh

Regards
Ramesh
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org