Print

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

[Vocalpoint]

All,

I have been trying to understand why Search in the latest v24 builds seem to get slower and slower with each release.

Over the weekend - I rebuilt our file server with Server 2016 and it is blazing fast for all normal activities on all PCs. All our music is stored on a share on this file server.

But last night - I installed the latest build of MC - and set to making a manual playlist where I am searching individual tracks from our FLAC library - and it seems in some cases it's taking 5 seconds for any result to appear.

I type a track name and hit Enter and MC just locks up for 3-4 seconds and then finally seems to wheeze out a search result. The UI is all laggy and I cannot click on anything while the search is happening.

I have looked everywhere that I can for a cause - but this is getting (almost) unusable now.

Anyone have any tips?

And Yes - AV has been told to back off scanning anything to do with MC's directories, FLAC files or anything else relevant on the machine.

VP

[Matt]

Would you be willing to send a library backup to matt at jriver dot com so I could test the same library?

Send me some of the slow searches as well.

Thanks.

[Vocalpoint]

Would you be willing to send a library backup to matt at jriver dot com so I could test the same library? Send me some of the slow searches as well. Thanks.

Matt,

Thanks for the quick response! I would be happy to fire over some files. Will pack up some stuff later this evening and get it over to you.

VP

[timwtheov]

Matt, I have this same issue. It takes 5+ seconds to search pretty much anything, no matter the view and how many files are in it.

I'd send you a library backup with a couple of search suggestions, but since I just reinstalled Windows 10, I'm rebuilding the missing thumbnails (I have a massive library of over a million files, mostly untagged classical music, so it takes about a week to rebuild all of them)--unless you want to try it with many thousands of missing thumbnails.

[Edit] I should note, too, that like Vocalpoint, I have "tamed" Windows Defender so that it doesn't scan any folders with media on them or any of JRiver's processes/folders.

[Vocalpoint]

I'm rebuilding the missing thumbnails (I have a massive library of over a million files, mostly untagged classical music, so it takes about a week to rebuild all of them)--unless you want to try it with many thousands of missing thumbnails.

I have tracked my issues down to thumbnails. As a test I am rebuilding a subset of 10000 right now to see if it matters within the Search function.

MC has completely frozen on screen and is using 20% of my CPU while doing the thumbnails (See attached).

Have never seen a program just die like this during what should be a normal function.

VP

[JimH]

It may be bound by file IO.

[timwtheov]

Vocalpoint, any idea (yet) what the thumbnail issue is, exactly? My search was slow even before I reinstalled Windows 10, i.e., all my thumbnails were built (I rebuild missing thumbnails nearly every day) and the search was still 5+ seconds for any view and seemingly for any media type. I assumed it was (possibly) because of the size of my library or because one of the many hard drives had to wake up or something like that. But overall, the search had become nearly unusable, as you noted in your original post.

One thing I did notice: sometimes after a reboot, the search would be like it used to be (fast), but then after some amount of time (not sure how much), the search would slow back down again.

One other thing occured to me: I usually copy over the built thumbnails from one version of MC to another (from 23 to 24, say, from the App Data folder, as I recall, maybe incorrectly), so as to not spend a week rebuilding them all, and I did wonder if that caused an issue, too.

Anyway, do post on here when/if you find out what the problem is.

Thanks!

[Matt]

That's strange that the search is fast after a reboot and then slows down.  Could the system be starved for memory as it runs a while?

I think Vocalpoint's issue is the thumbnailing.  He had a lot of thumbs not built and some of the files were on a slow drive.  I loaded his library at work here and the searches were super fast.  So hopefully he follows up and says as much!

[Vocalpoint]

I think Vocalpoint's issue is the thumbnailing.  He had a lot of thumbs not built and some of the files were on a slow drive.  I loaded his library at work here and the searches were super fast.  So hopefully he follows up and says as much!

Matt

I am still having massive troubles updating thumbnails. Last night starting at 10:00pm - I thought I would leave MC running to complete my thumbnails overnight. I figured it would be done this morning. I was very frustrated to find out that after 9 hours of thumb-nailing 42000 tracks - MC had only complete 8000. After running all night?

Then when I looked at MC this morning (after running all night) - I can see why it was not completed - MC was only processing maybe 1 thumbnail every 10 seconds. I watched this for about 3 minutes straight to make sure I wasn't seeing things. This vs MC processing about 10 thumbnails every 5 seconds when I started the process at 10:00pm.

To double check that I wasn't seeing things - I stopped the overnight thumbnail session and immediately restarted it - and MC jumped back to processing about 10 thumbnails every 10 seconds.

The music file share has no other processes running overnight. No backups, no scripts, no antivirus on the server - no nothing. The files just sit there - so there cannot be any contention from an outside source overnight that is causing interference with MC and it's thumb-nailing process.

There is something very non-efficient happening within MC - in it's thumb-nailing process here - especially as it moves over time. Almost like the process is not keeping up or is running out of threads or something.

Regarding my library - I will assume that you are seeing fast searches due to the fact that you do have have my files nor do you have a file share like mine. As soon as I get these thumbnails updated - I will run more tests.

But something is definitely not right. My MC library is stored on a super fast local SSD. AV is out of the picture and everything seems optimized but even with some early tests last night - on known albums or songs that I know I have already build thumbnails for - the search still takes 2 or 3 seconds and the UI remains "unclickable" until the results show in the pane.

