[mythtv-users] Getting slower

[DaveD]

On 8/18/20 3:01 PM, Stuart Auchterlonie wrote:
> On 18/08/2020 22:09, Stuart Auchterlonie wrote:
>> On 09/08/2020 05:12, DaveD wrote:
>>> On 8/2/20 4:00 PM, jam at tigger.ws wrote:
>>>> Over the last few releases mythtv has got slower to start and stop.
>>>> What is the delay looking for ipv6 dtuff?
>>>>
>>>> This trace is from my mac frontrnd, my linux frontend start is
>>>> similar, the stop takes 3 sec.
>>>>
>>>> If the issue is not my config should we not gently think about start
>>>> and stop times from a dev point of view?
>>>>
>>>> James
>>>>
>>>> 00.730068 I  Setup Interrupt: 2 handler
>>>> 00.730091 I  Setup Terminated: 15 handler
>>>> 00.730098 I  Setup Segmentation fault: 11 handler
>>>> 00.730104 I  Setup Abort trap: 6 handler
>>>> 00.730109 I  Setup Bus error: 10 handler
>>>> 00.730115 I  Setup Floating point exception: 8 handler
>>>> 00.730123 I  Setup Illegal instruction: 4 handler
>>>> 00.730130 I  Setup User defined signal 1: 30 handler
>>>> 00.730137 I  Setup User defined signal 2: 31 handler
>>>> .....
>>> I finally caught a slow startup (my wife usually has it started by the
>>> time I get to it) and here's the frontend output:
>>>
>>>> /usr/bin/mythfrontend --loglevel warning -O PowerOffTVOnExit=0 -O
>>> libCECEnabled=0 -geometry 1920x1080+1920+0
>>> qt.core.logging: Ignoring malformed logging rule: '’*.debug=false’'
>>> "Display: Requesting EGL for 'Mesa Project, 1.4'"
>>> 2020-08-08 20:44:32.526210 I [2264517/2264517] thread_unknown
>>> signalhandling.cpp:191:SetHandlerPrivate  Setup Interrupt handler
>>> 2020-08-08 20:44:32.526259 I [2264517/2264517] thread_unknown
>>> signalhandling.cpp:191:SetHandlerPrivate  Setup Terminated handler
>>> 2020-08-08 20:44:32.526288 I [2264517/2264517] thread_unknown
>>> ..... snip .....
>>> mediamonitor-unix.cpp:212:CheckMountable MMUnix:UDisks2 service found.
>>> Media Monitor does not support this yet!
>>>
>>> Same output, very different startup time.  What's the difference?
>>>
>> Right, I know what is going on here.
>>
>> The first time it starts up, it's trying to connect via DBus to the
>> service "org.freedesktop.UDisks" which fails to activate.
>>
>> "CheckMountable MMUnix:CheckMountable: DBus interface error: The name is
>> not activatable" <-- That's the error. Code is here [1]
>>
>> The second time through, DBus knows the service can't be activated
>> (or caches the result of the first time), and returns quickly with
>> the activation failure.
>>
>> Regarding these DBus endpoints. UDisks is so old, it's deprecation
>> notice now has mold on it. UDisks2 is newer, but nobody has been
>> sufficiently interested to write support for it.
>>
>> Anyway, I suspect that your system(s) still advertise UDisks via
>> DBus and it is trying this that takes the time. Please send the
>> output of the following command
>>
>> $ dbus-send --system --print-reply --dest=org.freedesktop.DBus
>> /org/freedesktop/DBus org.freedesktop.DBus.ListNames | grep
>> org.freedesktop.UDisks
>>
>> Regards
>> Stuart
>>
>> [1] -
>> https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmyth/mediamonitor-unix.cpp#L193
> Acutally, looking at
> https://code.mythtv.org/trac/ticket/12307#comment:11
>
> we weren't checking to see if the user had disabled
> the media monitor early enough, so it was still calling
> out to dbus.
>
> I've committed a fix to respect the user setting thereby
> bypassing this check at startup, and backported it to
> fixes/31. This should be in updated packages in the next
> 24hrs or so.
>
>
> Regards
> Stuart

This is very encouraging.  I hope you have it figured out.  That said, I 
don't know enough about dbus to fit your model into my experience.

I use a firewire to a cable box and that firewire interface is extremely 
fragile.  If the cable box gets turned off (remote in wrong mode!), I 
have to reboot to get mythbackend to get it's connection back where it 
can change channels again.  Some times I can pull and re-plug the 
firewire cable and restart mythbackend, sometimes I just need to restart 
mythbackend, sometimes I can unload the firewire module and re-modprobe 
it, etc, etc.  But I digress.

A week or so ago, I had to both turn off the power to my computer and 
unplug the cable box then fire it back up to re-establish the 
connection.  After that, mythfrontend started up every day with no 
delay; < 10 seconds from hitting the key on the remote to recordings 
list.  Every time.  Until it didn't.  No idea what changed to make it 
sluggish again, but it takes > 50 seconds, now.

What you said about dbus timing out the first time and not later does 
not quite fit the experience of it working, time after time, and then 
inexplicably stop working.  I'm wondering if there's something else I 
did to get the dbus daemon into a different state?  I think I'll try 
rebooting and get it working reliably again, then pay close attention to 
what I do to see if I can figure out what makes it change.

As I wrote this, it occurred to me that maybe the problem is the 
firewire connection being broken so I started mythfrontend, waiting 
nearly a minute for it to start, and then tried tuning a cable channel 
and, indeed, the connection had been lost.  After restarting 
mythbackend, the connection was re-established and mythfrontend started 
up normally.

So, it seems I have discovered the problem.  I don't understand why the 
lack of a connection of the backend to a cable box ("tuner") causes a 
slow startup of the frontend, but it seems that it certainly does.  It's 
actually a good thing as now I know that if it starts up slow, I need to 
restart the backend (at least) so it will be ready when needed (I have 
lost recordings due to the lack of connection).

It seems my  problem was not related to dbus nor was it related to media 
monitoring.  Others with slow startup will likely not be helped by my 
discovery, but it seems all hardware connections should be suspect.

If anyone knows of some way to programmatically check the firewire 
connection and, ideally, re-establish it programmatically, I would love 
to hear it.

Dave D.