Print

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

[marko]

Any ideas why this view is getting slower and slower to work with?

It used to be smoother than a smooth thing, but now, almost unuseable.

It's almost fully expression driven, but it makes no difference if I make those library fields instead.
It uses the main and the CD database.

If I move from left to right making selections, by the time I get to the sixth pane, Artist, a selection in there takes a full five seconds to filter.
Inline edits then also take a good five seconds to commit after pressing enter.
If I cut directly to "Calendar" on the far right, it takes about three seconds to filter.

It's only listing 56½ thousand files, 2700 artists and 2500 albums.

[StFeder]

I noticed the same for some time. I have a similar looking view which got unusable for editing metadata over the last couple of month with a comparable amount of files as you have (42.000).

I mainly use my view to create mixes for different music scenarios so not a very big deal, but it also can be handy to update some meta data which now is nearly impossible (five seconds for changing a songs rating). MC completely stalls during that time (thankfully the music keeps playing )

[marko]

Any thoughts on this issue?

My system benchmarks at 3065. I'm sure it used to hit the 3500 mark a few years ago...

=== Running Benchmarks (please do not interrupt) ===

Running 'Math' benchmark...
    Single-threaded integer math... 4.530 seconds
    Single-threaded floating point math... 2.554 seconds
    Multi-threaded integer math... 1.488 seconds
    Multi-threaded mixed math... 1.016 seconds
Score: 1982

Running 'Image' benchmark...
    Image creation / destruction... 0.840 seconds
    Flood filling... 0.711 seconds
    Direct copying... 0.733 seconds
    Small renders... 1.857 seconds
    Bilinear rendering... 1.337 seconds
    Bicubic rendering... 0.799 seconds
Score: 3505

Running 'Database' benchmark...
    Create database... 0.421 seconds
    Populate database... 1.422 seconds
    Save database... 0.220 seconds
    Reload database... 0.090 seconds
    Search database... 1.421 seconds
    Sort database... 1.428 seconds
    Group database... 0.795 seconds
Score: 3708

JRMark (version 22.0.6): 3065

[JimH]

Changes in the system?  Hardware or software?

Background processes?

[blgentry]

How about making a copy of the view, and then starting it from scratch, building it up one Pane at a time.  When it gets slow, you've found where the problem lies.

Or the opposite.  Take your copy and eliminate one pane at a time, stopping when it gets fast again.

This should help pinpoint which expression or database field, or whatever, is the source of the issue.  Then you can go from there with that knowledge.

Brian.

[Matt]

How about making a copy of the view, and then starting it from scratch, building it up one Pane at a time.  When it gets slow, you've found where the problem lies.

Or the opposite.  Take your copy and eliminate one pane at a time, stopping when it gets fast again.

This is a good idea.

I loaded your test view but it was pretty darn snappy for me.  I don't have a huge list of files so that might be why.

But figuring out which pane causes the slowness would be a great step.

[marko]

This is a good idea.

I loaded your test view but it was pretty darn snappy for me.  I don't have a huge list of files so that might be why.

But figuring out which pane causes the slowness would be a great step.

Interesting. I can do all that trouble shooting, but didn't want to if there was an obvious problem. Matt, are you benchmarking at 4 or 5 thousand? Will that make a difference in the grand scheme of things?
I found an old benchmark from back in 2011 or 2012, from MC17, where I returned a 3496 score, on this same machine. The image score is about the same, but both Math and Database have dropped by about 500 points.

This should help pinpoint which expression or database field, or whatever, is the source of the issue.  Then you can go from there with that knowledge.

I've done this already, moving from right to left, removing a pane at a time. There was no 'eureka', it just got progressively quicker as the panes reduced.

I'll do some testing in a test library over the coming weekend. I'll test by 'remove and return' and then move on to the next one. I'll try a few files vs. a few thousand. I'll let you know if anything crops up.

[StFeder]

I've done this already, moving from right to left, removing a pane at a time. There was no 'eureka', it just got progressively quicker as the panes reduced.

I also tried the same for me. I ended up with just one pane filtering based of my user field "Tanz" (german for "Dance") which contains one out of 47 possible values and still got the ~4-5 seconds stall.

[StFeder]

I could figure out what makes MC work hard for me. It's one of my sorting options.

I have an expression field like this:

FormatNumber( IfElse( IsEmpty( [BPM StFeder] ), FormatNumber( [BPM calculated], 1), IsRange( Math( abs( replace( [BPM calculated], /,, .) - [bpm StFeder])), 0-1.9), FormatNumber( [BPM calculated], 1), 1, [BPM StFeder]), 1)&datatype=[number]

It compares the calculated bpm field with my own counted bpm. I let MC sort ~42000 files based on this field. If I remove the sorting option everything is pretty much snappy again.

[Hendrik]

Sorting on an expression is expected to be slower, as it needs to calculate the expression for every single file all the time. But it should really not be stalling, I would think.

[StFeder]

Sorting on an expression is expected to be slower, as it needs to calculate the expression for every single file all the time.

I'm expecting that and it's ok for me to wait a few seconds when entering (or resorting) the view. But it is strange to get a freeze just when editing meta information.

[marko]

Sorting on an expression is expected to be slower, as it needs to calculate the expression for every single file all the time. But it should really not be stalling, I would think.

I am also prepared for that. However, I have been using that same view on this same system for a fair few number of years now, and just recently, it has become all but unuseable as when I make filter selections from the left to right, by the time I'm five panes in, everything I do is click and wait five seconds.

There is no one 'eureka' pane that suddenly speeds the view up when it is removed.
Removing the CD database (for testing as this defeats the purpose of the view) it knocks about two seconds off the filter time.

Now, what does help, is turning off bi-directional filtering. That knocks between three and four seconds from each filter stage, and the filter time remains uniform across all panes from left to right. This does mean that I'm losing functionality in the view.

All those years this view has served me well, and now, it starts playing up. It used to have that 1 to 2 second lag with bi-directional turned on, and that was lag I could live with as I knew I was pushing MC hard with the demands of the expressions.

[Matt]

I have the view WhereIsIt? imported.  There are 25543 files.  Not a ton, but not that little either.

I turned on bidirectional filtering in the panes.

It's still way less than a second if I pick in any pane.

[marko]

Finally, I've found the reason for this... It's all mark_h's fault

Set files to display:
(p="album rating" or [Media Type]=[audio],[Image],[Video]) -p=recycle -[type]=[Album Art],[emailers],[Girls],[Illusions] ~d=mc

For this, I set up Album Ratings as per mark_h's post here. I'm in this view very often, and it seemed a good way to run the data as early as in a MC session.

The album rating smart list includes all audio in the main library. I then need to specify [media type]=audio again, in order to draft in tracks on audio and data discs. As soon as I remove this trip into the album ratings smart list, the whole thing is back to its snappy old self and is once again useable.

Question is, why? It never used to be this slow, and the files to show rules have been that way for years.

-marko