Is it worth the hassle? I'm running MIP on a (nowadays) lowest end machine and never missed a beat due to the MIP communication. Maybe I need more music...

Do you have a rebuttal to help us decide, KDF? :)

I never intended it to be a priority.  Andy mentioned it once so I remembered one day and thought it should be filed.  'future' would work, or perhaps as part of the 7.3 scanning changes.  Users are already talking of huge overhauls in metadata handling so much of MIP would be gutted for that anyway.

Michael notes we haven't had complaints.  Andy notes this is a substantial rewrite.

Created attachment 3731 [details]
step one

this takes care of the high overhead checker.  the idea is that at least we can avoid a repeated warning when abusing http protocol handler and also avoid the blocked http call every 2 minutes.

Great, this call is what I was most worried about too. :)

the next one is the startup checks (as they do hold up things when they fail).  the trick is to make sure the response is there in time to continue anything that follows (ie scanning).  I'm not so up on the async stuff to be sure I'm catching the right cases and doing it the "best" way.

Created attachment 3735 [details]
step two

this makes the init routine async as well, so now it shouldn't get in the way of startup if mip is disabled or not available.  I can't do much with grabMoods as it's called on the fly far too often.  I would like to make mixes async, but I have no idea how to hold off the page render results while waiting for the callback results.

Let me know if we can move this into 7.2 with the current patch, or if it should just be committed to 7.3

Cool, let's get these into 7.2.

change 22329 contains the init and checker fixes.

Should we close this bug?

I think the worst offenders are handled now.  Given that the rest depend on already knowing that the plugin is working, connect to MIP is working and that we know that MIP is more than likely running on the same machine it should be safe to assume that the remaining blocking requests will not block for long.  They will, however, continue to cause warnings when they hit the standard http protocol handler (which expects a song reference)

More important reason to close, I really don't have a clue how to do any more than I have on this one :)

Yeah I'm fine with it now.

Reduce number of active targets for SC