[Solved] mythtv-setup freezes upon launching

Have a MythTV related problem? Ask for help from other MythTV users here.

Moderator: Forum Moderators

User avatar
kmdewaal
Developer
Posts: 640
Joined: Wed Dec 07, 2016 8:01 pm
Netherlands

Re: mythtv-setup freezes upon launching

Post by kmdewaal »

And now it looks like I can somewhat reproduce this, using the 3rd database version.
I have changed the host name in the database tables storagegroup, program, recorded, capturecard and settings to the host name of my system and created the /var/lib/mythtv/.... storage group directories.
Now mythtv-setup starts OK. Alt-tab to other screen, then Alt-tab back to mythtv-setup and then it is not responsive anymore to the arrow keys; often Escape does cause an exit but not always.
The DB Error (StorageGroup::StorageGroup()) in the beginning is also present.
Note: this is now with a recent master.
With the v31 mythtv-setup there is a segfault in LibCecInitialise which looks similar to a bug I fixed a while ago.
User avatar
kmdewaal
Developer
Posts: 640
Joined: Wed Dec 07, 2016 8:01 pm
Netherlands

Re: mythtv-setup freezes upon launching

Post by kmdewaal »

The LibCecInitialize bug was fixed only in master, not in v31.See commit e787645fd974bbed6b02ed45ae3530477bb49c58.
This bug happened sometimes when mythfrontend was connected to a monitor or a TV that does not support CEC.
User avatar
bill6502
Developer
Posts: 2299
Joined: Fri Feb 07, 2014 5:28 pm
United States of America

Re: mythtv-setup freezes upon launching

Post by bill6502 »

Would myhtv-setup.real --override-setting libCECEnabled=0 help?
ulmus-scott
Junior
Posts: 41
Joined: Sat Jun 05, 2021 12:50 am
United States of America

Re: mythtv-setup freezes upon launching

Post by ulmus-scott »

bill6502:
Would myhtv-setup.real --override-setting libCECEnabled=0 help?
libcec is not installed, so there is no difference.

Code: Select all

htpc@htpc-HP:~$ mythtv-setup.real -v most,norefcount --loglevel=debug > mythtv-setup-12-2021-06-09T1834.log 2>&1
htpc@htpc-HP:~$ mythtv-setup.real -v most,norefcount --loglevel=debug --override-setting libCECEnabled=0 > mythtv-setup-13-2021-06-09T1836.log 2>&1

log 12:
libcec.so.6: cannot open shared object file: No such file or directory
E  CECAdapter: Failed to load libcec.
becomes
log 13:
I  CECAdapter: libCEC support is disabled.
User avatar
kmdewaal
Developer
Posts: 640
Joined: Wed Dec 07, 2016 8:01 pm
Netherlands

Re: mythtv-setup freezes upon launching

Post by kmdewaal »

About the DB Error (StorageGroup::StorageGroup()) in the beginning of the log file.
This error is caused by the setting StartupScreenDelay.
This can be set in the mythfrontend configuration menu "Theme/Screen settings" and this is the help text:
The Startup Screen will show the progress of starting the frontend if frontend startup takes longer than this number of seconds.
If this setting is not present in the settings table then a time of 2 seconds is used as default.
However, the setting is present in the database with value 0 and this is then the value used.
I have not completely followed the logic but this value causes the first database access to fail with the "Driver not loaded" status.
In mythtv-setup the first access tries to find directories for storage group "Themes" and this will thus always fail if the StartupScreenDelay setting is 0.

I do not have a clue if this is related to the "mythtv-setup freezes" problem but you can always try.
You can either set the value with mythfrontend, set the value with mysql or delete the setting, also with mysql.
Setting the value with mysql can be done like this:

Code: Select all

MariaDB [mythconverg]> update settings set data='2' where value='StartupScreenDelay';
User avatar
kmdewaal
Developer
Posts: 640
Joined: Wed Dec 07, 2016 8:01 pm
Netherlands

