mp slower startup after update to 1.6 (2 Viewers)

[mhoogenbosch]

Okay. So I went from 38 seconds to 24 ony by disabling the sleepcontrol plugin and adding av exceptions.
We know my hardware is allright (good to know ).
We know MePo starts with Aqua8 in 11 seconds when all plugins are disabled. So all plugins combined are good for 13 seconds.

Is there still somting left to try and improve this, of is is a thing I just have to live with. I was under the impression ive read somewhere the plugins get started parallel, so all plugins are started at the same time. But can't seem to find the source of this.

 

[Miwer]

Hi,

Maybe I can bring something to the table in this bug report.

I'm not sure if it's related to what the OP is experiencing, but I found that the startup time issue can be influenced by messing with the log file (C:\ProgramData\Team MediaPortal\MediaPortal\log\MediaPortal.log)

I noticed (by accident), that if I deleted the MediaPortal.log file, my startup time dropped dramatically (from 50 seconds to 20 seconds total).
So I started timing the startups with a stop watch, and to my big surprise, I found that every subsequent startup, it would take aproximately 3 seconds longer to load window plugins, than the previous startup.

I can reproduce this every time:

-------------------------------------
Start by deleting MediaPortal.log

(MP start attempt - time "loading window plugins" in seconds - log size after closing MP)
1st - 12,5 - 80K
2nd - 15,5 - 160K
3rd - 18,5 - 240K
4th - 21,7 - 320K
5th - 25,1 - 400K
6th - 28,0 - 480K
7th - 31,7 - 560K
8th - 34,8 - 640K
9th - 38,1 - 720K
10th - 42,1 - 800K
11th - 44,5 - 880K
12th - 48,6 - 960K
13th - 51,5 - 1040K
14th - 55,0 - 1120K
15th - 58,3 - 1200K
16th - 61,2 - 1281K
17th - 64,3 - 1361K
18th - 67,9 - 1441K
19th - 70,5 - 1521K
20th - 73,5 - 1601K
... and you'll get the picture, and I stopped testing further

Deleting the MediaPortal.log again and it starts over, beginning with 12,5 seconds loading time.
-------------------------------------

I'm attaching a full log of all 20 start attempts.

The timings above and the attached log was done with all my 3rd party plugins enabled, but I did of course test this with plugins disabled, and Titan Updater configs disabled, and the problem is the same. IPv6 is also disabled.

So, can anyone confirm this?

 

[mm1352000]

@Miwer
I expect the reason for this behaviour is that you have security software scanning the MP log folder:
https://forum.team-mediaportal.com/threads/mediaportal-vs-microsoft-security-essentials.124689/

 

[cwchapma]

It sounds like the problem might be that the logging is continually opening and closing the file. I wonder how hard it would be to keep the log file open?

http://stackoverflow.com/questions/14903606/add-exception-to-windows-defender-at-install-time

Or maybe the log file needs to be split smaller than 5MB?

There has to be a way to do logging with Windows 8 default install without slowing down the startup time by 1000%. If logging has this sort of impact, it should be turned off by default.

I don't think telling people they need to exclude the log files from scanning is a good solution. There are too many manual setup steps already.

I'm willing to look into a solution and possible submit a pull request. Any one else have any suggestions or knowledge of the logging framework?

 

[mm1352000]

It sounds like the problem might be that the logging is continually opening and closing the file. I wonder how hard it would be to keep the log file open?

It probably wouldn't be hard, but I wouldn't assume it is desirable. When log4net was first introduced I recall it was configured to operate that way but was later changed after team discussion. I could be wrong but I think it was changed because some of the team members wanted the ability to clear the log file(s) while MP was running. That obviously isn't possible if they're locked due to being continually open. In short, my point is that MP logging operates the way it does by design.

I don't think telling people they need to exclude the log files from scanning is a good solution. There are too many manual setup steps already.

While I agree with your desire to make setup easier, I don't see a solution that is compatible with all parties. Its not just the log folder that is affected. Timeshift and recording folders can be affected, and I believe the program directories can be too. Some security software is just over-zealous.

 

[cwchapma]

I wonder if the desire to clear the logs while MP is running is a good enough reason to give a very poor user experience when the log file inevitably gets larger. With 'Windows Defender' installed by default in Windows 8, this will be an extremely common problem. Is it possible to reopen this discussion?

 

[mm1352000]

I wonder if the desire to clear the logs while MP is running is a good enough reason to give a very poor user experience when the log file inevitably gets larger.

I think you read to much into my response.
The main thrust of what I was trying to say is:

In short, my point is that MP logging operates the way it does by design.

To be clear I'm not saying the reason I gave is the reason (or even one of the reasons) why the logging is configured the way it is (I did not actively participate in the discussion).

The nice thing is that log4net.config allows you to try the behaviour you want without any code changes. Simply:

1. Navigate to c:\ProgramData\Team MediaPortal\MediaPortal.
2. Open log4net.config in any text editor.
3. Change all references to MinimalLock to ExclusiveLock.
4. Repeat for log4net.config in the MediaPortal install directory, and log4net.config and TvSetupLog.config in c:\ProgramData\Team MediaPortal\MediaPortal TV Server.

Naturally I take no responsibility for any issues this untested configuration might cause.

With 'Windows Defender' installed by default in Windows 8, this will be an extremely common problem. Is it possible to reopen this discussion?

Its not my place to say yes or no. The other comment I'd repeat is that this problem has occurred not only with the log directory but with timeshift, recording and program directory monitoring too. Unless a solution can be found for those other directories, changing the logging configuration seems almost pointless. At least that is my take on it.