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 2049715 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Album Art Downloader XUI

Reply #575 –
Wow, thanks for your detailed analysis and post! I will look into this crash in detail with the information you've provided, but here are some answers for you now:

[quote name='Akkurat' post='594539']Please show the progress bar for these sources when doing the size detecting/sort for "unknown" size images.[/quote]The progress bar is for the source finding the results. The automatic download of full size images runs separately, and simultaneously, so making it affect the same progress bar will be tricky. You can even turn on automatic download after all sources have already completed searching, so the progress bars will already have been removed.

Would a separate progress bar showing the automatic full size image downloading progress be helpful? That could be accurately calculated and displayed, then you would know when the list won't be re-sorting any more.

It might be helpful to know that while the mouse is down on the scrollbar, the list will not update (resort or have new items added), so if you want to look through what you've got right now without it changing under you, you can drag the scrollbar up and down without releasing the mouse to do so.

[quote name='Akkurat' post='594539']I downloaded v0.23.1, the program shows 0.23 everywhere (script compile window, about window, file version)?[/quote]0.23.1 was primarily a fix to the installer, and I did not update the version number in the app. Probably should have done, but I was in a big hurry to get something up there that wouldn't crash out on first install. It will automatically be resolved for the next version, of course!

[quote name='Akkurat' post='594539']IMHO it would be nicer to NOT active the drag&drop when holding down mouse button and previewing the big image. It seems that there's about 5px range for the d&d action to become active.. maybe increasing the range would suffice? (if that's possible)[/quote]Possible, sure, but I'm not sure what sort of range to make it. Is it just to eliminate wobbly-mouse problems, or is there some reason to be moving the mouse around while previewing? It's going to be tough to know when to initiate a drag.

[quote name='Akkurat' post='594539']I like the previous behavior more; the big image preview is showed and no re-sort to the list.[/quote]That wasn't intentional, thanks for bringing it to my attention - I'll fix that.

[quote name='Akkurat' post='594539']Have you looked into the "window size not retained after updating" issue? I didn't see this in the SF tracker.[/quote]I don't remember fixing it, so I'll assume it isn't fixed, and add it to the tracker.

[quote name='Akkurat' post='594539']Can you please use the same update list both in this thread and in the "File Release Notes and Changelog" in sourceforge (+wiki)?[/quote]Different format, so can't use the actual same list. Apologies for not keeping them in better synch though. You may have noticed that documentation isn't my strongest area.

[quote name='Akkurat' post='594539']Why is the SF download page showing "Download Album Art Downloader XUI v0.23 installer" text/link even if that link downloads the 0.23.1?[/quote]Same reason as the app version showing 0.23. The .1 is just a nasty little footnote in history that shouldn't have happened, and the sooner we can forget about anything below 0.minor, the better :-)

...continued

...continued

[quote name='Akkurat' post='594539']Does the filebrowser scan FLAC (or any other) tags for covers?[/quote]For embedded covers? No. This app doesn't read or write embedded covers. It will read FLAC tags for the album and artist name, if that's what you mean. It will only do one of tags or filenames at a time, though, you can't search for both simultaneously.

[quote name='Akkurat' post='594539']I also noticed that it doesn't detect my "_folder.jpg" cover files[/quote]Add "|_folder.%extension%" to the end of the Specify Path to Find Images box in the file browser.

[quote name='Akkurat' post='594539']Filebrowser: wouldn't it be better to detect VA albums as just one album and not list all of the artists from it?[/quote]This has been covered in detail in previous posts. Basically, Various Artists can't be reliably detected in a standard way, so unless you are using File Path Pattern matching, and they're all in the same folder, AAD doesn't know they are all part of the same album.

[quote name='Akkurat' post='594539']Sometimes the "name:, size:, type:, etc." field "labels" are not visible for some of the search result items until I press the search again.[/quote]I haven't been able to reproduce this, but I'll try again after fixing the other bugs mentioned.

[quote name='Akkurat' post='594539']It seems that the sort is made only to the first dimension of the cover image, e.g. all images with 500px width are not additionally sorted by height.[/quote]Yes, that's true. I'll put that one down as a feature request, I think.

[quote name='Akkurat' post='594539'][/end bitchin.., I mean debugging]  Maybe I should de-bug-off myself. [/quote]Your efforts with putting together this information are appreciated!

Alex

Album Art Downloader XUI

Reply #576 –
OK, thanks to some great detective work by Akkurat, I think I've fixed the crashes reported. If you'd like to help me test this out, I've put up a debug build here: AlbumArt.exe (just drop it over the existing one in your program folder). I'd appreciate it if those of you experiencing the crash could let me know if this fixes it.

