Topic: Slow areas in MC 9.1 v2 (Read 6337 times)

dragyn · « **on:** October 17, 2003, 11:56:13 am »

I'm gonna start a new thread on this because the other one is too big now. These are most noticable with large libraries.

Some slow spots I see now are as follows:

If you're in a view scheme with some rules set, it displays the files fine. When you start playing a track, it seems MC has to re-read the scheme to display the same files that are already there. Same with switching tracks.

Anyway it could update the file being displayed without doing this?

View filter is still way too slow for me too use. If I set up a view scheme with the same rules applied, it's at least 5 times faster in the same library. Again, playing/switching tracks is even more noticable because it has to go through the view filter to display files that are already displayed (above).

Viewing Fullscreen images are slow because it's updating the list again (I think). If I'm in Playing Now and then go to Fullscreen, it's a lot faster. There could be a 10sec lag bewteen the two.

Now I wasn't gonna say anything about tagging mode because that was slower than the above but that was fixed recently and now it's pretty fast. I'm sure you guys could do the same for these areas too.

Thanks

dragyn · « **Reply #1 on:** October 18, 2003, 09:20:55 am »

I'm still trying to figure out what MCs doing sometimes. The hard disk would be going like mad and I'm not doing anything. Mostly happens when I start sometimes. MC has to be checkin' somethin but what I don't know.

It will sit there for like 5mins before I can actually do anything.

I know it was said that it checks for missing / orphan thumbnails but if that's the case, I think we should just not do that anymore. Me having 2 more thumbnails wouldn't hurt me any compared to the gigabyte of thumbnails I have already.

Does this seem like what it would be doing?

Same with shutdown, I'm starting to notice a lag time again.

dragyn · « **Reply #2 on:** October 18, 2003, 09:24:56 am »

I just checked and there are 202,268 thumbnails created by MC. That's probably what's making my head spin half the time.

marketability · « **Reply #3 on:** October 18, 2003, 10:25:36 am »

Dragyn - 202K thumbnails - do you have the equivalent number of files or is MC creating "surplus" images?

dragyn · « **Reply #4 on:** October 18, 2003, 01:04:17 pm »

Well MC can create 3 thumbnails for each file (small, medium, large).

I deleted all the thumbnails and MC starts and closes instantly now like it should. So I know something is happening with them.

graham131 · « **Reply #5 on:** October 18, 2003, 04:22:54 pm »

Another couple of Slow Areas for me are:

I have approx 70,000 files and the searching function has become pretty redundant for me due to the time taken. (PS - This is on a PIV 2.53Mhz with 1GB Ram)

Watching Task Manager and processor utilisation is interesting - 100% till it completes.

On my test rig - Celeron 533Mhz with 384Mb Ram - it is painfully slow. But then again so is changing a view scheme to another one. On this machine the processor can sit at 100% for literally 40 or 50 seconds.

Another scenario is when starting MC - my main PC takes about 20 secs. Test Rig - maybe a minute.

Graham

PPS - Shutting down is instantaneous on both, however if you again watch task manager - it takes a long time (30 secs & 50 secs respectively) to release memory.

graham131 · « **Reply #6 on:** October 19, 2003, 05:54:05 am »

Quote from: Dragyn on October 18, 2003, 01:04:17 pm

Well MC can create 3 thumbnails for each file (small, medium, large).

I deleted all the thumbnails and MC starts and closes instantly now like it should. So I know something is happening with them.

Wow - Dragyn. That makes 1 hell of a difference.

The only point that remainis is the way in which MC appears to search.

Rather than allowing a small pause before searching after you type the first letter to see if you are going to type further letters it starts to search immediately.

A small pause would be good, and would also save time in completing searches.

Graham

PS - Are J River aware of the "issue" concerning thumbnails?"

marketability · « **Reply #7 on:** October 19, 2003, 11:39:27 am »

I agree with Graham131...
On a P4 2.4GHz with 512Mg RAM...

changing to a different view scheme = processor runs @ 100% for 22 - 31 seconds.

starting MC - average 21 secs

Shutting down is instantaneous - task manager - takes approx 30 secs to release memory and unload DLLs/components

KingSparta · « **Reply #8 on:** October 19, 2003, 11:46:28 am »

I don't use thumbnails but i can see how this would slow down the system.