Re: mythtv-setup freezes upon launching

Post by kmdewaal »

The first database does NOT have the StartupScreenDelay setting so a value of 2 seconds will be used.
The second and the third databases do have a StartupScreenDelay setting of 0.
ulmus-scott
Junior
Posts: 41
Joined: Sat Jun 05, 2021 12:50 am
United States of America

Re: mythtv-setup freezes upon launching

Post by ulmus-scott »

kmdewaal:
About the DB Error (StorageGroup::StorageGroup()) in the beginning of the log file.
This error is caused by the setting StartupScreenDelay.
Does the backend use a 2s delay regardless of the setting? Looking at the backend logs it always shows:

Code: Select all

I  Start up testing connections. DB localhost, BE , attempt 0, status dbAwake, Delay: 2000
The StartupScreenDelay setting does seem to be causing the issue I'm having.


I changed the setting in the frontend to 2 (backend-4, frontend-3). I then closed and relaunched the frontend (frontend-4). Upon running mythtv-setup (log 14), it worked properly.

I changed the setting to 0 using mysql, ran mythtv-setup (log 15), and it still worked fine. The log still shows a delay of 2000 (ms) and no error.

Code: Select all

I  Start up testing connections. DB localhost, BE , attempt 0, status dbAwake, Delay: 2000
After resetting the setting to 0 in the frontend (increased to 2, saved, and then set back to 0) (backend-5, frontend-5), I ran mythtv-setup (logs 16 and 17); it was frozen.

I set the setting to 2 in the frontend (backend-6, frontend-6), and ran mythtv-setup (log 18); it works properly.

I set the setting to 0 in the frontend (backend-7, frontend-7), and ran mythtv-setup (log 19); it was frozen, showing a grayed out menu.

I changed the setting to 2 using mysql, ran mythtv-setup (log 20), and it works fine. However, the log still shows a delay of 0 and the error. I think the progress bar did flash.
I ran mythtv-setup (log 21) again; it works fine, showing a delay of 2000 and no error in the log and no progress bar.

After changing the setting to 0 using mysql, I ran mythtv-setup (log 22); it works fine, but shows no progress bar and the log still shows a delay of 2000 and no error.
Running mythtv-setup (log 23) again, it was frozen on a grayed out menu, showed the progress bar and a delay of 0 and the error in the log.

Oddly, the changes via mysql seem to take two runs of mythtv-setup to propagate fully, while the change via the frontend affects the next run of mythtv-setup.


I reset StartupScreenDelay on the other machine to 2 in the frontend, and mythtv-setup works without issue.

I had set StartupScreenDelay to 0 because the frontend can take some time to launch, so it can easily be launched multiple times (using a shortcut on the desktop). Also, I don't think the 2 seconds delay was accurate (admittedly, I never timed it and it is not a critical delay). I liked it showing a screen instantly, letting you know it has been launched and is loading. (Although, the progress bar only ever showed a thin sliver filled on the left, unless the backend was not running.) Since it works fine with the delay, I can use it like that, but it is strange that it has other affects than just showing a progress bar.
User avatar
kmdewaal
Developer
Posts: 640
Joined: Wed Dec 07, 2016 8:01 pm
Netherlands

Re: mythtv-setup freezes upon launching

Post by kmdewaal »

OK, so this
The StartupScreenDelay setting does seem to be causing the issue I'm having.
does mean that the problem is solved by setting a value of 2. The lowest value is 1 second and that also works for me.
Does the backend use a 2s delay regardless of the setting?
The backend is a command line application without a GUI so it is correct that it does not look at the StartupScreenDelay setting.
Oddly, the changes via mysql seem to take two runs of mythtv-setup to propagate fully, while the change via the frontend affects the next run of mythtv-setup.
I found in the code this in mythcontext.cpp:1474 this reference:

Code: Select all

cache/contextcache.xml
which, if I understand the code correct, caches a few settings including the StartupScreenDelay and uses that initially. This must be what causes the propagation delay.