Oh, and Akkurat, in all those replies I made, I think I missed one:

The reason the filtering behaves the way it does (apart from the crashing, which should be fixed), is that if the full size image size is not known, then it filters on the size of the thumbnail, the theory being that if the thumbnail is over 50px big, then the full size image is going to be too. I appreciate that this might be confusing, though - it might be more clear to exclude unknown sized results from any filtered result set regardless of thumbnail size.

Alex

Album Art Downloader XUI

Reply #577 –
OK, it works fine now; getting an assertion error with "Rate Your Music", though:

Quote
Script Rate Your Music threw an exception while searching: Der Remoteserver hat einen Fehler zurückgegeben: (500) Interner Serverfehler.





    at ScriptSource.SearchInternal(String artist, String album, IScriptResults results) 

    at Source.SearchWorker(Object state) 

    at ThreadHelper.ThreadStart_Context(Object state) 

    at ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) 

    at ThreadHelper.ThreadStart(Object obj)


Seems to be on their server.
audiophile // flac & wavpack, mostly // using too many audio players

Album Art Downloader XUI

Reply #578 –
Quote from: tuxman on
OK, it works fine now; getting an assertion error with "Rate Your Music", though:
Yeah, you can safely ignore assertion errors - they are silently dropped in release builds, but are shown in debug builds. Scripts, and the sites they depend on, can be fairly sketchy, so these things do pop up.

Thanks for letting me know the crash seems to be gone, though!

Album Art Downloader XUI

Reply #579 –
I'll answer this quickly, I'll get back to those other topics tomorrow.

Quote from: AlexVallat on
I'd appreciate it if those of you experiencing the crash could let me know if this fixes it.

Still crashes.  Both test cases I wrote. Thou differently this time; no error log and with an error message window with text:
"Album Art Downloader has encountered a problem and needs to close.  We are sorry for the inconvenience.
If you were in the middle of something, the information you were working on might be lost."


Quote from: AlexVallat on
The reason the filtering behaves the way it does (apart from the crashing, which should be fixed), is that if the full size image size is not known, then it filters on the size of the thumbnail, the theory being that if the thumbnail is over 50px big, then the full size image is going to be too. I appreciate that this might be confusing, though - it might be more clear to exclude unknown sized results from any filtered result set regardless of thumbnail size.

Ok, I understand to some point what you're saying, it's a bit confusing as you said. Your suggested behavior makes more sense but there's a pitfall: if the "automatically download" is set to never, user might miss some covers because there's a possibility to get confused of the settings.. I don't know, maybe my brains are not working at the moment, the more I try to think about it, the more I get confused. There, you see? I got very Konfutsed.

Off the top suggestion: make the change as you suggested AND put a "show unknowns" checkbox into "filter size" "group" and disable (greyed out) it unless the "automatically download" setting is set to "never"...?

Album Art Downloader XUI

Reply #580 –
Quote from: macman4hire on
A note to the developer check out the following link AlbumArtExchange.  This site has some of the best quality album covers on the web.  You may want to consider offering it as a selection choice in your application.  Why not give your users the best quality that is out there.

I'd also like this. Maybe someone has the ability to write a script for it?
Can't wait for a HD-AAC encoder :P

Album Art Downloader XUI

Reply #581 –
Quote from: odyssey on
Quote from: macman4hire on

A note to the developer check out the following link AlbumArtExchange.  This site has some of the best quality album covers on the web.  You may want to consider offering it as a selection choice in your application.  Why not give your users the best quality that is out there.

I'd also like this. Maybe someone has the ability to write a script for it?

Does no one actually read my replies here? A script for Album Art Exchange was added back in version 0.16, and was updated in version 0.20 when they started providing an API. Please update to the latest version, and you should find it available there.

Album Art Downloader XUI

Reply #582 –
Quote from: Akkurat on
Still crashes.  Both test cases I wrote. Thou differently this time; no error log and with an error message window
Huh. I wasn't expecting that. How about the problem where the list would update while the preview was being shown, does that still happen? The other crashes seemed to be caused by the fact that the code to suspend updates to the list was broken (which of course also stopped the list being suspended while the preview was shown). I've fixed that up, and the list updates should be being suspended properly now. If it's suspending, but still crashing, I've got to come up with another idea.

For the filtering, I think I'm going to have it so that  Unknowns are never filtered out. At least that way you know they are there, and can choose to ignore or download them as you please. If automatically downloading, as they are downloaded they might then become filtered out, if they don't meet the criteria.

