Print

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

[dragyn]

I've noticed this before but haven't said anything until now.

When using a registry monitor, I get the following THOUSANDS of times per minute. Maybe it has something to do with my slowness?

8:01:38 PM      Media Jukebox.e:1944      OpenKey      HKLM\Software\Intel Corporation\PLSuite\IJLib      NOTFOUND      

Only happens with viewing thumbnails. There's nothing there so...does it makes sense to not look there anymore?      

I know nothing about programs and the registry. All I know is that I have an AMD and INTEL is not on my list.

Media Center Registered 9.1.204 -- C:\Program Files\J River\Media Center\

Microsoft Windows XP  Workstation 5.1 Service Pack 1 (Build 2600)
AMD Athlon 805 MHz MMX / Memory: Total - 196 MB, Free - 43 MB

Internet Explorer: 6.0.2800.1106 / ComCtl32.dll: 5.82 (xpsp1.020828-1920) / Shlwapi.dll: 6.00.2800.1106 (xpsp1.020828-1920) / Shell32.dll: 6.00.2800.1145 (xpsp2.021108-1929) / wnaspi32.dll: N/A
Ripping /   Drive E:   Copy mode:ModeSecure   CD Type:Auto   Read speed:Max
 Drive F:   Copy mode:ModeBurstBigBuffer   CD Type:Auto   Read speed:Max
 Digital playback: Yes /  Use YADB: Yes /  Get cover art: No /  Calc replay gain: Yes /  Copy volume: 32767
 Eject after ripping: No /  Play sound after ripping: No  

Burning /  Drive E: TEAC     CD-W54E            Addr: 1:0:0  Speed:4  MaxSpeed:4  Use MJ Engine:Yes
 Test mode: No /  Eject after writing: Yes /  Direct decoding: Yes /  Write CD-Text: No
 Use playback settings: No /  Normalization: None

[Doof]

I did a quick Google search and came up with this:

IntelŪ JPEG Library v1.5
CPU Type Not Detected Automatically
Symptom: The CPU-type auto-detection code in IJL v1.5 does not work properly. As a result, IJL defaults to blended code for all processors. This means slower performance on some machines.

In order to workaround this problem, you can add a key to the Windows Registry that specifies which processor's code to use.

Workaround: Create the key USECPU key in HKEY_LOCAL_MACHINE\Software\Intel Corporation\PLSuite\IJLib. The value is a DWORD and should be one of the following values:

0 - Blended code (option for all non-Intel processors)

3 - Code optimized for PentiumŪ processor with MMX Technology

4 - Code optimized for PentiumŪ II processor

5 - Code optimized for PentiumŪ III processor

6 - Code optimized for PentiumŪ 4 processor

Based on what I'm reading, and that you have an AMD system, then I'd say no, this missing registry key isn't the source of your slowness. Since it uses Blended by default when it can't find this key, and since it would use Blended even if this key were present, AND Blended is what causes the slowdown... then, adding this key wouldn't really affect that. It might eliminate some of the mulitude of registry accesses, though...

[dragyn]

Thanks Doof! After reading that, I have to agree.

This has been an ongoing problem for a long time. I starteed a thread awhile ago about my system being slow for thumbnails.

I ran another test just a few minutes ago.

I went to 'Start', closed MC. I have 'open at last location' set so when I reopened MC, it went directly to the Start page. This was moving fast (< sec).

Now after that, I immediately hit the X (Close). From that point, it took 4 and 1/2 minutes to close. I wasn't even doing anything at the time.

So what I want to know is: What does MC do when you close it?

There was no HD activity. No registry calling. CPU was HIGH for a long time. Then, CPU was LOW (01-05) for a little bit and HD was active. Then, there was a few registry queries, then it exited.

Something is up and I have no idea. If no one else has complained about it, then it has to be something specific to my system...be it programs installed/what not.

This is my biggest bug/gripe...I wish it would just close and be done with it.

[Doof]

Well, having an AMD system seems to carry an automatic speed penalty with displaying images, since Intel uses its slowest mode for non-Intel systems, and JRiver is evidently using Intel's software for displaying images.

But since you're not even displaying images in the example you give, that doesn't seem to really fit.

Could it be one of those settings about deleting thumbnails on exit or something?

[Matt]

Try this .exe and let us know what it says when closing.

Thanks Dragyn!

http://ftp://ftp.jriver.com/pub/downloads/music/tmp/Media Jukebox.exe

[dragyn]

This is just viewing the 'Start' Page. No actual thumbnail viewing is happening.

