Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mkolmar]

Does MC auto import use searches like this, below? Seems like auto import is causing sustained high CPU usage, and probably contributes to overall, intermittent slowness. This stopped when I turned off auto import, which is not really a solution. Could some options under auto import prevent these searches in order to work around the problem?

140158504: 8888: Database: CSearchFilesHelper::GetResults: Search: [Album]=[All Mine] [Media Type]=[Audio]; Elapsed ms: 100.205
140158604: 8888: Database: CSearchFilesHelper::GetResults: Search: [Album]=[All Mine] [Media Type]=[Audio]; Elapsed ms: 97.586
140158702: 8888: Database: CSearchFilesHelper::GetResults: Search: [Album]=[All Mod Cons] [Media Type]=[Audio]; Elapsed ms: 96.057
140158802: 8888: Database: CSearchFilesHelper::GetResults: Search: [Album]=[All Mod Cons] [Media Type]=[Audio]; Elapsed ms: 97.404
140158912: 8888: Database: CSearchFilesHelper::GetResults: Search: [Album]=[All Mod Cons /[re/]] [Media Type]=[Audio]; Elapsed ms: 107.564
140158913: 7948: Sharing Plugins: VHTTPMessage::Write: Wrote 0 bytes
140158914: 7948: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Finish (963 ms)
140158914: 10840: Sharing Plugins: CUDPSocketReader::Accept: Start
140158915: 10840: Sharing Plugins: CUDPSocketReader::Accept: Description: CListenerBase::CListenerBase [UDP]
140159012: 8888: Database: CSearchFilesHelper::GetResults: Search: [Album]=[All Mod Cons /[re/]] [Media Type]=[Audio]; Elapsed ms: 97.469
140159115: 8888: Database: CSearchFilesHelper::GetResults: Search: [Album]=[All My Friends] [Media Type]=[Audio]; Elapsed ms: 100.365
140159217: 8888: Database: CSearchFilesHelper::GetResults: Search: [Album]=[All My Friends] [Media Type]=[Audio]; Elapsed ms: 99.666

[Matt]

Setting on a relational field will do that search.

[mkolmar]

Matt, are you talking about Manage Library Fields? I had not used that until now. No audio fields are set as relational.

Update for external changes is on, and Fix broken links is Yes.

Logs show searches on artist after artist, then album after album, similar to what I posted.

I had shut down BubbleUPnP, Plex server, and phone each for a short time. Unless one of those can create a deep queue of searches, the searches continued to be logged until I turned off auto import. What type of tool might trigger that search, or only within MC?

[JimH]

Are you using any third party software?

Did you configure Windows Defender?

[mkolmar]

Firewall is not set up in any special way on the PC that runs MC, only so MC can access the internet outbound, and local devices can access MC's services.

It would be a rational explanation if this were due to Plex server indexing, or BubbleUPnP client or server. However, searches did continue even with all of them stopped. The servers are not on the PC that runs MC.

Auto-import is re-enabled now. Searches have not started again.

[mkolmar]

Same type of searches, album by album, logged again with high CPU usage. This time I turned off media network in MC, and high CPU usage stopped. Is there some connection between file import (which checks for files already in library), and media network, and CSearchFilesHelper::GetResults: Search?

I'm not aware of a way that Plex server would be able to try to index MC. I turned off MC as a media server for BubbleUPnP server, though I don't think it does any indexing. I've not been using JRemote (not installed) or BubbleUPnP client or Plex during this time. I need to know what type of activity is associated with CSearchFilesHelper::GetResults: Search, if that is something that an external tool can even cause to happen.

[mkolmar]

Has this issue been addressed in MC28? I am not certain how often this is still happening, but it is. This morning I found MC27 highly unusually slow. CPU was maxed. Same type of searches as described appear repeatedly in the log. At times in the past, I know this activity yields to A/V playback, with no obvious slowdown.

Recently I bought JRemote2 again. Playing back through JRemote2 / BubbleUPnP DLNA to Chromecast audio is the only recent difference. MC is always running, and that playback was the last thing I did with MC.

Let's stipulate that the PC running MC27 is no powerhouse, capable of playing basic HD and not much more.

I have had to restart MC and/or affirmatively reconnect to the server a couple times to get JRemote2 to display results from the server. But I suspect JRemote2 simply was not connected, maybe hadn't timed out yet and did not give an error.

[mkolmar]

Logs attached. Both logs show otherwise idle time -- no playback, no manual import, search, or anything.

First log is normal. TV (.105) presumably trying to detect media servers, but TV is not being used to browse or play.

Previous log shows MC eating its own tail? The .102 address is the PC that runs MC. It's not clear to me how to interpret the logging. What could produce these searches? Does it appear to be MC's requests to itself, or something hitting the media server?

MC was bogged down so badly just prior to this logging that it could not play back audio without stuttering. Restaring MC cleared the problem for now.

[mkolmar]

Blocked smart TV in Windows Firewall from connecting to the PC that runs MC a few days ago. I have not seen MC with high, sustained CPU usage since. Let's see how it goes.

I assume the searches would have to use DLNA server, which the TV can do. The TV has not been used to play music or connect with MC or other media server, except as a test, so searches by the TV would be pointless and unwelcome.

MC log could be clearer about what activity is associated with requests from which host. It would also be handy to block IP addresses in the Interfaces to Ingore setting.