Album Art Downloader XUI

Reply #583 –
Quote from: AlexVallat on
Quote from: Akkurat on
Still crashes.  Both test cases I wrote. Thou differently this time; no error log and with an error message window
Huh. I wasn't expecting that.
Can't you reproduce the crash with the steps I gave? Strange.

In case you didn't understand the German version of the error log, here it's in English (note: this is from the 0.23.1 version, not from the debug version!):
Code: [Select]
Album Art Downloader has encountered a fatal error, and has had to close.
If you wish to report this error, please include this information, which
has been written to the file: C:\Program Files\AlbumArtDownloader\errorlog.txt

App version: 0.23.0.0, running on Microsoft Windows NT 5.1.2600 Service Pack 2

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
   at System.Collections.ArrayList.RemoveAt(Int32 index)
   at System.Windows.Data.ListCollectionView.ProcessCollectionChanged(NotifyCollectionChangedEventArgs args)
   at System.Windows.Data.CollectionView.OnCollectionChanged(Object sender, NotifyCollectionChangedEventArgs args)
   at System.Collections.Specialized.NotifyCollectionChangedEventHandler.Invoke(Object sender, NotifyCollectionChangedEventArgs e)
   at System.Collections.ObjectModel.ObservableCollection`1.OnCollectionChanged(NotifyCollectionChangedEventArgs e)
   at System.Collections.ObjectModel.ObservableCollection`1.RemoveItem(Int32 index)
   at System.Collections.ObjectModel.Collection`1.Remove(T item)
   at System.Collections.ObjectModel.Collection`1.System.Collections.IList.Remove(Object value)
   at AlbumArtDownloader.Controls.ArtPanelList.OnImageSizeChanged(Object sender, EventArgs e)
   at AlbumArtDownloader.AlbumArt.SetImageDimensions(Double width, Double height)
   at AlbumArtDownloader.AlbumArt.<>c__DisplayClass7.<RetrieveFullSizeImageWorker>b__6()
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
   at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
   at System.Delegate.DynamicInvokeImpl(Object[] args)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Boolean isSingleParameter)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler)
   at System.Windows.Threading.DispatcherOperation.InvokeImpl()
   at System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(Object state)
   at System.Threading.ExecutionContext.runTryCode(Object userData)
   at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Windows.Threading.DispatcherOperation.Invoke()
   at System.Windows.Threading.Dispatcher.ProcessQueue()
   at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
   at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Boolean isSingleParameter)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Boolean isSingleParameter, Delegate catchHandler)
   at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Boolean isSingleParameter)
   at System.Windows.Threading.Dispatcher.Invoke(DispatcherPriority priority, Delegate method, Object arg)
   at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
   at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
   at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
   at System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame)
   at System.Windows.Threading.Dispatcher.Run()
   at System.Windows.Application.RunInternal(Window window)
   at System.Windows.Application.Run(Window window)
   at System.Windows.Application.Run()
   at AlbumArtDownloader.App.AlbumArtDownloader.IPriorInstance.Run()
   at AlbumArtDownloader.InstanceMutex.RunAppAsServiceHost(IPriorInstance instance, String channelUri)
   at AlbumArtDownloader.App.Main(String[] args)
What I understand is that your code crashed because it tried to access an array index which was not there anymore. I'd guess that this is due to the fact that the filter removes covers from the result list and the process for getting the full size images ("RetrieveFullSizeImageWorker" perhaps?) tries to read an array index which was removed because of the filter. So, if you make the change to never filter out the "Unknowns" in the results list/window, I bet that the crash goes away.. or it might not.. or it could bring more problems (wrong index/image get).. it would be wise to check out that the "get full images" process always tries to access the correct index, which could have been moved or removed.. that is if the processes are run in parallel (the "update result list" & "get full"). Do I make sense at all or am I talking rubbish? I could be wrong.. considering that this "black box" testing I'm doing is pretty hard.

Quote from: AlexVallat on
How about the problem where the list would update while the preview was being shown, does that still happen?
It's fixed. Thou honestly I still hate the fact that the cover is re-sorted (if it was different size) after I let the preview close. BUT, it's consistent now and no freezes so I guess I've to live with that. With big lists you could lose the position of the cover you were previewing. Although you could consider using, in example, a color indication (colored border on the image, put a transparent green "correct" image over the image (you could use a transparent disk image in same way for saved covers), etc.) whether the preview has been opened or not. This would make browsing much clearer, i.e. you instantly see which covers you've already checked.

