[mythtv-users] mythfrontend over vnc crashes

Leo Butler leo.butler81 at googlemail.com
Mon Mar 1 21:18:46 UTC 2021


Douglas Paul <doug at bogon.ca> writes:

> Hello,
>
> On Mon, Mar 01, 2021 at 07:57:25AM -0600, Leo Butler via mythtv-users wrote:
>> I upgraded my frontend and separate backend from ubuntu 18.04 to 20.04,
>> then upgraded myth from the .29 mythbuntu ppa to .31 (all due to the
>> pending changes involving the metadata grabbers).
>> 
>> The frontend and backend both work fine after the upgrade.
>> 
>> Before the upgrade, I was able to use vnc tunnelled over ssh to run
>> mythfrontend on the backend, too (I do most editing this way). Here is
>> the complete command to run the server:
>> 
>> [...]
>> 
>> The vncserver runs a fluxbox window manager.
>> 
>> After the upgrade, that no longer works even though mythfrontend works
>> on the backend (under the gnome desktop). It looks like a Qt-related
>> problem, but I am at a loss how to fix it.
>> 
>> Attached are stdout and stderr from
>> 
>> mythfrontend > m.log 2> m.err.txt
>> 
>> in a terminal inside the fluxbox-managed vnc session.
>
>> [...]
>> The X11 connection broke (error 4). Did the X11 server die?
>
> If it is of any use, I run the frontend routinely from a VNC desktop
> running Openbox. In my case, I am running TigerVNC not TightVNC. This is
> running in a VM (with no GPU access) on a server, also with no GPU.
>
> The frontend seems to run completely fine with software OpenGL.
>
> I am also running 0.32-pre, which hasn't been updated in a bit, so I
> don't know if something has been committed to both 0.31-fixes and
> 0.32-pre that could cause this problem, since I built, but I hope not. I
> would have no way to get hardware OpenGL on this machine...
>
> The error from X11 is EINTR, which means that the process should have
> received some signal when communicating to the X server. You could see
> which if you ran the frontend from a debugger.
>
> However, because of the error here, you might be able to see something
> else in the logs for VNC (usually in ~/.vnc/$DISPLAY.log). They might
> point to the origin of the problem. Maybe there is some bug in that
> particular VNC server.

Thanks. I tried a few things, but the only thing that seems to work at
the moment is running a gnome session on the server with x11vnc. I don't
like running such a resource hog, but ...

There are so many possible points of failure, that I will put a pin in
it for the moment and try again when I have more time.

Leo


More information about the mythtv-users mailing list