Searched for orphan thumbs... (159499 ms -- 89586 files)
Deleted orphan thumbs... (520 ms -- 908 files)

Did it again:
Searched for orphan thumbs... (148203 ms -- 89586 files)
Deleted orphan thumbs... (370 ms -- 908 files)

Same thing.

[dragyn]

I don't have it set to erase them.

Could it be one of those settings about deleting thumbnails on exit or something?

[Matt]

Looks like plugging through the list of 89,000 thumbs is way too slow.

But I wonder why it's trying to delete those 908 files each time.

Also, I wonder if the XP disk indexing is still causing troubles.

Anyway, we'll do some testing and let you know what we find.

Thanks Dragyn.

[Matt]

It looks like Windows doesn't like so many files in one directory.

So, see if this build is any better.  It'll break the thumbs across several directories.  You'll have to let MC rebuild the thumbs after upgrade, because it'll erase the existing ones.

http://ftp://ftp.jriver.com/pub/downloads/music/tmp/Media Jukebox.exe  (beware of the IE cache gotcha)

Let us know if it's any better.  If so, we'll roll this change into 9.1.

Thanks!

[KingSparta]

Looks like plugging through the list of 89,000 thumbs is way too slow.

since fat32 only handles about 14,000+ per folder it should be compatable with that format.

[dragyn]

Thanks Matt!

I'll let ya know what I come up with.

[dragyn]

This exe closes right away but right now I only have about a 1,000 thumbs made.

When I close MC, it shows the time and number of thumbs I have. It doesn't say anything about deleting orphan thumbs.

I'm gonna let MC rebuild them all tonight and then see what it does.

[dragyn]

I don't think that was the fix. I did the same as above (from the start page).

Version 2 -- searched for orphan thumbs... (180ms -- 29913 files)

From the time I hit the X, it took over 2 minutes to display that. It doesn't say how many were deleted though. Also notice the 180ms. Maybe it's seconds? Or maybe the slowdown is before the timer starts?

It just seems like it's stuck somewhere. Any other ideas?

...And what is an orphan thumb anyway? Does it have to search for them? Where are they kept?

Would it be better to keep the thumbs in the same directory as the file? What about a .mjt/.mct/whatever database like explorer does?

Only downside with the current way is if you have more than 1 library with the same file, it creates 2 different thumb images (library directory) for the same file.

Also noticed that thumbnails as individual files take a lot of space considering the cluster size of HDs. I had over a gig of just thumbnails one time.

Stuff to think about. Thanks again for looking into this.

[dragyn]

now it's instant again. I didn't even do anything since the last time I posted.

I'm starting to lose my mind (or have I lost it already and nobody told me?)

[Matt]

An orphaned thumb is a thumbnail for a file that's no longer in the database.  MC won't let them sit around.

About cluster sizing... well it's true that several small files can take more space.  However, in our tests, lots of small files went faster than a few big files.

So, I don't know why it was slow once, but if it stays fast from here out I guess it doesn't really matter.

Let us know if it acts up again.

Thanks Dragyn.

[Jaguu]

Talking about thumbnails another isssue:

I replicated all my data (Drive D:, 50GB) from one pc to another for backup reason. After first replication, it only updates changes. Here I noticed that most of the time is used up for replicating thumbnails - not really necessary as they are built up dynamically.

Would it be possible to specify a thumbnails directory under options, so we can keep it off from valuable data, similar to IE Temporary Files. Could also be a subdirectory of the Music Temp directory. Thank you!

[Matt]

Thumbnails are always under the Data (library) directory.  So just put your library on another drive.

You can also tell MC to erase all thumbs on exit if you like.

[Jaguu]

Thumbnails are always under the Data (library) directory.  So just put your library on another drive.

Not really a good idea, as I want the  library data to be replicated!

You can also tell MC to erase all thumbs on exit if you like.

Why should I do that? There is no real reason for it!

Should thumbnails not be treated like a data cache, separate from other data as it can be rebuilt any time?

[Matt]

Sorry, I'm not understanding.  If you're backing up, there's no reason to backup thumbs.

If you want to move your thumbnails somewhere else, just move the library.  They're always together, but I don't know why that'd be bad.

Thanks Jaguu.

[dragyn]

It seems to be working fine now.

Version 2 -- searched for orphan thumbs... (481ms -- 79265 files)

Thanks for the fix!

[Matt]

Dragyn, that change is in 9.1 now just so you know.

Thanks for helping us get it