In addition, it would be nice to have indicators for covers I've clicked to show the full size image in background (letting go of the preview window) when those are fully loaded. Now it only shows the "search" image in the left-top corner. A "search/download complete" image would be nice. This would also enhance the usability a lot. E.g. I always check many full size images and when they're big, the loading takes a while, and I like to open many "background full images", but it's hard to detect which images I chose when the full size image is ready.

Quote from: AlexVallat on
For the filtering, I think I'm going to have it so that  Unknowns are never filtered out.
Good call. Maybe the best solution here.

Album Art Downloader XUI

Reply #584 –
No, I can't reproduce it using the steps you gave me, not in the fixed debug version I put up.

The crash report there (in English or in German) is the same one as tuxman had, that seem to be resolved now for him.

In case you're interested, the cause behind it was due to a failure of the system for suspending updates to the results list. When the list is suspended, it is supposed to batch up additions and removals, then when the list unsuspends, play them back so that the UI can update itself. Further, when an image size changes, that result is removed and re-added to the list so that it gets placed in the correct position. Unfortunately there is no nicer way to convince the WPF control to re-order its contents than removing and re-adding them.

So, you can probably see where this is going now; the full size image would download, triggering a size change, which would be badly batched up by the suspended change system, then replayed incorrectly, causing it to replay the removal (prior to the subsequent immediate re-addition) of the changed item incorrectly, confusing the WPF list control which was being told that a non-existent item had been removed.

Anyway, that's all just for curiosity's sake, that particular problem is definitely resolved now, so if there is something else causing a crash for you, I've got to look elsewhere. You say you are finding it tough doing black-box testing - if there's anything I can do to make things easier for you in this regard, please do let me know!

I take your point about the item moving once you finish previewing. I'm going to see whether it is possible to scroll the list so that after you release the mouse, and it updates, the list is scrolled so that the result you just previewed is still visible. It might not be in exactly the same spot, but you should at least be able to see it.

I like the suggestion for indicating which images are full sized and which are not. I tend to to this just by looking at them - the fuzzy ones aren't full sized! I'll see what I can think up, UI-wise, to indicate this in a non-obtrusive way. I don't think an overlay is the best way to go, though - I'd like to keep the actual image unchanged.

Some good news for you, I think I've got window size and position settings upgrading working for 0.24.

Album Art Downloader XUI

Reply #585 –
Quote from: AlexVallat on
Wow, thanks for your detailed analysis and post!

Wow, you weren't disheartened by my massive post.  I've to confess that I've been couple of times in the REACT thread with big posts.. sometimes too much is just, well, too much.

Quote from: AlexVallat on
The progress bar is for the source finding the results. The automatic download of full size images runs separately, and simultaneously, so making it affect the same progress bar will be tricky. You can even turn on automatic download after all sources have already completed searching, so the progress bars will already have been removed.

Would a separate progress bar showing the automatic full size image downloading progress be helpful? That could be accurately calculated and displayed, then you would know when the list won't be re-sorting any more.

Well, when you're right, you're right, the idea to use the source progress bar was not good. What you suggested sounds absolutely marvelous! Maybe a popup (since you don't have status bar) progress bar at the bottom of the results window?

Quote from: AlexVallat on
Quote from: Akkurat on
IMHO it would be nicer to NOT active the drag&drop when holding down mouse button and previewing the big image. It seems that there's about 5px range for the d&d action to become active.. maybe increasing the range would suffice? (if that's possible)
Possible, sure, but I'm not sure what sort of range to make it. Is it just to eliminate wobbly-mouse problems, or is there some reason to be moving the mouse around while previewing? It's going to be tough to know when to initiate a drag.

Yes, it would be just for eliminating wobbly-caffeinedeprivation-mouse problems.  10-20px?

Quote from: AlexVallat on
Quote from: Akkurat on
Can you please use the same update list both in this thread and in the "File Release Notes and Changelog" in sourceforge (+wiki)?
Different format, so can't use the actual same list. Apologies for not keeping them in better synch though. You may have noticed that documentation isn't my strongest area.

Yeah, I meant in sync, not the format. Show me a coder who IS good at documentation, I'm crap at it and I hate it soooo much.  Coding my REACT mod, I've learned always to write down a documentation/changelog (if needed) for a particular update/change/new feature I just have coded. This way the documentation process doesn't get too boring, baby steps, baby steps to open the changelog, etc.