I do agree that this is a bug. What seems to happen is that the StartupScreenDelay is used as the timeout value for the very first SQL query and when this is zero the first SQL query fails. If this can be easily fixed then I will do that and otherwise I will create a Github issue.
For the time being I suggest to use a StartupScreenDelay setting of 1 or more.

Thanks for the reports and the extensive testing!
User avatar
kmdewaal
Developer
Posts: 640
Joined: Wed Dec 07, 2016 8:01 pm
Netherlands

Re: mythtv-setup freezes upon launching

Post by kmdewaal »

mythtv-setup-2.log
CODE: SELECT ALL

2021-06-07 00:29:44.690652 I ScreenSaverX11Private: DPMS is disabled.
2021-06-07 00:29:44.783345 E DB Error (StorageGroup::StorageGroup()):
Query was:

Driver error was [1/]:
Driver not loaded
Database error was:
Driver not loaded
This is not good what caused the DB to go away?
With the StartupScreenDelay setting of 0 immediately the TempMainWindow is shown instead of waiting a few seconds until there is a database connection and the real main window can be shown. The TempMainWindow code (mythcontext.cpp:278) calls SilenceDBErrors() (mythcontext.cpp:1094) and this one clears the hostname which then intentionally causes the next database access to fail, giving the error message quoted here. So the DB did not go away, it was never there.

This is how it is described in the code:

Code: Select all

/**
 * Cause MSqlDatabase::OpenDatabase() and MSqlQuery to fail silently.
 *
 * This is used when the DB host address is bad, is non-routable,
 * the passwords are bad, or the DB has some other problem.
 *
 * It prevents hundreds of long TCP/IP timeouts or DB connect errors.
 */
So really everything is correct with a StartupScreenDelay setting of at least one second.

The reason given for using a StartupScreenDelay of 0 seconds is to have something on the screen as quick as possible. This is something I can understand but in my tests it does not take significantly longer to display the real main window than what it takes to display the TempMainWindow.
The only fix I think about for this is to set the minimum value for StartupScreenDelay to 1 second, thus avoiding the issue completely.

On a side note, when investigating this I found a bug in reading the value of StartupScreenDelay from the database. The database value is in seconds and this needs to be converted to milliseconds, but this conversion was done incorrect in master. This code was still correct in v31 so it cannot have been of influence here. For those interested, see commit 0fd4b0ec6e6ce8ab18fe63af561cf27b45f94525.

A second bug found is that it is possible to crash mythtv-setup, and probably also mythfrontend, using the following sequence:
- set StartupScreenDelay to 0 with a mysql command
- start mythtv-setup; this is OK.
- set StartupScreenDelay to 2 with a mysql command
- start mythtv-setup; now it segfaults.
Root cause of this is related to a difference between the cached database settings and the corresponding real database settings; when there is a difference some additional actions are taken, causing the crash. As I understand it, when changing the StartupScreenDelay setting via the mythfrontend menu both the database value and the cached value are updated so this problem should not happen.
Manually changing database values is not supported but mythtv-setup should never crash so I intend to add an if to prevent this crash.
User avatar
paulh
Developer
Posts: 909
Joined: Thu Feb 06, 2014 6:09 pm
Great Britain

Re: mythtv-setup freezes upon launching

Post by paulh »

Just for reference. Peter added the StartupScreenDelay at my request because he changed something that was causing the setup screen to always be shown when the FE started. It was driving me and my users nuts because we found it so irritating. Each time the FE started up there would be a flash of the setup screen then the real FE would then show. It was incredibly annoying :evil: So Peter kindly added that setting so you can delay showing it. It really should only be shown when there is a real connection problem not every time the FE starts IMHO.
ulmus-scott
Junior
Posts: 41
Joined: Sat Jun 05, 2021 12:50 am
United States of America

Re: mythtv-setup freezes upon launching

Post by ulmus-scott »