I tested albums that I hand picked, have unique titles (Show only on result in Search) and ones that I manually rebuild thumbnails on. I would expect these targets to appear almost instantly - but they do not.

So now I need to address some unknowns. Maybe there is something going on with my new file server. Or the network card. and here's another one - I have used this specific library over at least 3 or 4 versions of MC. Could there be a problem with reusing a library over and over again vs creating a clean v24 library and repopulating it from scratch?

What I do as a positive is that my v23 experience had no flaws or slowdowns on the same hardware. As soon as I moved to v24 - these problems began to magnify.

Appreciate any additional thoughts on what/where I should be looking.

VP

[JimH]

Are the files local?  Or on a USB drive?  Or a NAS drive?  Slow access could explain it.

[Vocalpoint]

Are the files local?  Or on a USB drive?  Or a NAS drive?  Slow access could explain it.

All files are on a Windows Server 2016 file share.

MC v23 had no flaws no slowdowns or any other issues on the same hardware.

The issue that needs explaining is why MC processes 10 thumbnails per second when starting a thumbnail session and then grinds down to one thumbnail every 10 seconds after a short period of time. If the network or server was a problem - I would expect to see one thumbnail per 10 seconds all the time - at the start and during the process.

VP

[JimH]

What MC23 did may or may not be relevant.  It doesn't prove anything.

So the files are on another machine?

[JimH]

Not exactly the same problem, but this is worth reading:

https://yabb.jriver.com/interact/index.php/topic,24031.msg811677.html#msg811677

[Vocalpoint]

So the files are on another machine?

Yes. On a standard Windows Server 2016 file share.

VP

[Vocalpoint]

https://yabb.jriver.com/interact/index.php/topic,24031.msg811677.html#msg811677

Is it the Defender item you are suggesting I read?

Defender is not in play in my equation but I am willing to check it out.

VP

[JimH]

It's really to point out that the OS can do some crazy things.  You may think there is no antivirus or firewall, but it may not be certain.

[swiv3d]

Hi VP
I am currently building 21876 thumbnails on a library with files situated on a NAS drive and watching the process with Task Manager - I can see Windows antimalware service executable cutting in every so often with massive network activity which slows the process intermitently, but is chugging away building 2.26 thumbnails per second over the first 45 minutes. It might be worthwhile for you to check out what is happening on your server during the thumbnail building process with task manager (if such an item is present on WS 2016.

[Vocalpoint]

I am currently building 21876 thumbnails on a library with files situated on a NAS drive and watching the process with Task Manager - I can see Windows antimalware service executable cutting in every so often with massive network activity which slows the process intermitently, but is chugging away building 2.26 thumbnails per second over the first 45 minutes. It might be worthwhile for you to check out what is happening on your server during the thumbnail building process with task manager (if such an item is present on WS 2016.

Will be checking out a lot of things this evening - but Windows Defender is disabled by Group Policy on the server. No chance for it to be doing anything to the process.

2.26 thumbs per second sound smuch more reasonable and it' what I thought I should be getting but I am more like 1 per 6-10 seconds at times. There is something going on somewhere here. And I will find it eventually.

I am also wondering if MC has a specific issue with generating thumbs from FLAC files - because that is all I have on the server.

VP

[swiv3d]

Mine are flac files, so I don't think that should be a problem. I would definitely check out with task manager what processes are kicking in that might slow down the build process.

EDIT: Just tried the search function a few times while the thumbnail buid is going on and it gives instant results.

[Vocalpoint]

Mine are flac files, so I don't think that should be a problem.

Do you embed your artwork right in the FLAC file or are you just storing one artwork graphic in the album folder (like folder.jpg or similar)?

ALL 77500 of my FLAC files have embedded artwork.

VP

[swiv3d]

My artwork is embedded in the files - lost too many cover art images by having them in folders.

[swiv3d]

You might want to check whether MC 24 has the correct permissions for your server file share.

[JimH]

Will be checking out a lot of things this evening - but Windows Defender is disabled by Group Policy on the server. No chance for it to be doing anything to the process.

That's a bold statement. Awesome Donkey wrote his Master's thesis on Windows Defender.  It's in a thread here somewhere.

[Vocalpoint]

That's a bold statement. Awesome Donkey wrote his Master's thesis on Windows Defender.  It's in a thread here somewhere.

I've read it. However Windows Server Enterprise 2016 and consumer Window 10 Defender are two different things. If Defender is disabled on Server by GP - off means off.

And I have already tested it using ProcessMonitor (via SysInternals). There are no processes or source files even remotely connected to Windows Defender running on the server when MC is doing it's thumbnails.

VP

[Vocalpoint]

All,

Spent quite a bit of time checking and rechecking my new file server - all is well with the hardware and there are no mysteries interfering with any MC processes on the server.

I managed to get my thumbnails to 100% and have tested the search again. It is better than it was but still has lags dependent on what I am looking for. It may be a factor of my machine or this specific library but it's not "lightning fast" by any means. Let's call it usable.

I will be trying a few other tests like setting up a new library to see if the search performance is different between a clean new v24 library and my old cranky v18-v24 library that I have been using for years.

VP