Quote from: AlexVallat on
Quote from: Akkurat on
Sometimes the "name:, size:, type:, etc." field "labels" are not visible for some of the search result items until I press the search again.
I haven't been able to reproduce this, but I'll try again after fixing the other bugs mentioned.

Ok, I hope I found the way to reproduce this; do a search (any search), then minimize the cover "area" until the labels drop off, then press search again = labels are back. It doesn't matter if you're showing the info below or on the side.

Remember that sometimes, for some of the result list covers, this happens after searching (no resizing of the result cover areas).

Actually now when I look at the "on the side view" without the labels, I kind of like it better. The info is pretty self-explanatory, so maybe the labels could be turned off from settings? Jésus, it seems that I'm full of ideas/suggestions at the moment, sorry. Pick out the best (if any) if you like.

Quote from: AlexVallat on
Your efforts with putting together this information are appreciated!

Your lightning fast replys and fixes are very much appreciated!! Thanks.

Album Art Downloader XUI

Reply #586 –
Quote from: Akkurat on
Well, when you're right, you're right, the idea to use the source progress bar was not good. What you suggested sounds absolutely marvelous! Maybe a popup (since you don't have status bar) progress bar at the bottom of the results window?
Hah, great minds... from the upcoming 0.24:



I've also increased the drag start size, and some informal playing about with it seems to show that 32px works well enough.

Quote from: Akkurat on
Ok, I hope I found the way to reproduce this; do a search (any search), then minimize the cover "area" until the labels drop off, then press search again = labels are back. It doesn't matter if you're showing the info below or on the side.
Got it, thanks. Issue added to the tracker for this.

Album Art Downloader XUI

Reply #587 –
Maybe I just didn't read the FAQ/manual/etc closely enough, but when "automatically download..." is enabled, does it actually save the files, or just store them in temp?

Album Art Downloader XUI

Reply #588 –
Quote from: Zarggg on
Maybe I just didn't read the FAQ/manual/etc closely enough, but when "automatically download..." is enabled, does it actually save the files, or just store them in temp?
They are just stored in memory until the window is closed. Nothing is automatically saved to file using this option.

Album Art Downloader XUI

Reply #589 –
Excellent!

Album Art Downloader XUI

Reply #590 –
Quote from: AlexVallat on
No, I can't reproduce it using the steps you gave me, not in the fixed debug version I put up.

The crash report there (in English or in German) is the same one as tuxman had, that seem to be resolved now for him.

It would be interesting to see if tuxman passes the two cases I wrote down. EDIT: I just PM'd tuxman.

Quote from: AlexVallat on
..so if there is something else causing a crash for you, I've got to look elsewhere.

Unfortunately. Tell me what to do. The crash happens exactly the same but instead of errorlog, I got error window. Put lot's of debug points and send me the exe.

Quote from: AlexVallat on
You say you are finding it tough doing black-box testing - if there's anything I can do to make things easier for you in this regard, please do let me know!

No no, I've no interest to throw myself into learning your code, would take too much time to even understand a small bit of your codebase. I merely covered my ass if my guess for the problem would be wrong.

Quote from: AlexVallat on
I take your point about the item moving once you finish previewing. I'm going to see whether it is possible to scroll the list so that after you release the mouse, and it updates, the list is scrolled so that the result you just previewed is still visible. It might not be in exactly the same spot, but you should at least be able to see it.

Hmm, couldn't you just ignore the change for those covers resort-wise? Didn't the previous versions work like this?

Quote from: AlexVallat on
I like the suggestion for indicating which images are full sized and which are not. I tend to to this just by looking at them - the fuzzy ones aren't full sized! I'll see what I can think up, UI-wise, to indicate this in a non-obtrusive way. I don't think an overlay is the best way to go, though - I'd like to keep the actual image unchanged.

That's not actually what I meant, I meant that indicate which full size images have been loaded from net after clicking to show the preview and letting the preview close before the image has been loaded. The "search" icon overlay on top of the small image (not the preview image "window/dialog") shows nicely what images are being fetched, BUT, when they're fetched there's no indication of that.. and if you clicked many images to load the full sized images in the background, you have a very hard time knowing which ones you did click. Add the resort feature for changed sizes images, and you're totally lost which ones you put into "download mode". I hope you understand what I mean.

Fuzzy ones are impossible to detect in side view with small images. I guess you have bottom view and a big stretched cover area so that the images are huge.

Quote from: AlexVallat on
Some good news for you, I think I've got window size and position settings upgrading working for 0.24.

It's unbelievable how fast you work, I just peeked in the SF tracker & SVN repo and started to worry about your Real Life™.  And mine too, this takes so much time.. but it's for good cause.. and I benefit from this also.

BTW. Is it possible to include AAD XUI in my REACT mod release in the future? I've some plans (actually my ToDo list is huge) to update the mod in near future. Though I've to fix many things in config files and in the REACT code before I could put XUI to the rel.. but nonetheless I thought to ask now since it popped into my mind.

Album Art Downloader XUI

Reply #591 –
I think I've come up with something reasonably nice for indicating which of the results have full sized images already downloaded. I'm now displaying the image dimensions greyed until a full sized image has been downloaded, which suggests that these dimensions aren't confirmed yet, and are only an estimate provided by the source. (In fact, for some of the scripts, they're even worse - just a usual size of image returned by that source!) Once the full size image is downloaded, the image size appears black like the other information.