i am wondering if deleteing all the external cover art may also speed it up.

the other slow area and i think it has become worse is Image taging and the added questions. when i tell MC9 to do somthing i want it to do it not go away for 15 mins then ask me are you sure? then i come back from work and it still is not done because it is waiting on me to answer a question then after i tell it "yes" it takes another 15 mins to save cover art inside the file.

It reminds me of my wife keep naging me asking questions, but in this case i must answer when my wife asks i can just normaly ignore her unless she comes in my room and asks again.

graham131 · « **Reply #9 on:** October 19, 2003, 12:35:37 pm »

Quote from: KingSparta on October 19, 2003, 11:46:28 am

i am wondering if deleteing all the external cover art may also speed it up.

Just tried deleting Cover Art (in fact all images) from my test rig. It makes a significant difference in changing view schemes etc, almost to the same sort of speed as my main PIV PC.

Still the same issues though with starting / stopping / memory & processor usage and release times.

graham131 · « **Reply #10 on:** October 19, 2003, 04:09:44 pm »

I have also discovered aother area of extreme slowness in MC.

If you are sending "lots" of files for burning (on a DVD) to the writer the process can take minutes, when all that happens is that MC appears to hang but sits at 100% Processor Utilisation. If you are patient it eventually completes (after 12 mins for a full DVD's data worth) in my case.

Note that "lots" in my case was approx 3Gb worth

Graham

Matt · « **Reply #11 on:** October 19, 2003, 05:28:36 pm »

We'll see what we can do.

The more you can pinpoint what's slow, the more it will help us. For example:

Is it only views with panes that are slow, or does a playlist with 100,000 images also seem slow? (to create, and to start playback from)
If you look at images in "Details" mode, is that slow?
Are audio views also slow, or just image views?
Does the search criteria / view filter of the view make a big speed difference?
Do you have a lot of large values (lyrics & bios) in your database, and does removing them help?

Thanks for helping.

Matt · « **Reply #12 on:** October 20, 2003, 11:24:16 am »

The "Analyzing Thumbnails..." stage was taking 5 seconds for 30k files on my AMD 2.6. For Dragyn (with 100k files and a slower computer) that time could easily have been a minute.

In the next build the "Analyzing Thumbnails..." stage has effectively been optimized away, so there should be huge speed increases for large views.

Thanks for helping, and please keep the feedback coming.

dragyn · « **Reply #13 on:** October 20, 2003, 11:59:40 am »

Could you test the same for thumbnail images?

Create all 3 sets and close MC and see how long it takes. I'm hitting at least a couple minutes on my system.

Thanks Matt!

Matt · « **Reply #14 on:** October 20, 2003, 01:42:17 pm »

Thumbnail cleanup isn't very slow for me. Still, next build will allow you to turn it off.

KingSparta · « **Reply #15 on:** October 20, 2003, 01:55:59 pm »

I think this is a matter of too many files in a Folder so if i have 131,000 files and each has it's own cover art. you have then have 131,000 cover art \ thumnail files in a single folder. when MC9 access this folder would it not be slower than if MC9 broke this down into more than one folder?

Matt · « **Reply #16 on:** October 20, 2003, 02:02:01 pm »

Thumbnails are split across 16 directories per size, so that's less than 10,000 files in a folder, which should be fine.

KingSparta · « **Reply #17 on:** October 20, 2003, 02:09:24 pm »

I don't use Thumbnails but can't the same be done for cover art if that also seems to be a problem?

it might help a bit not sure how much

I don't think this is a major problem however.

jleerigby · « **Reply #18 on:** October 20, 2003, 02:16:24 pm »

Quote from: Matt on October 20, 2003, 11:24:16 am

The "Analyzing Thumbnails..." stage was taking 5 seconds for 30k files on my AMD 2.6. For Dragyn (with 100k files and a slower computer) that time could easily have been a minute.

In the next build the "Analyzing Thumbnails..." stage has effectively been optimized away, so there should be huge speed increases for large views.

Thanks for helping, and please keep the feedback coming.

Sounds great but I'm not sure I understand what you mean by 'optimised away'. Will there be a trade-off for this performance improvement?

Matt · « **Reply #19 on:** October 20, 2003, 02:23:42 pm »

Quote

I don't use Thumbnails but can't the same be done for cover art if that also seems to be a problem?

I don't think it'll be a problem with cover art because normally about 10 files share one piece of art. That keeps the cover art count pretty low. (cover art is also thumbnailed, so the actual art doesn't get read too often)

Quote

Sounds great but I'm not sure I understand what you mean by 'optimised away'. Will there be a trade-off for this performance improvement?

The hitch is that it no longer builds thumbs for files you're not looking at. That makes it faster and removes the need for the "analyzing" step.

The tradeoff is that scrolling through files that don't have thumbs yet will be a little slower. (previously the thumb thread would make sure everything was built so that scrolling would be faster)

Once the thumbs are built, it'll run at the same speed (or faster) than ever. Since thumbs only ever get built once (unless you manually erase them), this isn't such a big deal.

It's out now, so please try it and let us know how it seems.

dragyn · « **Reply #20 on:** October 20, 2003, 02:27:20 pm »

282 has definately improved a lot of areas mentioned here. Thanks! It really is appreciated!

KingSparta · « **Reply #21 on:** October 20, 2003, 02:36:15 pm »

Quote

I don't think it'll be a problem with cover art because normally about 10 files share one piece of art.

Maybe, i just moved mine out of the cover art folder (seems a bit faster) there was 12,500+ cover art files in there.

jleerigby · « **Reply #22 on:** October 20, 2003, 03:00:13 pm »

Quote from: Dragyn on October 20, 2003, 02:27:20 pm

282 has definately improved a lot of areas mentioned here. Thanks! It really is appreciated!

There should be an outright ban on anyone saying how good the latest release is for at least the first 2 hours after it's been posted. It's not fair to those of us who have to sit watching 26 kbps streaming in front of them.

Quote

It's out now, so please try it and let us know how it seems.

I will - tomorrow lunchtime!

dragyn · « **Reply #23 on:** October 20, 2003, 04:46:28 pm »

ok I now have been playing with the view filter and here's what I found.

First, since 282, when viewing the file list, it updates right away so that bug has been fixed.
Here's the other slow down:

I did a test with 2 view schemes

Albums is a playlist of all my ape images. [media type]=[audio] [file type]=[ape] [Track #]=<1
There's 61 files in this smartlist.

I have also created a smartlist in a playlist group called network. The smartlist is [Filename (path)]=[\\computer\"
There's 10,393 files in this smartlist.

There's 121,587 files currently in the library.

Audio [Media Type]=[Audio] -[Playlist]=[Albums]
-Artists [Media Type]=[Audio] (inherit parent, populate)
Panes: Artist | Album

Audio2 [Media Type]=[Audio] -[Playlist]=[Albums] [Filename (path)]=[\\computer\"
-Artists [Media Type]=[Audio] (inherit parent, populate)
Panes: Artist | Album

The columns are identical in boths views. Same with sorting.

If I have the view filter to show all files, it takes Audio2/Artists about 3secs to show the correct files.
If I have the view filter set to show only 'Network', it takes Audio/Artists about 27secs to show the correct files.
The correct # of files are the same.

That a 24sec difference for using a view filter rather than making a new scheme with the filter inside.

Matt · « **Reply #24 on:** October 20, 2003, 05:02:50 pm »

How fast is it if you leave each view and come back? (without doing anything in between)

The view filter will be slow when it is first calculated, but then should be fast after that. Database changes cause it to be recalculated.

Let us know if it's always slow, or just when it's first run and we'll dig some more.

dragyn · « **Reply #25 on:** October 20, 2003, 05:08:22 pm »

it's the same going back and forth between view schemes/playing now and back. ~25secs

It seems it takes ~15secs before 'loading view' shows, then after a half a second is shows loading panes for about 7 secs, then the rest is fast.

KingSparta · « **Reply #26 on:** October 20, 2003, 09:00:49 pm »

Why Is it So slow to Clear The Paths Of Cover Art If this field is not saved to the MP3 file?

it took about 45 mins for it to do somthing and then it asks if i really want to make all the changes and it has taken another hour to save changes to the database.

with 14,000 files

Matt · « **Reply #27 on:** October 21, 2003, 02:05:35 pm »

Quote

Why Is it So slow to Clear The Paths Of Cover Art If this field is not saved to the MP3 file?

Since many audio files may share the same image, we have to run through the database to check for other affected files during each delete.

We're working on a better solution...

Matt · « **Reply #28 on:** October 21, 2003, 03:35:23 pm »

Dragyn,

Switch your rules from:

[Filename (path)]=[\\computer\"

to

[Filename]=[\\computer\"

That'll help speed a bunch since calculated fields are slower. Let us know how much difference that makes.

King,

Changing / removing images will be much faster next build. (saving tag changes will take the same amount of time though)

dragyn · « **Reply #29 on:** October 21, 2003, 03:47:31 pm »

Ok I changed it.

with view filter, 13 secs to get to gather files, another 13 secs to get to panes loaded then it's instant after that

with out view filter, <3secs total

It's also slower with the view filter on and going to audio2 than it is with view filter off.

KingSparta · « **Reply #30 on:** October 21, 2003, 07:21:05 pm »

Matt can't we have an option to turn off the "Are You Sure" prompt?

Don't you have the Undo option working?

================================================

also when you make a change in the tags it reallly does not start saving unless you click on the list again (at least when you change alot of tages) is it that when that message pops up are you sure? that the list lost focus and thats why it is not saving?

when i make a change i would like that change made and not need to come back in from mowing the lawn and select "yes make the changes" and or click on the file listing just to get MC to save the changes, then go back to mowing the lawn.

KeystoneCop · « **Reply #31 on:** October 21, 2003, 07:28:29 pm »

Quote

when i make a change i would like that change made and not need to come back in from mowing the lawn and select "yes make the changes" and or click on the file listing just to get MC to save the changes, then go back to mowing the lawn.

AMEN.. Sure would be nice have a "do it now" button and a "I screwd up, forget it " button.

Matt · « **Reply #32 on:** October 21, 2003, 10:24:45 pm »

Quote

Matt can't we have an option to turn off the "Are You Sure" prompt?

Don't you have the Undo option working?

It's there because too often people accidently changed 100 or 1000 files when they meant to change 1 file. This way, it at least tells you before changing a lot of files.

Quote

also when you make a change in the tags it reallly does not start saving unless you click on the list again (at least when you change alot of tages) is it that when that message pops up are you sure? that the list lost focus and thats why it is not saving?

when i make a change i would like that change made and not need to come back in from mowing the lawn and select "yes make the changes" and or click on the file listing just to get MC to save the changes, then go back to mowing the lawn.

This was changed recently because people that run multiple tools on the same selection didn't want the tags to get rewritten multiple times. So, tags get saved on selection / view change.

Is there a better way? We won't introduce "Save" and "Cancel" buttons. (adds complexity, requires more clicks, and doesn't really add anything)

We could change the prompt to "Save Now", "Save on View / Selection Change", "Discard".

Any other ideas?

nila · « **Reply #33 on:** October 22, 2003, 02:59:10 am »

Just gotta say so it's an equal voice - as one of the guy's who's messed up a LOT of files - I'm REALLY glad it asks for comfirmation when changing a lot of files.
I'm also glad it doesn't do tag updates instantly as when I'm freshly tagging files (like my pictures) I'll often be making 3-5 tag changes and dont want it written each time I change it.

Having said that - in tagging mode I dont think it should ask for confirmation as you are in a mode deliberately for tagging.

KingSparta · « **Reply #34 on:** October 22, 2003, 02:26:25 pm »

Quote

It's there because too often people accidently changed 100 or 1000 files when they meant to change 1 file.

both of them i feel are problems and bug the crap out of me.

RandyP · « **Reply #35 on:** October 22, 2003, 03:19:28 pm »

Quote

We could change the prompt to "Save Now", "Save on View / Selection Change", "Discard".

I would *love* to have this option! Just yesterday I had used "Rename Files from Properties"... it told me there were 177 files, and I said "OK". I was looking around the disk, and the files were still there!

Oh, yeah, the command hadn't been executed. I had to go back to MC9, click some other field, and *then* the files actually got moved. I would truly appreciate the ability to turn this feature off. This is just one example of needing to "go click something" that happens several times a day.

graham131 · « **Reply #36 on:** October 22, 2003, 04:10:15 pm »

Quote from: KingSparta on October 22, 2003, 02:26:25 pm

Quote
It's there because too often people accidently changed 100 or 1000 files when they meant to change 1 file.

both of them i feel are problems and bug the crap out of me.

Not everyone can be perfect!

KingSparta · « **Reply #37 on:** October 22, 2003, 04:23:55 pm »

Quote

Not everyone can be perfect!

I Am Ask My Wife.

graham131 · « **Reply #38 on:** October 28, 2003, 12:28:08 pm »

Quote from: graham131 on October 19, 2003, 04:09:44 pm

I have also discovered aother area of extreme slowness in MC.

If you are sending "lots" of files for burning (on a DVD) to the writer the process can take minutes, when all that happens is that MC appears to hang but sits at 100% Processor Utilisation. If you are patient it eventually completes (after 12 mins for a full DVD's data worth) in my case.

Note that "lots" in my case was approx 3Gb worth

Graham

Bump - Any thoughts JR?

Matt · « **Reply #39 on:** October 28, 2003, 12:37:16 pm »

How are you adding the files to the burn queue? Drag-n-drop to the Action Window, right-click 'Send To', etc.

Also, is it everytime, or only if the queue is empty or full or some in some other state.

Thanks!

Matt · « **Reply #40 on:** October 28, 2003, 12:46:49 pm »

Quote

I have also discovered aother area of extreme slowness in MC.

If you are sending "lots" of files for burning (on a DVD) to the writer the process can take minutes, when all that happens is that MC appears to hang but sits at 100% Processor Utilisation. If you are patient it eventually completes (after 12 mins for a full DVD's data worth) in my case.

Note that "lots" in my case was approx 3Gb worth

Graham

Found it, so it'll be fixed next build.

The album analyzer was being rerun in cases where it didn't need to be.

graham131 · « **Reply #41 on:** October 28, 2003, 01:06:05 pm »

Sorry Matt - i should have given you more info.

My findings are as follows:

Test 1 - Highlight 57 Files (370Mb) - right click -> send to G (My DVD burner) - This takes 1min 29 secs and my CPU Utilisation is 100% during that time.

Test 2 - Highlight 74 files (579Mb) - right click -> send to G - This takes 2 mins exactly, and again CPU sits at 100%

Test 3 - Highlight 74 files (555Mb) - drag files and drop onto DVD burner - Results are instantaneous!

Test 4 - Highlight 235 Files (2.4Gb) - drag and drop - instantaneous!!!!!

Therefore the issue appears to be with "right click send to"

Regards

Graham

Media Center Registered 9.1.289 -- C:\Program Files\J River\Media Jukebox\

Microsoft Windows XP Workstation 5.1 Service Pack 1 (Build 2600)
Intel Pentium 4 2529 MHz MMX / Memory: Total - 1048 MB, Free - 555 MB

Internet Explorer: 6.0.2800.1106 / ComCtl32.dll: 5.82 (xpsp1.020828-1920) / Shlwapi.dll: 6.00.2800.1226 / Shell32.dll: 6.00.2800.1233 (xpsp2.030604-1804) / wnaspi32.dll: Internal ASPI Layer

Ripping / Drive E: Copy mode:ModeBurstBigBuffer CD Type:Auto Read speed:Max
Drive F: Copy mode:ModeBurstBigBuffer CD Type:Auto Read speed:Max
Drive G: Copy mode:ModeBurstBigBuffer CD Type:Auto Read speed:Max
Digital playback: Yes / Use YADB: Yes / Get cover art: Yes / Calc replay gain: Yes / Copy volume: 32767
Eject after ripping: Yes / Play sound after ripping: No

Burning / Drive F: YAMAHA CRW2200S Addr: 0:2:0 Speed:20 MaxSpeed:20 BurnProof:Yes
Drive G: PIONEER DVD-RW DVR-105 Addr: 3:0:0 Speed:4 MaxSpeed:4 BurnProof:Yes
Test mode: Yes / Eject after writing: Yes / Direct decoding: Yes / Write CD-Text: No
Use playback settings: No / Normalization: None

INTERACT FORUM

Author Topic: Slow areas in MC 9.1 v2 (Read 6337 times)

dragyn

dragyn

dragyn

dragyn

dragyn

jleerigby

dragyn

jleerigby

dragyn

dragyn

dragyn

nila