kmdewaal:
The reason given for using a StartupScreenDelay of 0 seconds is to have something on the screen as quick as possible. This is something I can understand but in my tests it does not take significantly longer to display the real main window than what it takes to display the TempMainWindow.
I just timed the startup with a stop watch from hitting enter on the desktop shortcut to the frontend being open.

StartupScreenDelay set to 1 or 2: 4.5 to 5.5 seconds until the frontend is open. It never shows the loading screen.

StartupScreenDelay set to 0: within 750 ms the loading screen is displayed. The same 4.5 to 5.5 seconds after hitting enter, the frontend is open. N.B. the progress bar never moves and is always barely filled in.

So I guess the setting is not working properly, which is possibly separate from freezing mythtv-setup.
On a side note, when investigating this I found a bug in reading the value of StartupScreenDelay from the database. The database value is in seconds and this needs to be converted to milliseconds, but this conversion was done incorrect in master. This code was still correct in v31 so it cannot have been of influence here. For those interested, see commit 0fd4b0ec6e6ce8ab18fe63af561cf27b45f94525.
Just a suggestion, but wouldn't it make more sense to have the setting actually be in milliseconds? (Or tenths of a second if you feel that resolution is too fine [setting via arrow keys in frontend].) This value is an integer, right?
A second bug found ...
Root cause of this is related to a difference between the cached database settings and the corresponding real database settings; when there is a difference some additional actions are taken, causing the crash. As I understand it, when changing the StartupScreenDelay setting via the mythfrontend menu both the database value and the cached value are updated so this problem should not happen.
Changing the setting causes the frontend to restart, which I assume would make both the database value and the cached value the same.

paulh:
Each time the FE started up there would be a flash of the setup screen then the real FE would then show. It was incredibly annoying :evil: So Peter kindly added that setting so you can delay showing it. It really should only be shown when there is a real connection problem not every time the FE starts IMHO.
That does sound annoying, but that is not my experience given the 4.5 to 5.5 second delay until the frontend is open. There is a brief (<100 ms?) dance it plays with the panel as the frontend opens, but it is not annoying. (It flashes between being highlighted and not in the panel before hiding the panel since the frontend is fullscreen.)


As an aside, 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. I haven't done this recently (only when first setting up if I remember correctly) so I don't remember if I could exit the loop via the task manager. This is probably due to how mythfrontend is packaged on Ubuntu, i.e. mythfrontend is a script that calls mythfrontend.real and the default .desktop file calls the script with --service.