That should make it quick to tell at a glance which ones have full size images downloaded already.

Here's a link to a compiled version of the current state of 0.24 (note to others - this does not represent the final 0.24 - you can download this if you like, but it is unsupported and unfinished). If that one crashes, it should at least provide an error log. AlbumArtDownloaderXUI-0.24.zip.

Yes, you are welcome to include AAD XUI in your REACT mod. Send me a link when you do, I'd be interested to see it in use!

Album Art Downloader XUI

Reply #592 –
Quote from: alsaan on
As for the buy.com script: sure, you can include it in the next release.
I've made a few changes to it and added cover type support (which wasn't very hard to do)
Here is the latest version: http://alsaan.iespana.es/buy-com.boo
I'm about to include this in version 0.24, but before I do, is there any chance you could make it provide thumbnail images? It does help a lot with the search responsiveness. If it really can't be done, then just leave the full sized image parameter of the Add call as null, so it just uses the thumbnail as the full sized image rather than re-downloading it a second time.

Alex

Album Art Downloader XUI

Reply #593 –
Quote from: AlexVallat on
I think I've come up with something reasonably nice for indicating which of the results have full sized images already downloaded. I'm now displaying the image dimensions greyed until a full sized image has been downloaded, which suggests that these dimensions aren't confirmed yet, and are only an estimate provided by the source. (In fact, for some of the scripts, they're even worse - just a usual size of image returned by that source!) Once the full size image is downloaded, the image size appears black like the other information.

That should make it quick to tell at a glance which ones have full size images downloaded already.

The crashes went away, yea!

But, infamous but, now the unknown images which become "known" and are in example, below the minimum filter px, are NOT removed from the list.  After all searches and full-size image downloads are over, I've to re-apply the minimum filter setting for it to become effective. + sort also fails with these results. Crap. Actually I just noticed that it sorts some of the covers, not all.

Steps to reproduce both problems:
1) set download when unknown
2) set minimum filter 600px
3) set group by source (just in case this affects too)
4) set sort by size desc
5) select ONLY "LastFM Artist" source (limit to 40)
6) search metallica / metallica

= minimum filter has no effect
= notice that the first (at least in the beginning of the "download full sizes") 2 covers detected (in my search this happens this way) are 1000px wide and placed at the top. When the "download full" continues, smaller than 1000px wide images are NOT sorted.. then about in the middle there comes 2 covers with 1424 width and they ARE placed at the top before the 2 1000px wide covers. Strange. Maybe the first result is used as the "base" in all comparisons? It would explain the behavior I'm seeing.


Discogs source shows image sizes in grey even if they really are full sized straight from the get go. Not a big problem, I just thought to mention this. Were there other sources too with no thumbnails?

One new thing, sorry, when after the first search, you add more sources and click search again, the "stop all" doesn't popup anymore. Only after you change the search artist &/ album.

new progress bar = fabulous
image size grey -> black text = ok
drag&drop area = ok

Were there more fixes/changes? (sort asc/desc fixed, others?)

And yes one thing more; I noticed that the "download unknowns" gets only 1 image at a time including all sources. If the download stagnates for one source, it could get really boring to wait for all of the covers in the queue to finish. I already saw this happen almost everytime I did my tests with the above problems. This could get complicated, but could you change it so that it gets only 1 image at a time PER source? This way one stagnating source doesn't affect all.

I hope you're not getting tired with me.

Quote from: AlexVallat on
Yes, you are welcome to include AAD XUI in your REACT mod. Send me a link when you do, I'd be interested to see it in use!

Thanks, I will. Though people are already using AAD XUI with REACT, it's just that REACT doesn't support it fully at the moment (limited support for other than .jpg's (only jpg's in the "original" AAD) -> some encoders crash, etc. bugs/problems).

