Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prevent frontend from resurecting when the database is inaccessible #95

Merged
merged 1 commit into from
Jul 3, 2021
Merged

Prevent frontend from resurecting when the database is inaccessible #95

merged 1 commit into from
Jul 3, 2021

Conversation

ulmus-scott
Copy link
Contributor

I am using MythTV version 31 installed on Xubunutu 21.04 or 20.04 via the mythbuntu ppa.

When I launch the frontend without the backend running, it displays the loading bar, but when I try to exit, either before or after it times out, it thinks the frontend has crashed, so it relaunches. This obviously creates an inescapable loop, which is annoying.

Killing mythfrontend via xfce4-taskmanager does break the loop, but oddly mythfrontend.real doesn't show up in xfce4-taskmanager while gnome-system-monitor shows both.

Adding exit code 130 to the list in the script breaks the loop. Exit code 130 is GENERIC_EXIT_NO_MYTHCONTEXT (https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythbase/exitcodes.h ), which is a result of exiting the GUI startup screen (see mythcontext.cpp MythContextPrivate::FindDatabase() which returns false, causing MythContextPrivate::Init() to return false and thus MythContext::Init() to also return false, finally causing mythfontend to return 130 (https://github.com/MythTV/mythtv/blob/4eaa9cdbad0552d61f71a48019cbc6f9b1a14209/mythtv/programs/mythfrontend/main.cpp#L1896 )

GENERIC_EXIT_SOCKET_ERROR 135, may also need to be ignored based on its use in mythcontext.cpp.

Perhaps, abandoning the auto-restart entirely is a better option.

Alternatively, mythtv.desktop could be modified to call mythfrontend without the --service parameter.

MythTV version 31 is installed on Xubunutu 21.04 or 20.04 using the mythbuntu ppa.

When I launch the frontend without the backend running, it displays the loading bar, but when I try to exit, either before or after it times out, it thinks the frontend has crashed, so it relaunches. This obviously creates an inescapable loop, which is annoying.

Killing mythfrontend via xfce4-taskmanager does break the loop, but oddly mythfrontend.real doesn't show up in xfce4-taskmanager while gnome-system-monitor shows both.

Adding exit code 130 to the list in the script breaks the loop.  Exit code 130 is GENERIC_EXIT_NO_MYTHCONTEXT (https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythbase/exitcodes.h ), which is a result of exiting the GUI startup screen (see mythcontext.cpp MythContextPrivate::FindDatabase() which returns false, causing MythContextPrivate::Init() to return false and thus MythContext::Init() to also return false, finally causing mythfontend to return 130 (https://github.com/MythTV/mythtv/blob/4eaa9cdbad0552d61f71a48019cbc6f9b1a14209/mythtv/programs/mythfrontend/main.cpp#L1896 )

GENERIC_EXIT_SOCKET_ERROR 135, may also need to be ignored based on its use in mythcontext.cpp.

Perhaps, abandoning the auto-restart entirely is a better option.

Alternatively, mythtv.desktop could be modified to call mythfrontend without the --service parameter.
@superm1 superm1 merged commit bc160d0 into MythTV:master Jul 3, 2021
@ulmus-scott ulmus-scott deleted the patch-1 branch July 3, 2021 19:11
@ulmus-scott
Copy link
Contributor Author

@superm1 Could you also apply bc160d0 to fixes/31? It should cleanly apply back to at least 0.26, but only 31 is probably sufficient.

@superm1
Copy link
Member

superm1 commented Sep 26, 2021

@superm1 Could you also apply bc160d0 to fixes/31? It should cleanly apply back to at least 0.26, but only 31 is probably sufficient.

Go ahead and open a PR against the older branches and ping me on it and I will.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants