Call for tester for 1.4.0 features and fixes (1 Viewer)

[Scythe42]

Added Build #10:

Changes:

• added missing TVPlugin.dll
• increased number of initial thread pool worker threads.

New Known Issues:

• Powersheduler plugin might hang during "staring plugins" on the splash screen. Please let me know if this is the case for anyone of you, as I am not able to reproduce this regression at the moment.

Please post logs if you experience a noticeable faster startup time so I can gather values on thread waiting and thread execution time.

Beside that test stay the same as with build 9.

 

[megahorst]

I do have this delay everytime when my system comes from suspend. Is this a special behavior of my setup or "normal" behavior?
Do you think @Scythe42 that it is worth to optimize this?

Does this happen with stock MP, meaning no additional plugins activated as well?
Can you check if MP is controllable via keyboard beside the remote?
When removing the network folders, does the problem go away?
Happens when you are in a specific plugin or also on basic home?
Difference between using a network cable and Wifi?

Trying to limit things down here finding what's taking so long on your system / what's blocking MP.

I cannot reproduce this on my system. No unusual long delays after resuming from standby or hibernation specific to MP.

Logs don't really help here. Something is blocking MP that does not write to the logs for what it is waiting. Network related is a very good guess, though.

I have solved the issue for me some days ago:

Most delay came from the option 'file existence cache' after disabling this function in the GUI section of MePo configuration most of the delays where gone.
It seems to me that MePo is searching for the files within the network before the network interface is up and running after a suspend. I'm using a GBit LAN. This takes one or two seconds to negothiate again.

I have seen this looking for files on the network without network interface up and running also within the TV-server. I'm recording to a networkshare. From time to time the TV-server clears the recording table after resuming. It seems that it also looks for the files before the network is ready, It does not find them than and clears the table. I will try to capture this case and open a new thread regarding this issue.

The music searching delay is only when I came back from suspend on basic home. It is the latest media handler that delays resuming there. Perhaps @cul8er should have a look at this. From my point of view the latestmediahandler should not refresh after the resuming of the htpc.

 

[tourettes]

From my point of view the latestmediahandler should not refresh after the resuming of the htpc.

And when ever it does a refresh it really should do it in a worker thread instead of blocking MP's main thread. @cul8er, could you make such change in the future plugin versions?

 

[Lightning303]

Also I noticed that not a lot of worker threads are available on your system. MP can use four worker threads for all the plugins on your system. Let me guess: two core CPU, right?

Thats right. My system specs are in my profile and up to date if you need more infos .

That's a good default, unless you have a ton of background tasks!

I do have some background tasks running, however they should be idleing. i am also connected in via rdp as a second user.

Can you check your CPU/IO usage during startup please?

How do you want me to do that? Is there a tool that i can run and that produces logs for you, or should i just eyeball the task manager graphs?

When I use 32 threads instead of the default 8 on my system, plugin loading takes 1.3 instead of 1.4 seconds.

I tried build 10, which, as i understand it has more worker threads, however it did not give me any noticeable speed improvements. still around 20secs for the whole startup of mp. I attached logs for you.

I might be too optimistic here, but by just reducing the wait time it should be possible to get you < 10 seconds.

my fingers are crossed .

Also also did some tests regarding half/fullscreen. everything works perfectly now for that. doesnt matter what i turn off or on, or change, mp is always in fullscreen and responsive. Nice work, thanks.
Refresh Rate Change does work flawless for me aswell, no minimizing.
Havent found any other problems yet.

 

[Scythe42]

Breakdown of Startup on your system:

• Initializing Various Stuff: 1 second
• Loading Fonts: 0.2 seconds
• Loading WindowPlugins.dll and doing related stuff: 2.3 seconds (1.5 seconds wasted on Texture Packer alone - was it the first start, so it re-created the texture atlas?)
• Loading Window Plugins: 7.8 seconds (three worst plugins)
  • Moving Pictures: 5.3 seconds
  • Titan Skin Updater: 5.7 seconds - what the heck does it do?)
  • TV Seriens: 7.5 seconds
• Other Startup stuff: 1.2 seconds
• Loading Process Plugins: 0.4 seconds
• Starting Plugins: 6 seconds (roughly how long FanartHandler and LatestMediaHandler need)
• Rest of Startup Sequence: 0.6 seconds

So the speed we gained so far is coming from having Moving Pictures and TV Series run in parallel.

The thread waiting times are way better now but still the longest running thread determines when each step is finished. So you don't really see the speed gain.

As Moving Pictures and TV Series are not core MP components, not much I can do here.

Also what the heck is the TitanSkinUpdater doing that long? Not good. @ncoH: can you explain what is taking so long?

In could try to parallel the window plugin loading/starting and the process plugin loading/starting. Do not know if this works out. I assume there is a reason for starting process plugins that late.

Whatever takes so long for Moving Pictures, TV Series, FanartHander and Latest Media Handler needs to be checked with the developers of these plugins. They have some stuff in it that takes ages on your system and can be optimized for sure.

I guess the long times come from IO. Probably some stuff over the network is involved here? I assume stuff could be run parallel on startup in these plugins instead of sequential.

 

[tourettes]

Also what the heck is the TitanSkinUpdater doing that long? Not good. @ncoH: can you explain what is taking so long?

My wild guess would be that it does the online update check in the init phase in MP main thread

Whatever takes so long for Moving Pictures, TV Series, FanartHander and Latest Media Handler needs to be checked with the developers of these plugins. They have some stuff in it that takes ages on your system and can be optimized for sure.

Do we even need to load the plugins before main menu is shown? Plugin needs to be ready (at least pure UI plugin) when it is first accessed - so it would be enough in many cases to have the wait done (if needed) in case when the user accesses the plugin for the 1st time (of course the loading would be done already in the background right after the startup).

Do we have plugins that depend on each other? Such could give some nasty random bugs when threading the loading.

 

[Lightning303]

was it the first start, so it re-created the texture atlas?

Nope, first start took way longer, so i threw that out.

Probably some stuff over the network is involved here?

Nope, no network drives or such as these. Everything mediaportal related is stored on my ssd, videos and stuff are stored on internal drives.

 

[Scythe42]

My wild guess would be that it does the online update check in the init phase in MP main thread

Sure but why does it take so long to start it? It writes tons of log lines. Must be more than a simple check if something new is available.

Do we even need to load the plugins before main menu is shown? Plugin needs to be ready (at least pure UI plugin) when it is first accessed - so it would be enough in many cases to have the wait done (if needed) in case when the user accesses the plugin for the 1st time (of course the loading would be done already in the background right after the startup).

Not going to change the WindowManager and the Plugin Architecture here. Just working on the PluginManager itself as it is nicely isolated.

It is up to the plugin developer in the end. For example loading the TV Series database can be done in a thread in the background once the plugin is started. Should the plugin be accessed while the DB and other stuff is not yet loaded it could display a GUIWaitCursor/Some Window/Whatever.

Do we have plugins that depend on each other? Such could give some nasty random bugs when threading the loading.

The current code does not check for dependencies. The only thing it does is loading processplugin.dll before all other process plugins of course. The load order itself is just how they are found in the directory. So there seems to be no dependency in the loading/starting order. Proper function later on is a different story.

Will try out of I can load window plugins/process plugins in parallel. That should gain a couple of more seconds instead of waiting LatestMediaHandler/FanArtHandler to complete their startup sequence.

 

[mbuzina]

I tried you v10 on my attic client, it seems to work when I use debug mode, but starting MP in full mode does seem to hang MP (it is running for almost 10 minutes now, still shows Loading Windows Plugins and last log entry was minutes ago). Logs from my tests:
1st: Successful without plugins
2nd: Aborted after ~10 minutes with all plugins

 

[tourettes]

Not going to change the WindowManager and the Plugin Architecture here. Just working on the PluginManager itself as it is nicely isolated.

It is up to the plugin developer in the end. For example loading the TV Series database can be done in a thread in the background once the plugin is started. Should the plugin be accessed while the DB and other stuff is not yet loaded it could display a GUIWaitCursor/Some Window/Whatever.

Sounds good approach, much safer. We really need to get the 3rd party plugin developers to see the slow startup issue as an important one.

Will try out of I can load window plugins/process plugins in parallel. That should gain a couple of more seconds instead of waiting LatestMediaHandler/FanArtHandler to complete their startup sequence.

In worst case we have some process and UI plugin dependencies that could cause havoc after such optimization. Maybe it is not worth the risk (test for sure it is ).