Album Art Downloader XUI

Reply #594 –
Quote from: AlexVallat on
Quote from: alsaan on
As for the buy.com script: sure, you can include it in the next release.
I've made a few changes to it and added cover type support (which wasn't very hard to do)
Here is the latest version: http://alsaan.iespana.es/buy-com.boo
I'm about to include this in version 0.24, but before I do, is there any chance you could make it provide thumbnail images? It does help a lot with the search responsiveness. If it really can't be done, then just leave the full sized image parameter of the Add call as null, so it just uses the thumbnail as the full sized image rather than re-downloading it a second time.

Alex

Ok, I followed your suggestion and made some performance improvements: http://alsaan.iespana.es/buy-com.boo
It's still a bit slower than I'd like, but it will do the job for now.

Album Art Downloader XUI

Reply #595 –
Quote from: Akkurat on
now the unknown images which become "known" and are in example, below the minimum filter px, are NOT removed from the list.
I wasn't able to reproduce this. Following the steps you gave resulted in exactly correct behaviour. As each Unknown image was downloaded, it was removed from the list, with the exception of two results at 1000px width, and two at 1424px width. These were sorted in the correct order.

I'm guessing the reason that the images smaller than 1000px are sorting incorrectly for you is that they aren't supposed to be there at all (should have been filtered out), and are therefore not being sorted at all.

Are you clicking on any preview images, or scrolling during the search? Do you have a maximum filter turned on? Anything else you can think of we might be doing differently?

Quote from: Akkurat on
Discogs source shows image sizes in grey even if they really are full sized straight from the get go
You know that, and I know that, but AAD has no way of knowing that the size is accurate until it tries to get a full size image for them, and is told by the script to just use the thumbnail.

Quote from: Akkurat on
One new thing, sorry, when after the first search, you add more sources and click search again, the "stop all" doesn't popup anymore.
Tracker added - I'll look into that.

Quote from: Akkurat on
Were there more fixes/changes? (sort asc/desc fixed, others?)
Also: Window Size and Position should have been upgraded, the popup preview should ensure that the previewed image is brought into view when it closes, and the information label re-appearing should have been fixed.

Quote from: Akkurat on
could you change it so that it gets only 1 image at a time PER source?
Not really. The full sized image download worker is a low-priority background thread that crawls over all the results downloading the full sized images when appropriate. Having one thread per source would be a major architectural change that I won't be doing any time soon.

What I could do would be to add an option for each source (next to the Limit Results option) to ignore thumbnails for that source and download full size images right from the start. That way they'd be downloaded as part of the initial search, in that plugin's search thread. Would that be any use?
 

Album Art Downloader XUI

Reply #596 –
Quote from: AlexVallat on
I wasn't able to reproduce this. Following the steps you gave resulted in exactly correct behaviour. As each Unknown image was downloaded, it was removed from the list, with the exception of two results at 1000px width, and two at 1424px width. These were sorted in the correct order.

I'm guessing the reason that the images smaller than 1000px are sorting incorrectly for you is that they aren't supposed to be there at all (should have been filtered out), and are therefore not being sorted at all.

Are you clicking on any preview images, or scrolling during the search? Do you have a maximum filter turned on? Anything else you can think of we might be doing differently?

No maximum filter, not doing anything while searching & downloading full size images. You're right about the reason why some of the images are not sorted, so the situation now is that only the filter isn't working.

I tested this problem with WinXP SP2 in MS Virtual PC, just normal windows install with all the latest updates (-this month updates), installed .NET3.5 = same thing, filter doesn't work.

Can you test this with some other computer which doesn't have your IDEs, SDKs and such dev. tools? I find it odd that this doesn't work in "vanilla" WinXP.

Quote from: AlexVallat on
You know that, and I know that, but AAD has no way of knowing that the size is accurate until it tries to get a full size image for them, and is told by the script to just use the thumbnail.

Ok, just as I thought.

Quote from: AlexVallat on
Also: Window Size and Position should have been upgraded, the popup preview should ensure that the previewed image is brought into view when it closes, and the information label re-appearing should have been fixed.

Works. Excellent.

Quote from: AlexVallat on
What I could do would be to add an option for each source (next to the Limit Results option) to ignore thumbnails for that source and download full size images right from the start. That way they'd be downloaded as part of the initial search, in that plugin's search thread. Would that be any use?

I guess yeah, more features is good I guess.. thou it could confuse some users since there's the "download full size images : never" option. Maybe the functionality AAD has now is good enough (regarding this topic ).


