Print

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

[rjm]

Thanks for asking.

1) Can anything be done to speed up the selection of and navigation within views? This is central to the usability of the product and any improvement would be enjoyed by all. Separate threads for each tab? Separate threads for smartlists used by views?

2) How about multiple threads for analyzing/converting so that all available cores are maxed out. Or have you already done this?

Tag saving is already very fast - doubt users would gain much from your proposal.

Cheers.

[Matt]

Thanks for asking.

1) Can anything be done to speed up the selection of and navigation within views? This is central to the usability of the product and any improvement would be enjoyed by all. Separate threads for each tab? Separate threads for smartlists used by views?

If you have a view that feels slow to load, could you email me a library backup and the name of the slow views?  It's matt at jriver dot com.

Thanks.

[rjm]

If you have a view that feels slow to load, could you email me a library backup and the name of the slow views?  It's matt at jriver dot com.

Thanks.

My main view (which is fairly simple but displays everything grouped by album) take 8 seconds to come up.

My simple views (subsets of library, no grouping) take 1 second to come up.

All other views take 4-5 seconds.

Perhaps we should wait until I have MC13 in production because we know it is better.

[edit] oh, and I'm running 12.0.470 waiting for the iPod fix...

[Matt]

My main view (which is fairly simple but displays everything grouped by album) take 8 seconds to come up.

That's slow.  If you send me a library backup, we may be able to make it faster.

[rjm]

My library backup is 50 MB so no go on email. And it has much personal info like family photos so not sure I want it floating around. Would it be useful for me to send you the design of my main view? Or, I could clone my library and delete the majority of files, leaving the views intact?

btw: Above I said my main view was simple. I should retract that since I have no idea what the definition of simple is when it comes to view performance. For example, I make heavy use of nested fields. I have a sophisticated sort order. And I use album grouping.

[thurston]

Matt, what about Theater View animations? Is this a candidate or is this really a limitation on the way the GPU handles things? Animations tend to stutter from time to time while video/tv playback is happening. It's nothing bad but thought I'd mention this anyway.

Cheers.

This was the first thing that came to my mind too

[Alex B]

My library backup is 50 MB so no go on email. And it has much personal info like family photos so not sure I want it floating around. Would it be useful for me to send you the design of my main view? Or, I could clone my library and delete the majority of files, leaving the views intact?

Matt's offer is generous. You should take advantage of it. Your library would probably help us all if Matt can tweak MC to handle it faster.

Cloning would be right way to do it, but instead of deleting files you should replace the tag values that contain sensitive personal info with some other info. Disable physical file tagging and mass tag those fields with some other text strings that have approximately the average length of your tag values.

You can upload the zipped library to a free service like www.megaupload.com or www.rapidshare.com and mail just the link.

[JimH]

50MB seems like a lot.  I wonder if it's corrupt.

I have 25,000 files and the library backups are less than 3MB.

Is your library more than 400,000 files?

[Alex B]

A couple of days ago rjm said that it is 190,000.

My largest library contains 60,000 files and the backup file is 9 MB.

You can easily multiply the library size by adding big tag values like lyrics or descriptive stories (or lots of small values).

[rjm]

I exaggerated a little. It is 183,000 files. Uncompressed library is 97 MB in size. I try to avoid heavy use of text fields. No lyrics or stories.

Four largest library files are:
field (text).jmd             26.83 MB
field (filename).jmd        20.18 MB
field (name).jmd            3.74 MB
mediafiles.jmd               2.12 MB
The rest of the library files go smoothly down in size from here.

I would love to take up Matt's offer.

Wondering if a guru out there could suggest a function that would let me anonymize my library.

Need a function "Scramble" that I could use like this:

[Name]=Scramble[Name]

where new name is a unique hash of the original name with same number of characters.

[JimH]

Your name and filename files are about 40 times the size of mine, though your library is only about 7 times mine.  Odd.

Your library backup will be zipped, so it should be around 12 or 15MB.  File / Library / Back Up Library

Don't worry about privacy.  There aren't any pictures in the library.  Matt is a Boy Scout.  He'll shred it when he's finished.

[rjm]

Using max compression with WinRAR it's 43 MB.

I trust JRiver. It's the other billion people on the internet that I don't trust.

Scratch my request to the gurus out there. I figured out how to anonymize my fields using existing MC tools.

[JimH]

Are you using MC's backup?  It zips the files.

[rjm]

Yes I know. RAR is a little better at compression than Zip which is why I tried it. I'll use the MC standard Zip, which is closer to 50MB, when I send it.

[Alex B]

... Scratch my request to the gurus out there. I figured out how to anonymize my fields using existing MC tools.

As a test, I did the following:

- Cloned my largest library on a laptop, disconnected LAN to make the media files off-line, disabled tag writing and switched Auto-Import off.

- Created an "all media" view scheme. It displayed about 60,000 files.

- Selected all files and pasted =[Duration] [track #] [Bitrate] [Date] [Filename] in the album field in AW. This created a new unique album value for each file (about 50.000 of them are audio).

- Processing took about 10 minutes. The new values appeared in about two minutes and the rest of the time was apparently used for composing and writing the physical library files when I browsed away from the view. The resulting field (album).jmd file was a bit over 5 MB.

I guess you figured out something similar.

[rjm]

Very cool idea for audio, thanks!

I am thinking of getting a one time lookup pad from https://www.grc.com/passwords.htm.

It will be fun to see how MC performs when I select 183k files and do a single character find and replace on a half dozen or so fields.

[Deivit]

My library backups are almost 100 MB each (uncompressed library is 163 MB) 

[rjm]

I did some timing comparisons between MC12.0.470 and MC13. I am seeing a 50% reduction in time to display a view in MC13. Views that took 8 seconds now take 4 seconds. Views that took 4 seconds now take 2 seconds. Congrats to the development team!

Also did a few tests to try to isolate why some MC13 views take 2 seconds and others take 4 seconds. I am pretty sure that the increase is caused by using "Group by Album".

Is this increase due to grouping expected and normal? Is there anything I can do in my grouping view design (such as reducing the number of fields used in the sort) to minimize this increase?

[Matt]

Is this increase due to grouping expected and normal? Is there anything I can do in my grouping view design (such as reducing the number of fields used in the sort) to minimize this increase?

It takes extra time to do grouping since it requires an extra layer of processing to calculate and sort the groups.  This step got quite a bit faster in MC 13, but we'll take another look to see if there's any way to make it faster yet.