Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Album Art Downloader XUI (Read 2035294 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Album Art Downloader XUI

Reply #300
Possible fix for CPU usage while idle: AlbumArtDownloaderXUI-test_cpu_fix.zip.

Could someone who's experiencing CPU usage while idle please try extracting the contents of the above zip over their AAD program folder and letting me know if it has made any difference? My profiling tools say that it theoretically ought to.

Works for me!  It now pretty much stays on 00, occasionally jumping to 01.  That's with it open, but idle.  I said before that caused about ~20% usage, but I tested it again before copying these files over, and it actually was jumping all over the place, sometimes into the 30s.  20% probably was about average, but it was hard to tell, because it was changing so much.

Thanks (again) for your efforts!

Album Art Downloader XUI

Reply #301
i will give that a test tomorrow. i just wanted to chime in to say that if i run this at low priority level it responds how i imagine it should and memory sits around 100MB.

Album Art Downloader XUI

Reply #302
To add to what I reported earlier, after doing a search of a pretty popular album, with all search engines selected, CPU usage again jumps all over the place, as high as into the 30s, even after minimizing.

Just to reiterate, the old version did that even before searching (at least while open - minimizing mostly eliminated it).  The new version uses virtually no CPU even while open, prior to searching.

So it looks like you're on the right track, but in some ways it's worse now (since minimizing no longer helps).

Not complaining;  just reporting.

Album Art Downloader XUI

Reply #303
To add to what I reported earlier, after doing a search of a pretty popular album, with all search engines selected, CPU usage again jumps all over the place, as high as into the 30s, even after minimizing.
Sorry, but just to be clear, do you mean while it is actually searching, or that it stays high after the search completes? (the Stop All link will disappear once all sources have finished searching)

During searching, the CPU usage is expected, but if it is then staying there after the search completes, I'll investigate further.

Alex

Album Art Downloader XUI

Reply #304
Hi Alex,

I have been enjoying this amazing development of AAD XUI.

I have a couple of feature suggestions to increase the quality of the artwork that's downloaded using AAD command line.

/minRes
/squareFactor

Note: These option names are for demonstration only.

For example:

/minRes 600

would filter results to artwork with only Width >= 600 or Height >= 600
So either Width or Height should meet minimum dimensions.

/squareFactor 0.9

could make sure Width is almost close to Height.

squareFactor can be described as smaller dimension divided by the bigger dimension.

If the artwork is 600x593 thne the squareFactor for the artwork is 0.98833333 which is higher than 0.9 (almost square) so this can be included

If the artwork is 403x600 then the squareFactor for the artwork is 0.67166 which is less than 0.9 (not close to a square) so this will be excluded from the results.

squareFactor 1.0 is a perfect square: 500x500, 600x600 etc.

My expectation for AAD to have

Code: [Select]
aad.exe /artist "Artist Name" /album "Album Name" /minRes 600 /squareFactor 0.9


so AAD could filter results to artwork with Width or Height at least 600px and Square Factor at least 0.9

Best Regards,
McoreD

Album Art Downloader XUI

Reply #305
I have a couple of feature suggestions to increase the quality of the artwork that's downloaded using AAD command line.

/minRes
/squareFactor

Thanks for the suggestions. /minRes already exists, but I called it /minSize. It behaves the way you described, though.

/squareFactor sounds like a good idea, I'll probably put that in the next version.

Alex

Album Art Downloader XUI

Reply #306
I have the same result as KarnEvil9, virtually no CPU usage when open AAD and do nothing. But after doing a search and finish, it is again has CPU usage like before in the picture in one of my previous post.

I have a bunch of computers beside my main computer over here:
Athlon X2 4200+ 1GB Vista SP1 using onboard nvidia 6100;
a laptop with 1.7GHz Dothan Pentium M with 512 MB running XPSP2 with 945G onboard graphic;
a T7200 laptop with 2GB RAM Vista SP1 and onboard 965G
all of them run this program adequately. I have a P3 550 256MB RAM with XP on it, too. But I guess I don't need to test this program on it.

@arnymars:
What I meant by that is: if I can not convince you to change your point of view then it'll be pointless to continue talking. I was naive thinking that you would understand as you still kept your false assumption on this software and how a computer should work from my point of view. I'm sorry that my kindness and advice was unaccounted for and directed at the wrong person or any inconveniences that my posts directed to you have caused. Anyway, I will stop talking to you on this case, don't worry and peace.

Album Art Downloader XUI

Reply #307
I have the same result as KarnEvil9, virtually no CPU usage when open AAD and do nothing. But after doing a search and finish, it is again has CPU usage like before in the picture in one of my previous post.

OK, so I'm on the right track then, but not quite there. Try this one: AlbumArtDownloaderXUI-test_cpu_fix_2.zip.

Thanks also for the information on your PCs. The one I find particularly interesting is the Pentium M laptop. The Dothan Pentium M is roughly equivalent in performance to a good P4, I believe (correct me if I'm wrong), and 512Mb would seem to me like a sensible lower limit. I can only assume that if it is running OK on that laptop, but unusable on Mondo's Athlon or anymars' P4 (both also at 512Mb), it's probably down to how much work WPF can offload on to the GPU. I don't really have any experience with the Intel onboard graphics - would you say the 945G was a reasonably good graphics chipset, or more entry-level? anymars is running a GeForce 4, which I don't think support DX9 - which means WPF would have to do most, if not all, of the rendering work in the CPU instead. I can see how that would make a difference.

Alex

Album Art Downloader XUI

Reply #308
Thanks for the suggestions. /minRes already exists, but I called it /minSize. It behaves the way you described, though.

/squareFactor sounds like a good idea, I'll probably put that in the next version.

Alex


Oops.. my bad:

Quote
/minSize    Specifies the minimum size of  (/minSize 300)
              image, in pixels, to use.
              Both horizontal and vertical
              dimensions must conform.
              May be abbreviated to /mn      (/mn 300)


I thought it was fileSize. 

That's GREAT news Alex. Thanks for the fast response! 

Cheers,
McoreD

Album Art Downloader XUI

Reply #309
Alex,

I tested this fix, and it looks very promizing. First AAD window, when open without search terms from within or outside of foobar, draws no CPU resources continuosly whatsoever. When opened with search terms, it stops drawing the resources soon after the search is completed. However, each additional open AAD instance continues drawing CPU resources at 1.5% periodically indefinitely whether empty or showing Search results, while it's active window on the screen. Once passive (you switch to a different program or AAD window), it appears to stop drawing the resources. If none of AAD instances is active on the screen, they all total to 1.5% but only seldom. It's almost perfect in this aspect now, but I feel can be polished a bit. If you are kind enough to give a user without new or any Graphics Card a bit more control over AAD habits in ID3 Tag local search, it will really solve whole this issue for all (as opposed to attempts of simply shutting up users on the forum).

thuan,

I do tend to assemble my own PCs, but also use stock PCs, depending on purpose. I'm well aware of deficiencies of price designed PCs, and CPUs of various generations, even without overclocking. However, this whole "weak PC" issue is irrelevant here, since in my view programs advertized as foobar plugins or helpers should adhere to foobar System Requirements. As well, any program can be improved, as we all know, and bug reports are merely encouragement for this. And on top of this, AAD is a good program.

Album Art Downloader XUI

Reply #310
Sorry, I was wrong that laptop has a 915G, my main computer is the one that has 945G (but I use a dedicated card now). The 915G and 945G are nearly identical just different in clock speed and different vertex shader versions that they support. 945G supports vertex shader 3.0 (915G supports version 2) and a little more powerful in term of raw power as it has higher core clock. They both do not have support for vertex shader and HW T&L in HW that a GF2/4MX or higher have. Performace wise they are POS to be honest, should be lower than a GF4MX440 a DX7 class card even though they are DX9 capable. As for the CPU, yes you're right it should be as powerful as a good P4.
Performance of AAD on this system is of course not as fast as my main computer and the T7200 laptop but still acceptable IMO. On the Athlon X2, it is not much different from my main computer and the T7200, maybe because I haven't used up all of my RAM yet and the CPU is roughly about the same in power.

Also, I have a long standing problem with your program that I told you some time ago, but it seems like you forgot. If I launch a search then another right after and turn off the first one, the 2nd instance (not really as you only have one process) sometimes freezes. This also happens when there're more than 2 windows, if I close one of old ones the newer ones will randomly freeze. It might unfreeze if there's some change in the UI though.

I have tested your new build it's still the same as the previous test build.

EDIT: somehow I kept getting the old binary however I tried, can you rename the zip?

Album Art Downloader XUI

Reply #311
Also, I have a long standing problem with your program that I told you some time ago, but it seems like you forgot. If I launch a search then another right after and turn off the first one, the 2nd instance (not really as you only have one process) sometimes freezes. This also happens when there're more than 2 windows, if I close one of old ones the newer ones will randomly freeze. It might unfreeze if there's some change in the UI though.
Is [a href='index.php?act=findpost&pid=549182']this[/a] the problem you mean? I thought I'd fixed that in 0.14, but it doesn't seem to match your new description exactly. If it's a different problem you are describing, that you reported to me and I failed to acknowledge, then I apologise for missing it. I'll see if I can reproduce it from the description you've given here, but if there are any other details from the original report, please pass those on again.

EDIT: somehow I kept getting the old binary however I tried, can you rename the zip?
OK, it's now AlbumArtDownloaderXUI-test_cpu_fix_2.zip (AlbumArt.exe inside should have a modified timestamp of 2008-04-12 13:00).

However, each additional open AAD instance continues drawing CPU resources at 1.5% periodically indefinitely whether empty or showing Search results, while it's active window on the screen.
If I've understood right, you run AAD, and it's fine. After completing a search, it's fine. Opening a new search window (through the menu?) results in low, but non-zero CPU usage while the new window has the focus? Does closing the new window return usage to zero? I haven't been able to isolate this case in my profiler tool.

I'll see if I can put together a test build that drops the priority of the file browser search to background when the file browser window is minimised (which will also avoid CPU usage rendering the results as they come in), and you can let me know if it makes enough difference to CPU usage to be worthwhile.

Alex

Album Art Downloader XUI

Reply #312
Great job Alex!

All my problems seem solved with zip #2.

When I launch AAD CPU stays at 0-3%; I also tried 3 or 4 searches through foo_run and CPU usage is back to 0 when the search is over (and I have the impression AAD uses less resources than before also when seeking, though I'm not really sure).

Case closed for me.

Alessandro

Album Art Downloader XUI

Reply #313
I reported the freeze problem in this post, the last paragraph. There's nothing more I can say about it though.

About the CPU fix, it really is still the same as the previous one for me.

EDIT: update on the CPU usage problem, it's good on the XP Dothan laptop and not on my main Vista machine (the one with ATI card) whether Aero is on or off. I will try to test the other machines when I can. The T7200 laptop is doing something and that AMD machine is currently in used by other.

Album Art Downloader XUI

Reply #314
update seems to fix the problems. memory usage still sits at about 200M even after doing a few searches and closing all the search windows to just have the file browser open. i suppose running it through foobar would help.. i just need to learn how to do it.
definitely a solid update though!! i've been using it for about an hour now without it really inhibiting my progress at all.
oh yeah, my graphics card is an ati radeon 9600.

 

Album Art Downloader XUI

Reply #315
Opening a new search window (through the menu?) results in low, but non-zero CPU usage while the new window has the focus?

It looks, like any AAD Search window in focus or visible on screen (unobstructed), even a single open one, whether with or without search results, whether open from AAD menu, foobar or Win Explorer, draws 1.5% every 2-3 sec indefinitely without mouse over activity. With more AAD windows open, and one still in focus & several (partially) visible, frequency of CPU usage increases, while staying at 1.5% and slowly going to 1.5-3+% with 6 AAD windows open, no mouse over. Once all windows are out of focus and fully covered by another program window (but not minimized), AAD draws 0% CPU total regardless of number of windows with or withour search results. In focus File or Foobar Browser windows don't draw CPU at all. It all looks like standard intelligent WPF routing, but may possibly be further minimized.

Timely memory release may be another issue to look at. If done correctly, it should be covered by .Net 3.5. "As long as there exists a reference to an object, which might be either a direct reference to an object or via a graph of objects, the object is considered to be in use by the CLR. When there is no reference to an object, and thus cannot be reached or used, it becomes garbage. However, it still holds on to the memory allocated to it. .NET Framework includes a garbage collector which runs periodically, on a separate thread than the application's thread, that enumerates all the unusable objects and reclaims the memory allocated to them."

As to opening windows minimized, as done in this test build, this option is traditionally reserved for a user in Prefs, and not everyone likes it, as AAD performs some entertainment function as well, complementing foobar in that, so attractiveness - nice Covers apear from nowhere - and immediate visual access to Covers feel important.

Album Art Downloader XUI

Reply #316
I reported the freeze problem in this post, the last paragraph. There's nothing more I can say about it though.
Can you tell me if the old windows that you close have currently running searches, or if closing idle windows has the same effect? If it is closing currently running searches, I have added a possible fix for it to Test Build 3.

It looks, like any AAD Search window in focus or visible on screen (unobstructed), even a single open one, whether with or without search results, whether open from AAD menu, foobar or Win Explorer, draws 1.5% every 2-3 sec indefinitely without mouse over activity.
Could you use the tab key to move focus out of the text boxes (for example on to the search button), then leave the mouse outside the window check to see if it is the same? The profiler is telling me that the only area being redrawn on an empty idle AAD search window now is flashing the text-insertion caret in the textbox. I've got to say, it seems unlikely that this will be using 1.5% CPU, but after that, I'm out of ideas.

Timely memory release may be another issue to look at.
Can you be more specific about where? I had a memory leak hunting session at around version 0.7, and while I'm sure the major ones are still plugged (closing a window or clearing search results releases the memory used), there might be minor ones I've missed. I've had a look at the usual suspects, though, and everything seems to be being released when it should be.

As to opening windows minimized, as done in this test build, this option is traditionally reserved for a user in Prefs
I'm not set on using that as a UI mechanism yet. If low-priority file tag scanning goes in at all, there will be some way of indicating that this particular operation should be treated as a background task to run at a low priority (rather than a more general global option). For the moment, minimising the window indicates that it should work in the background. Windows will never be automatically minimised or opened minimised - that will always be a user-initiated action.

Test Build 3 sets the file scanning thread to low priority while the file browser is minimised. Could you try running it and let me know if that reduces the CPU load significantly for you? It doesn't for me, but then it only runs at about 50-60% CPU here anyway, so there's another 40% or so idle CPU time available for other normal-priority threads before it would take share away from the low priority ones anyway.

Alex

Album Art Downloader XUI

Reply #317
Alex, I think you exactly right about the cursor - removing it from the window in focus lives AAD with 0% CPU usage regardless of the number of visible windows with or without search results. Still it looks like WPF overhead, for a cursor to draw 1.5-3% CPU every 2 sec. But this problem seems to be resolved.

Can this Mondo's RAM & CPU report help: "i'm running a 2.17ghz amd athlon with 512MB of ram and the program is almost completely unusable. it opens up at about 30MB of memory and escalates from there until it gets into 400+MB 10 seconds later. interface is almost completely unresponsive, usually i click something and sit there hoping my mouse click went through. i know my computer is pretty outdated, but is the program supposed to be using this much memory?". "Memory usage still sits at about 200M even after doing a few searches and closing all the search windows to just have the file browser open". " if i run this at low priority level it responds how i imagine it should and memory sits around 100MB" ?
I'll try to do more tests a bit later.

Pointers Wiki
Memory Management Reference
.NET Framework Developer's Guide - Garbage Collection
Garbage Collection FAQ

I'm afraid, "low priority" search won't do much from heat standpoint, if there are no other programs running (foobar excluded as it draws very little), so some kind of Application & Resource Throttling approach is needed. Low priority will help to use other programs simultaneously, if one is willing to allow extreme fan noize & PC damage consequences. However, a lot of of people would feel easier, if task throttling is implemented. " The general tuning figure for the threshold limit for processors is 85 percent". Some MS Blogs & Forums are good places to ask.

See also:
.NET Framework Developer's Guide - Managed Threading

This is great and unusual experience for a plugin type program. Despite newer models dominating sales, P4 replacement at many homes is slow, especially in the 3-d world. And everyone loves music, with P2P sharply increasing availability. Foobar is still considered an easy choise for lossless formats playback, despite "unfinished" feel. Having completed music collections with Lyrics and Covers is a great hobby. As I mentioned earlier, most audiophiles would want to find more info about an Album and its Cover, if easy links are provided with found covers. I can't think of another App with such a good fit for this as AAD.

Album Art Downloader XUI

Reply #318
Alex, the freeze issue happens whether the old window is searching or idle. Your latest build doesn't fix it in either case for me. As for the CPU usage problem, it is still the same for me on any of my Vista machine, CPU usage goes wildly again after a search.

EDIT: CPU usage on XP (Dothan) is fine.

Album Art Downloader XUI

Reply #319
Alex, I think you exactly right about the cursor
OK, thanks for letting me know. It's a little disappointing that showing a flashing text insertion cursor uses a measurable amount of CPU, but at least the mystery is solved.

Mondo: "Memory usage still sits at about 200M even after doing a few searches and closing all the search windows"
Yes, that was helpful. It turns out a leak was introduced in 0.11, which I have now managed to track down and eliminate. Test Build 4 should now always release a search window's memory when it is closed.

Thanks for your links. AAD is a fully managed-code application, though, so information about pointers doesn't apply in this case. If anyone is curious, I've found SciTech's .NET Memory Profiler to be invaluable in tracking down managed object leaks (objects expected to be free for garbage collection, but which are still being held on to due to unexpected references to them).

I'm afraid, "low priority" search won't do much
Yeah, I figured it probably wouldn't do much, as it didn't sound like there was anything else competing for CPU at the time, but I thought it might be worth a try, as I was doing a test build anyway. I'll remove it. At least it proves that the file scanning is not taking CPU from anything else that needs it more, just making good use of the CPU resource made available to it.

I appreciate the time you took looking up links on throttling and tuning, but I'm afraid they all seem to relate to server applications, where different priorities apply, and scaling must be taken into account.

This just isn't the case for a single-user desktop application performing a user-initiated foreground task. I'm not going to get into all this again, but suffice it to say, I won't be writing any throttling code.

the freeze issue happens whether the old window is searching or idle. Your latest build doesn't fix it in either case for me. As for the CPU usage problem, it is still the same for me on any of my Vista machine, CPU usage goes wildly again after a search.
Fair enough - if the freeze can occur even when not searching, then the fix I put in to test build 3 wouldn't have had any effect. I'm still trying to find any reason there might be a freeze from closing an idle window, but haven't managed to come up with anything yet, sorry. I'll keep looking, though.

Also, lacking a Vista machine to test on, I'm not sure what I can do about it. If you have the time and patience, you can download WpfPerf (documentation), then using the Perforator tool check to see if the Dirty Rect Addition Rate is non-zero when idle after completing a search. If it is, check the "Show dirty region update overlay" checkbox. Hopefully this will result in some coloured rectangles over whatever area is being re-rendered - if you send me a screenshot of that, I can see if I can figure out why that area might be being re-rendered when it is supposed to be idle.

Of course, I'd understand if you don't want to bother, but I thought I'd mention it anyway, as it's probably the only way to get anywhere with a Vista-only problem.

Alex

Album Art Downloader XUI

Reply #320
Of course, I'd understand if you don't want to bother, but I thought I'd mention it anyway, as it's probably the only way to get anywhere with a Vista-only problem.

As you're willing to help fix the problem, at least I should be able to do that, shouldn't I. It's to improve the program I use after all. Here it is:

The part inside the RED rectangle I drew is the part keep updating after a search. With the rectangle inside the cover sources updates the most, the 2nd in frequency is the search button and the least is the remaining part. When starting up and doing nothing, an inactive AAD window does have Dirty Rect Addition Rate = 0. And here's the data frame inside WpfPerf:

Thank you for taking your time looking into my/users' problems. It's hard to find someone, working on a FOSS project such as this, who is willing to help and tolerant as you.

Album Art Downloader XUI

Reply #321
Wow, 816 dirty rect addition rate! I need a faster pc... :-)

OK, I've had another stab at preventing the sources area from redrawing when it shouldn't. I'm going to assume the Search button redrawing is a side-effect of that, as I can't think of anything that would cause the button to redraw itself. Try Test Build 5 and see if that resolves the problem after performing a search. If it doesn't, could you let me know if any of the sources have "test: true" written under them? They should all say "test:false", if everything is working the way I am hoping.

For the freezing problem, does it still draw the window at all? Or do you get a black or corrupted display? If it is drawing the window, try moving the mouse over Options link, and see if the cursor changes to the hand pointer, and then hover over the sort triangle, and see if a tooltip pops up. If the tooltip does pop up, does the window then become responsive afterwards? How about minimizing and restoring the window, does that unfreeze it? I just need to know if I'm looking at the right effect or not. Does it ever happen if you open new window within AAD itself, rather than using foo_run to trigger it?

Alex

Album Art Downloader XUI

Reply #322
With this new test build, it seems like it even redraws faster after a search, all sources return test:false though. And yes, you're right about the cover sources part is the main problem as only that part is redrawn when AAD is inactive after a search.

I found some new bugs in this test build:
- Do a search and when the search is still taking place, doing another search with the same search term by either click on the search button or press enter inside the text box completely freeze AAD.

- Launh first search, then launch a 2nd search, close down the 2nd window when the first one still searching will completely freeze AAD.

About the freeze issue:
Quote
For the freezing problem, does it still draw the window at all? Or do you get a black or corrupted display?

Yes it still draws the window.
Quote
If it is drawing the window, try moving the mouse over Options link, and see if the cursor changes to the hand pointer, and then hover over the sort triangle, and see if a tooltip pops up. If the tooltip does pop up, does the window then become responsive afterwards?

No, the cursor doesn't change to the hand pointer at any place.
Quote
How about minimizing and restoring the window, does that unfreeze it?

Doesn't do any good in older versions, the latest test build is reponsive afterward though.
Quote
Does it ever happen if you open new window within AAD itself, rather than using foo_run to trigger it?

It happens in either case.

Album Art Downloader XUI

Reply #323
Hmm... Windows Vista progress bars are continuously animated, aren't they? It would seem that they are being animated by WPF even when they aren't visible too. Hopefully this Test Build 6 will finally lay them to rest and stop them animating. If it doesn't, I might need some holy water and a silver stake, just to be sure.

I've fixed the second-search freezing bug in this test build too, thanks for pointing it out.

In this test build I've also tried a couple more ideas to help with the freezing bug from the answers you gave me, so let me know if anything improves there too, please.

Alex

Album Art Downloader XUI

Reply #324
Yes, progress bars in Vista are continuously animated.
Fortunately, it seems like you have brought me holy water and a silver stake. This version seems to work fine CPU usage wise and the freeze issue wise. I only did a few searchs though. I will try more tomorrow. It's late night over here already.

EDIT: Ok, in this version you managed to make everything goes to sleep when searching is finished. "Dirty Rect Addition Rate" does equal zero. There's a small CPU usage (well in a RARE case I have seen it goes nearly to 10% on my Core 2, but haven't encountered this behavior again) in AlbumArt.exe thread, as shown in Process Explorer, happens SOMETIMES whether the windows are active, inactive or minimized, though. If you're willing to continue investigating, I'm able to help, too.

Another small problem, when changing the Album search string (mostly delete some unnecessary words, it's not a new search string so most of the time AAD uses the old window) and do a search again during the original search is taking place, the GUI may temporary freeze. It will be reponsive soon though with the same trigger as in previous freeze problem. Other than this, the GUI doesn't freeze now.

EDIT2: It seems like I found out the cause of the freeze issue I talk about above. It only happens either when you stop the search using the stop all button or do another search that satisfies certain criteria making it happen in the current search window. IOW, when user stops a search it causes AAD to freeze.