New thing again: the "LastFM Artist" source returns some images twice. It seems that this happens with images which have the same link as the image below as a text link (jsus, does that make sense? English is sometimes hard).. look at this example gallery (http://www.last.fm/music/Corduroy/+images), the last image is the only one that has an extra link to the picture underneath it (text: l_af929402e4888ea54bd..), and if you search "corduroy" in AAD, only that image is listed twice.

Album Art Downloader XUI

Reply #597 –
Quote from: Akkurat on
Can you test this with some other computer which doesn't have your IDEs, SDKs and such dev. tools?
No, I'm afraid not. Even if I could, it might not be that much help if I can't reproduce it with a debugger available.

Just once thing occurs to me, in the environments you tested in, was it .net 3.5 SP1? or plain 3.5?

Weird about that LastFM artist thing, I wonder why they've got that junk text link under the picture. I'll tweak the script to ignore it.

Album Art Downloader XUI

Reply #598 –
First, I'll vent out, I hate Micro$oft & I hate .NET even more after this. Thanks MS and your .NET POS and it's versions that are NOT (or should I say .NOT) versions, etc. crap (e.g.: after updating to 3.5 SP1, your existing 2.0 SP1 & 3.0 SP1 .NETs are updated to SP2 (these are NOT available separately, only with 3.5 SP1)... yeah, makes perfect sense.).

As you may have already guessed, the problem is solved. Installing .NET 3.5 SP1 to my VPC Win image solved it... at least in VPC image, I don't have the time or opportunity to install it on my "main" system at the moment because I "can't" reboot now (only hibernate).. but I'm sure it will work there too.

I didn't know that 3.5 SP1 was out, windows update (website, not the systray popup crap) doesn't offer it (all previous updates have been there), released on 8/11/2008, couple of months ago but still not in win update. Thumbs up MS, great work. One funny thing more: if you download just 3.5 ("bootstrapper"), the filename is "dotNetFx35setup.exe", guess what filename is used with 3.5 SP1? Yes, same "dotNetFx35setup.exe". -b Same thing with full setup downloads. Filename description & product name say that it's "Microsoft .NET Framework 3.5", the only way to know that it's SP1, is to "know" that the file version "3.5.30729.1" is the SP1.  It's so terrible that you can only laugh. Well, MS is known for poor versioning, but this time they stepped into big pile of.. eh pudding.

@Alex: So, it seems that you have either just upgraded to SP1 or started to use new features from it in AAD. I bet that you like .NET less after this.  Is there tools available to .NET IDE to track framework requirements of written code? Maybe it would be best to automatically push AAD users to new framework versions if you upgrade.

Btw. remember to update the first post link to the SP1.. and put up reminders everywhere.

Aaaannndd, one thing more.. it seems that this never stops.  I've now noticed couple of times that sources sometimes gets more images than the limit is. E.g. last search to "Darktown" returned 11 images (all different) while the limit is 10. Again, I've to say that this is not a biggie, and I've only seen, IIRC, 1 or 2 images over the limit. Nonetheless, I thought to report this so that you can keep an eye out for this. Small test: 10 searches, 2x 11 results (no filters used).

Album Art Downloader XUI

Reply #599 –
Yeah, they've really dropped the ball on that one. I upgraded to SP1 some time ago, actually. I can't remember exactly when, but I would have thought at least version 0.22 would have been compiled under it.

Anyway, I haven't used any new features from SP1, but SP1 did include a whole bunch of bug fixes and performance enhancements for WPF. One of which must have been to fix some buggy behaviour of the list control the results list is based on.

The IDE does track requirements of written code, and can be made to enforce requirements too. Unfortunately, it does not regard SP1 as any different from 3.5, so while I could track and enforce .net 2.0, 3.0 or 3.5, I can't do so for SP1. Not that it would help anyway, as the code I have used is supposed to work on plain 3.5 too, it's just 3.5 has some bug with it.

So, options now... well, first, I need to find a way to detect whether AAD is running on SP1 or not. Once I can do that, my first choice would be to implement some work-around code that makes it update the list correctly, at the cost of performance. Probably clearing the list completely and repopulating it would work, rather than just repopulating the single changed item.

I'll also have it pop up a warning on first run that installing SP1 would improve performance, and, of course, update the link in the posts to point to the SP1 installer.

Finally, I'll have a look at that maximum results thing. Sounds very strange, but I'll see if I can figure out what's going on. Probably some sort of timing thing.