Edit:
Yep, that is a packaging bug. Adding exit code 130 to the list in the script breaks the loop. So should I create a new thread about that? Or who should I contact about that? (I'm using the mythbuntu ppa.) What does exit code 130 mean?

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

Edit 2:
kmdewaal wrote: The only fix I think about for this is to set the minimum value for StartupScreenDelay to 1 second, thus avoiding the issue completely.
That would just ignore the issue and not fix the root cause of the mythtv-setup freeze. Although as a workaround band-aid, forcing mythtv-setup to use a non-0 delay would probably work.


For reference, mythtv-setup logs and StartupScreenDelay values:

Code: Select all

cached  db     result            log delay & error  progress bar         log        
     2     2      works             2000, no error     no                   18, 21     
     0     0      frozen            0, error           yes                  19, 23     
     0     2      works             0, error           may have flashed     20         
     2     0      identical to 2,2                                          22         
Delay between first db connection attempt and connection (seconds):

Code: Select all

log         18      20
attempt     45.95   53.77
found       46.46   55.30
dt          0.51    1.53

kmdewaal wrote: The TempMainWindow code (mythcontext.cpp:278) calls SilenceDBErrors() (mythcontext.cpp:1094) and this one clears the hostname which then intentionally causes the next database access to fail, giving the error message quoted here. So the DB did not go away, it was never there.
mythcontext.cpp:1085

Code: Select all

/**
 * Cause MSqlDatabase::OpenDatabase() and MSqlQuery to fail silently.
 *
 * This is used when the DB host address is bad, is non-routable,
 * the passwords are bad, or the DB has some other problem.
 *
 * It prevents hundreds of long TCP/IP timeouts or DB connect errors.
 */
void MythContextPrivate::SilenceDBerrors(void)
{
    // This silences any DB errors from Get*Setting(),
    // (which is the vast majority of them)
    gCoreContext->GetDB()->SetSuppressDBMessages(true);

    // Save the configured hostname, so that we can
    // still display it in the DatabaseSettings screens
    if (!m_dbParams.m_dbHostName.isEmpty())
        m_dbHostCp = m_dbParams.m_dbHostName;

    m_dbParams.m_dbHostName.clear();
    gCoreContext->GetDB()->SetDatabaseParams(m_dbParams);
}

void MythContextPrivate::EnableDBerrors(void)
{
    // Restore (possibly) blanked hostname
    if (m_dbParams.m_dbHostName.isNull() && !m_dbHostCp.isEmpty())
    {
        m_dbParams.m_dbHostName = m_dbHostCp;
        gCoreContext->GetDB()->SetDatabaseParams(m_dbParams);
    }

    gCoreContext->GetDB()->SetSuppressDBMessages(false);
}
mythcontext.cpp:803

Code: Select all

/**
 * Some quick sanity checks before opening a database connection
 *
 * \todo  Rationalise the WOL stuff. We should have one method to wake BEs
 */
QString MythContextPrivate::TestDBconnection(bool prompt)
{
    QString err;
    QString host;

    // Jan 20, 2017
    // Changed to use port check instead of ping

    int port = 0;

    // 1 = db awake, 2 = db listening, 3 = db connects,
    // 4 = backend awake, 5 = backend listening
    // 9 = all ok, 10 = quit

    enum  startupStates {
        st_start = 0,
        st_dbAwake = 1,
        st_dbStarted = 2,
        st_dbConnects = 3,
        st_beWOL = 4,
        st_beAwake = 5,
        st_success = 6
    } startupState = st_start;

    static const std::array<const QString,7> kGuiStatuses
        {"start","dbAwake","dbStarted","dbConnects","beWOL","beAwake",
            "success" };

    auto msStartupScreenDelay =
        gCoreContext->GetDurSetting<std::chrono::milliseconds>("StartupScreenDelay",2s);
    do
    {
        QElapsedTimer timer;
        timer.start();
        if (m_dbParams.m_dbHostName.isNull() && !m_dbHostCp.isEmpty())
            host = m_dbHostCp;
        else
            host = m_dbParams.m_dbHostName;
        port = m_dbParams.m_dbPort;
        if (port == 0)
            port = 3306;
        std::chrono::seconds wakeupTime = 3s;
        int attempts = 11;
        if (m_dbParams.m_wolEnabled) {
            wakeupTime = m_dbParams.m_wolReconnect;
            attempts = m_dbParams.m_wolRetry + 1;
            startupState = st_start;
        }
        else
            startupState = st_dbAwake;
        if (attempts < 6)
            attempts = 6;
        if (!prompt)
            attempts=1;
        if (wakeupTime < 5s)
            wakeupTime = 5s;

        std::chrono::seconds progressTotal = wakeupTime * attempts;

        if (m_guiStartup && !m_guiStartup->m_Exit)
            m_guiStartup->setTotal(progressTotal);

        QString beWOLCmd = QString();
        QString backendIP = QString();
        int backendPort = 0;
        QString masterserver;

        for (int attempt = 0;
            attempt < attempts && startupState != st_success;
            ++attempt)
        {
            // The first time do everything with minimum timeout and
            // no GUI, for the normal case where all is OK
            // After that show the GUI (if this is a GUI program)

            LOG(VB_GENERAL, LOG_INFO,
                 QString("Start up testing connections. DB %1, BE %2, attempt %3, status %4, Delay: %5")
                      .arg(host).arg(backendIP).arg(attempt).arg(kGuiStatuses[startupState])
                      .arg(msStartupScreenDelay.count()) );
...
I looked at mythcontext.cpp, which, frankly, seems messy. (Granted, I have never written code for a large, complex project or been involved in a multi-year code development.)

I don't understand the point of m_dbHostCp and clearing m_dbParams.m_dbHostName because:
  1. The only time m_dbHostCp is used (line 842), it is to set m_dbParams.m_dbHostName if it is cleared. Although, it is a public variable, so it may be used in other files.
  2. m_dbParams.m_dbHostName is set by other methods every other time it is used.
  3. Clearing m_dbParams.m_dbHostName does not seem like it would be involved in silencing DB errors. I do not see the logic in that.
If you want to cause a DB access to fail, for whatever reason, then doesn't it make more sense to clear the hostname, make an impossible access, and restore the hostname all in the same function?

The log statement

Code: Select all

Start up testing connections. DB localhost, BE , attempt 0, status dbAwake, Delay: 2000
is from mythcontext.cpp:883. The startupStates are poorly named, from my first cursory glance, I thought status dbAwake ment that it already knew something about the database, but it means nothing.

I need to read the entire TestDBconnection function more closely, since it appears the log should show multiple connection attempts, but there is always only one
User avatar
kmdewaal
Developer
Posts: 640
Joined: Wed Dec 07, 2016 8:01 pm
Netherlands

Re: mythtv-setup freezes upon launching

Post by kmdewaal »

I do enjoy reading your analysis. Please do continue and before you know it you are the expert on this part of the code!
My contributions to mythtv are mainly limited to channel scanning and mythtv-setup and therefore I triggered on your problem, "mythtv -setup freezes upon launching". Note that this is something I have not been able to reproduce. I suspect it could be something in the video playback / UI code that causes this, in combination with compositing window managers and Wayland vs X11, but that is largely uncharted territory for me.
User avatar
kmdewaal
Developer
Posts: 640
Joined: Wed Dec 07, 2016 8:01 pm
Netherlands

Re: mythtv-setup freezes upon launching

Post by kmdewaal »

It could just be that mythtv-setup works correct, also with a StartupScreenDelay of 0, when started like this:

Code: Select all

mythtv-setup -platform xcb
ulmus-scott
Junior
Posts: 41
Joined: Sat Jun 05, 2021 12:50 am
United States of America

Re: mythtv-setup freezes upon launching

Post by ulmus-scott »

Testing is now on host htpc since I transferred the hard drive to htpc-HP.

Code: Select all

mythtv-setup.real -O platform=xcb -v most,norefcount --loglevel=debug > mythtv-setup-26.log 2>&1
I can see the setting overridden in the log (26, 25 for reference without platform=xcb), but there is no change. It still froze.

mysql for my reference:

Code: Select all

UPDATE settings SET data = 2 WHERE value = 'StartupScreenDelay';
UPDATE settings SET data = 0 WHERE value = 'StartupScreenDelay';
SELECT * FROM settings WHERE value = 'StartupScreenDelay';

mythtv-setup.real -v most,norefcount --loglevel=debug > mythtv-setup-27.log 2>&1

Code: Select all

cached  db     result            log delay & error  progress bar         log        
     2     2      works             2000, no error     no                   18, 21     
     0     0      frozen            0, error           yes                  19, 23     
     0     2      works             0, error           may have flashed     20         
     2     0      identical to 2,2                                          22         
Based on my table of cached and db values: this seems to imply that the freeze occurs after database connection. If it reads a db value of 2 it works, but it also works with a cached value of 2 and a db value of 0. Hmm, is it taking different code paths based on the cached value, i.e not using the db value since the cached value ≠ 0? I revalidated that cached 2 and db 0 works (log 27) and 0, 0 doesn’t (log 28).


For easier debugging can the log print the file and line number that creates that entry? Because right now it is not obvious at all where the log entries come from. Ideally the file name would also include the path in the github repository.

Can the font logs be disabled?

ulmus-scott wrote: I don't understand the point of m_dbHostCp and clearing m_dbParams.m_dbHostName because:
  1. The only time m_dbHostCp is used (line 842), it is to set m_dbParams.m_dbHostName if it is cleared. Although, it is a public variable, so it may be used in other files.
  2. m_dbParams.m_dbHostName is set by other methods every other time it is used.
  3. Clearing m_dbParams.m_dbHostName does not seem like it would be involved in silencing DB errors. I do not see the logic in that.
If you want to cause a DB access to fail, for whatever reason, then doesn't it make more sense to clear the hostname, make an impossible access, and restore the hostname all in the same function?
My concern about it being a public variable is unfounded since the class MythContextPrivate is a "private class" inaccessible from outside mythcontext.cpp.
ulmus-scott
Junior
Posts: 41
Joined: Sat Jun 05, 2021 12:50 am
United States of America

Re: mythtv-setup freezes upon launching

Post by ulmus-scott »

In my ongoing detour down mythcontext.cpp lane:
git blame says the root of all evil is: … NigelPearson (… in 2007-2008)

Remove MCP::FixSettingsFile(), which was only called from one place, · MythTV/mythtv@a7171b3 · GitHub
[a7171b3c108ca62e8a54507ea26a3f6de5707d84]

New, slightly improved, UPnP autodiscovery. See #4075. · MythTV/mythtv@4e47a1a · GitHub
[4e47a1a7d0efd0bd976b7817edd8e8f0d78a57ce]

Fix a few very broken QString conversions, tidy the Database silencin… · MythTV/mythtv@7684161 · GitHub
[7684161a87a1bce9b0c4fb252a5a8049e6bf7c65]

1) Eliminate bootstrap errors from GetSetting() - there is now exactl… · MythTV/mythtv@65b4148 · GitHub
[65b4148c3e7d4faa033313d8a20aaeda15ea4788]

Tidy the "error reduction while DB bootstrapping" hacks: · MythTV/mythtv@760ff9a · GitHub
[760ff9a1bfc5831c09982c9f232faeb962ca3f6c]

Use SetSuppressDBMessages() instead if IgnoreDatabase() to prevent th… · MythTV/mythtv@88c641a · GitHub
[88c641ac88bec2d0c4f8cdf8a133d10e23b3edd4]

Silence and Enable DB errors functions are poorly named. Initially they only cleared or restored the db host name, respectively. It is still clear as mud why this is done.


bennettpeter
mythfrontend: Add startup screen delay or suppress option in setup · MythTV/mythtv@9d17a64 · GitHub
[9d17a64ffde3c586e7c3bbf27a0acfb62000702e]

The comments imply this should only effect the frontend, but it doesn’t.

Would it be possible to instead create a “global” timer (i.e. a class member and not in a function) that after it has expired fires an interrupt to determine if the gui is started?

e.g. in MythContextPrivate::Init

Code: Select all

if(gui) {
    // current stuff
    m_timer = new countDownTimer(auto msStartupScreenDelay =
        gCoreContext→GetDurSetting<std::chrono::milliseconds>("StartupScreenDelay",2s)); // copied lines 836 and 837
}

in class  countDownTimer 
   on expiration {
       // do something, probably with a function pointer
    }
or maybe call a function screenDelay in init instead

Code: Select all

void screenDelay(some kind of duration) {
    return fork(); // create a new thread, old thread returns to calling location
    
    sleep(duration); // new thread sleeps while old thread continues execution
    
    if (!gui_exists()) {
        // create temporary gui, e.g. copied from lines 896-898
        ShowGuiStartup();
            if (m_guiStartup)
                m_guiStartup->setTotal(progressTotal);
    }
    return; // explicit return, or kill new thread (or something like that)
}
If the logic behind my second method is sound, that is probably easier (and maybe cleaner, but I don’t have any experience with multithreaded or real-time programming).

The behavior I am proposing seems to be more in line with the idea of a splash screen than the current behavior, which only cares if the database has connected, not if a GUI is visible.
Post Reply