Winamp really doesn't like Windows Media Player...

[MrSinatra]

if you think you get a lot of complaints now, its nothing compared to how many you will get if you disable Folder.jpg (or other modes) by default. most users won't realize that's where the art came from, esp since those particular files are typically hidden. suddenly, art will be gone for users, I think that's a bad move. jmho.

I'm not sure why cover.jpg should be ahead of Folder.jpg either, but honestly after the first couple I'm not sure one is any more "specific" than another. I'm not really bothered one way or the other how you order the default list, but ordering albums by folder is very common and is how winamp and WMP and EAC and most rippers do it. I understand you have to take those into account who throw files into one dir, but you can't turn off the defaults to accommodate them without breaking the exp for the first group, who are more orderly and just doing what the rippers say by design.

the one thing I would argue for, is giving users the ability to decide for themselves IF they want to enable a catchall mode. I understand you don't like it and it makes you cringe, but if its off by default, it really won't harm anything, and yet it could be very useful to someone who has a scheme different from your list. I would use it myself to simply catch art that for one reason or another isn't conforming with the list. I have np forcing it to be last however. perhaps consider it as an ini only option?

(something else neat you could do is enable a catchall mode but eliminating results from all the other modes, so that only the "oddballs" displayed, so a user could find em easy and manually rename them to conform)

and the same logic is behind at least some kind of indicator, so users can spot bad extensions.

[DrO]

yet having incorrect art is better? and i never said it would be disabled by default, just out of what is currently enabled, it is the most likely of the lookup options which could be considered to be changed from on to off.

however it is done there are compromises as it otherwise potentially turns into a mess of options and that's just exacerbating the issue further as a lot of people don't want to have to mess around with settings. they just want to install something, it be correct and not give a toss that you can adjust a certain lookup order.

and currently the folder.* doesn't mean it will be correct, so if anything, dropping it to the bottom of the list is most likely what i'd prefer to do. so it's still an option but it's a final resort (making it easier to determine it's the issue at fault). and yes, most of them are not very specific, but as artwork handling is not consistently done (hence all of the modes listed on the screenshot), is it no wonder that it's a mess and that whatever is done will piss off someone because it doesn't automatically know what they want.


as for the catchall, it's grasping at straws if nothing else worked. if there was something more specific to check against then i probably would consider adding it. but effectively doing a full search on all image files is not a solution and compounds the issue. sometimes it's better to provide nothing and get complaints and educate people than try to keep every single scenario covered. that is why it makes me cringe and is really not something i'd want to implement.

[MrSinatra]

ok, I can tell I'm starting to piss you off so i'll stop, but just to be clear, I don't really care where in the order Folder.jpg is, I wasn't arguing for higher, but I do think it should be on rather than off. when you said it was more likely to be disabled by default, I worried.

on the other items we disagree, but that's fair enough, np. I do think its cool you're doing anything with this, so I'm at least happy to see that.

ok, one last attempt (sorry): in squeezebox, a user can actually specify the filename to use for art. would you consider adding a mode like that, and allowing that mode to respect a wild character? (so * for the filename with any found image ext is used?) that way, a user couldn't just check it on, they'd have to know it would be possible, plus it also allows for specific filenames outside your list.

[DrO]

i'll consider the custom entry option which would then mean you get your catchall option but it better satisfies the need to pick more appropriate searches for those cases where the defaults don't work, so i'll consider it as a compromise of what you're wanting and what i think is needed.

[MrSinatra]

I don't know what to say!

[Aminifu]

DrO,

Would not just adding a preference to use a custom image file name, that overrides what is currently done, be simpler to code than the enable/disable for each naming preference shown in your screenshot?

The naming rules currently used could be listed and would be the default.

If the <Alt+3> tag editor is used, to put an external image file in the folder of the song file being edited, it will rename the image file to what's in the song's %album% tag if one exists or "cover". I assume this behavior will not change.

[MrSinatra]

it would not suffice, b/c even people who would specify a filename or wildcard might also want embedded images to show for example.

I think its a good thing to allow each indiv method to be turned on or off via checkbox. it possibly might even speed up scanning, depending on how the scanner is implemented. if that were true, I would search my entire HD of songs for images, sort by filename, and make sure all art used Folder.* and set that to be the only item used (maybe with embeds, maybe without); again if it improved scan time.

[DrO]

with the options proposed so far it wouldn't be any more complex than how things are done already since it'd just be controlled as a bitmask compare at the different stages on lookup which is simple to implement.

its the possibility to control the order which is the more complex option and with the custom option I'm now not sure it'd even be needed (reordering support that is). there might be an arguement to just disable everything if a custom field is specified but if its really there as a way to cater for what we don't use by default, it'll be at the end and I could make a prompt or something to disable the other options so as to reduce confusion or something like that.

[Aminifu]

Originally Posted by DrO

with the options proposed so far it wouldn't be any more complex than how things are done already since it'd just be controlled as a bitmask compare at the different stages on lookup which is simple to implement.

Ok. What about the behavior of the <Alt+3> editor?

[DrO]

that uses the artwork api so any control changes on artwork lookup would then be applied to what's displayed on that dialog or anything using the api e.g. gen_classicart or library lookups.

though this is why it could get messy if there's embedded artwork which if the option is disabled then you'd not know it's in the file tags. so maybe that's something which needs to be more clearly indicated either in the 'format info' summary or on the artwork page itself.

as the artwork page itself needs some tweaking whatever the case so it's able to show the artwork (branding and now playing) from SHOUTcast v2 streams which are able to provide that with the stream.

[Aminifu]

Originally Posted by DrO

though this is why it could get messy if there's embedded artwork which if the option is disabled then you'd not know it's in the file tags. so maybe that's something which needs to be more clearly indicated either in the 'format info' summary or on the artwork page itself.

Maybe the artwork naming choices should be opt-out instead of opt-in (looking at the screenshot of the new preference you're thinking about). If nothing is selected as the default, then no artwork would be shown. That would really confound users who don't change defaults.

[DrO]

yes the options are opt-out, is just how i'd mocked things up meant they weren't shown as checked.

[edit]
attached image is what we've decided on (it has image.* in the field only because that's what i've been using for testing, otherwise it's empty by default).

[Aminifu]

Originally Posted by DrO

attached image is what we've decided on ...

Looks good to me and is the best that can be done to deal with the problem of Windows overwriting external image files named "folder". Now people can disable the use of "folder" and use any other name or names, then when Windows (sooner or later) adds an image named "folder" it will not disrupt anything.

[MrSinatra]

looks great. will unchecking say half of those boxes make scans faster?

Originally Posted by DrO

[edit]
attached image is what we've decided on (it has image.* in the field only because that's what i've been using for testing, otherwise it's empty by default).

I hope you don't mind some nit-picky feedback, but I would have Folder.* come before cover.* in the ranking, if only b/c winamp is a windows app and Folder.* is what windows/wmp uses.

also, I would reword the text of the custom option to say:

"use a custom filename or wildcard search if there are no other matches. the artwork file needs to be in the containing folder as the file to which it belongs, or if in a relative path to song file, that path also can be specified below."

I suggest this b/c I'm not sure I understand the intent to text that is there, so maybe I have just completely misunderstood? but the way it is now I think will confuse folks.

also, what if someone simply entered *.* ? would any file be attempted to be used, or just any file with an image ext winamp recognizes?

Originally Posted by Aminifu

Looks good to me and is the best that can be done to deal with the problem of Windows overwriting external image files named "folder". Now people can disable the use of "folder" and use any other name or names, then if Windows adds an image named "folder" it will not disrupt anything.

this is an excellent point, except that windows itself uses Folder, so while one could protect oneself from windows malpractice, one would lose the windows icon.

you could modify your approach, and use a system of two files, where one is the primary art, and Folder is the copy/backup. I currently do the opposite, folder is my primary, and I have a copy of it (with whatever name) as the backup; but with this new winamp ability, I could convert my method and be more robust.

[Aminifu]

Originally Posted by MrSinatra

this is an excellent point, except that windows itself uses Folder, so while one could protect oneself from windows malpractice, one would lose the windows icon.

I don't follow you here. Explorer will still use the image named "folder", but Winamp would not if it is disabled.

Also, I don't think a wildcard (*.*) could be used for a custom name, but DrO will clear that up.

The bit about relative path is confusing. I would change what you suggested to; "Use a custom filename or wildcard search if there are no other matches. The artwork file needs to be in the containing folder of the file(s) with which it is associated, or if in a relative path, that path must also be specified below."

[DrO]

*.* will work and it'll then just use the first image which can be loaded. the specifics of what is allowed is based on how the OS determines things since we're just passing it as <folder_of_file>\<search>. i've left it open since i don't know what people may try and if junk is entered, it's just not going to provide a match and so nothing would be enabled.

the front.* and cover.* options will not be swapped from what is in place and with the custom option, you can now get the change in order that you want by unchecking one and entering it in the custom search.

as for changing the wording of the message (which is the tweaked version Egg came up with), i'm not keen on what has been proposed as they're verbose versions of what has been put on there (as it makes it a 3 line block of text which is too much for the purpose of that). and what is there is just following the same as is implied by all of the options above it (since it's purely allowing for front.* to be replaced with <search> in the internal code).

[MrSinatra]

Originally Posted by Aminifu

I don't follow you here. Explorer will still use the image named "folder", but Winamp would not if it is disabled.

I don't know what was unclear? I would not want a scenario where winamp is using one image from whatever source, while windows explorer/wmp uses another from its own source, as that could easily lead to divergence.

Originally Posted by Aminifu

The bit about relative path is confusing. I would change what you suggested to; "Use a custom filename or wildcard search if there are no other matches. The artwork file needs to be in the containing folder of the file(s) with which it is associated, or if in a relative path, that path must also be specified below."

I'd be fine with that.

[MrSinatra]

Originally Posted by DrO

the front.* and cover.* options will not be swapped from what is in place and with the custom option, you can now get the change in order that you want by unchecking one and entering it in the custom search.

yes, one can now just uncheck whatever, and that's great! however, I was just saying that for default purposes, swapping them makes sense to me but its nothing I feel strongly about, just mentioning it.

I am intrigued by what you are saying above though, so some questions:

will unchecking say half of those boxes make scans faster?

how do u change the order by unchecking one and using the custom search? can u give an example of what you mean?

another related question is, say I had these settings:

checked = embedded
checked = Folder.*
checked = custom with *.*

(the rest unchecked)

lets say winamp on a file record found an embedded or a folder.* image. would that "find" end the image search for the file record? or would winamp continue to look for other image categories that are checked, (like *.*), even after it found a higher ranked one it will prefer?

Originally Posted by DrO

as for changing the wording of the message (which is the tweaked version Egg came up with), i'm not keen on what has been proposed as they're verbose versions of what has been put on there (as it makes it a 3 line block of text which is too much for the purpose of that).

I don't feel super strong about it, but if Aminifu and I agree, I hope Egg would consider that.

its def the kind of option that would be well served by a single wiki link in the pref dialog.

Originally Posted by DrO

and what is there is just following the same as is implied by all of the options above it (since it's purely allowing for front.* to be replaced with <search> in the internal code).

I'm not sure I follow this but I'm probably just over-thinking it.

just to be clear, I really like the work on this aspect of the program. the audiophiles at squeeze, (heavy music users) do in some cases have crazy artwork naming schemes, and relative paths, and so this will now allow them to use winamp, whereas before they would have automatically ruled it out.

[DrO]

Originally Posted by MrSinatra

however, I was just saying that for default purposes, swapping them makes sense to me but its nothing I feel strongly about, just mentioning it.

you feel strongly enough to have mentioned it a few times now

Originally Posted by MrSinatra

will unchecking say half of those boxes make scans faster?

potentially it will save a bit of time (probably looking at milliseconds at best subject to the media being searched on) if you're constantly not getting any results for files. but with OS caching of things, it's unlikely to be noticeable unless it's the first time of hitting the files i suspect or doing 1,000s of files (and even then it'd save maybe a few seconds i'd expect).

Originally Posted by MrSinatra

how do u change the order by unchecking one and using the custom search? can u give an example of what you mean?

uncheck cover.*, leave folder.* checked and then put cover.* in the custom field. that is re-ordering things exactly as you're wanting (having folder.* before cover.*). all this custom option is doing is adding an extra level to the pre-defined list and is working with the exact same code as the pre-defined options use.

Originally Posted by MrSinatra

another related question is, say I had these settings:

checked = embedded
checked = Folder.*
checked = custom with *.*

(the rest unchecked)

lets say winamp on a file record found an embedded or a folder.* image. would that "find" end the image search for the file record? or would winamp continue to look for other image categories that are checked, (like *.*), even after it found a higher ranked one it will prefer?

as soon as there is a match, then the lookup ends. the options are listed in the order that things are attempted and as soon as there is a valid result, things are stopped. so if you have an embedded cover then it'll only look at that and it will not look at anything else.

Originally Posted by MrSinatra

its def the kind of option that would be well served by a single wiki link in the pref dialog.

i was fully expecting that comment. we have given some thoughts to things (but it would not be in the manner you keep asking for), though for the time being it's going to remain with the help (if present) stored in winamp.exe/winamp.lng (which there isn't anything on that dialog at the moment) which is triggered by clicking the added help button or leaving the mouse over the control for a few seconds.

[MrSinatra]

Originally Posted by DrO

you feel strongly enough to have mentioned it a few times now

sorry. I should clarify that I always feel strongly about explaining myself, if not the topic at hand. I do appreciate the breakdown!

Originally Posted by DrO

potentially it will save a bit of time (probably looking at milliseconds at best subject to the media being searched on) if you're constantly not getting any results for files. but with OS caching of things, it's unlikely to be noticeable unless it's the first time of hitting the files i suspect or doing 1,000s of files (and even then it'd save maybe a few seconds i'd expect).

well, worthy nonetheless. I look forward to seeing what will work best for me. it also allows one to figure out what they actually have, by doing scans of just "one type" and then refreshing the art, to see what shows up. so I could say, specify Folder.gif or embeds or *.png and get just those results. its true I could do the same in a results list in windows explorer, but that is not easy to then work with for me as it would be via winamp art icons.

Originally Posted by DrO

uncheck cover.*, leave folder.* checked and then put cover.* in the custom field. that is re-ordering things exactly as you're wanting (having folder.* before cover.*). all this custom option is doing is adding an extra level to the pre-defined list and is working with the exact same code as the pre-defined options use.

ah, duh, I get it now. that works but it "uses up" the custom option for that purpose, but still that's better than not being able to at all. I thought you meant something entirely different so that clears it up.

Originally Posted by DrO

as soon as there is a match, then the lookup ends. the options are listed in the order that things are attempted and as soon as there is a valid result, things are stopped. so if you have an embedded cover then it'll only look at that and it will not look at anything else.

perfect! that should solve the bug I had as well.

Originally Posted by DrO

i was fully expecting that comment. we have given some thoughts to things (but it would not be in the manner you keep asking for), though for the time being it's going to remain with the help (if present) stored in winamp.exe/winamp.lng (which there isn't anything on that dialog at the moment) which is triggered by clicking the added help button or leaving the mouse over the control for a few seconds.

all I really want, and how you do it is fine with me, but all I really want is the ability to link to a user edited wiki from a given pref dialog. you guys can appoint the wiki editors u trust, hopefully people like me and Aminifu and TT, ryerman, etc. ...but that's all I'm asking for and I really hope you strongly consider doing so. thx again for the work on art, as I think its very worthy under the hood stuff.

[DrO]

Originally Posted by MrSinatra

all I really want, and how you do it is fine with me, but all I really want is the ability to link to a user edited wiki from a given pref dialog. you guys can appoint the wiki editors u trust, hopefully people like me and Aminifu and TT, ryerman, etc. ...but that's all I'm asking for and I really hope you strongly consider doing so. thx again for the work on art, as I think its very worthy under the hood stuff.

if anything we're more likely to try to go with some sort of off-line solution (possibly allowing for downloadable updates or user derived updates from a central file) than relying on a dedicated wiki / server side solution. but it's just thoughts at the moment and is way down the list of things that could be done with what we're wanting to achieve.

[MrSinatra]

well, please consider making this information cloned, so that there is an offline ver, and a mirrored online ver, so that way people could find the info via google searches etc, and reference it directly when making posts, emails, and so on. thx.

[DrO]

an online version wouldn't work with how the help system works in the preferences against the idea i was talking about (since it'd be specific to how the preferences are implemented and not lend itself to web based help). and like i said, it's just thoughts at the moment and is more likely to just end up staying as it is as it's a lot of work for minimal benefit (which i know you will disagree with but it's the truth of the matter of spending a few days or more on a mass of changes to the in-help handling vs the same time doing something useful with reducing resource usage which benefits everyone).

[MrSinatra]

Originally Posted by DrO

is more likely to just end up staying as it is as it's a lot of work for minimal benefit (which i know you will disagree with but it's the truth of the matter of spending a few days or more on a mass of changes to the in-help handling vs the same time doing something useful with reducing resource usage which benefits everyone).

actually, I agree with that, b/c the argument you are making above is not the one I am making. I think an offline "help" system or whatever you are proposing is useless and time would be better spent on resource usage, features, etc; i completely agree!

Originally Posted by DrO

an online version wouldn't work with how the help system works in the preferences against the idea i was talking about (since it'd be specific to how the preferences are implemented and not lend itself to web based help).

where I disagree is that an online USER written document tied to pref dialogs is useless. I'm not sure why you seemingly want to do help offline anyway esp since you already have come to the correct conclusion that it would serve no purpose esp vs time spent elsewhere.

but the real benefit of online documents, besides linking dialogs to the exact area explaining them, is that you guys would NOT need to spend time creating content for it, the users could write the documentation, and the value of the ability to reference that documentation online via forums and email and so on is self evident, imo.

so, I'm sorry we disagree on this, b/c I think it would be really a great thing for winamp with minimal dev time invested.

[DrO]

online services fail - just look at the failure of the wiki today and how it was down for the first few weeks after the sale. if anything, the sale has shown that relying on online aspects for things is not always the best way and as we already provide some sort of in-Winamp help, maybe trying to bolster that is better than going down the online route.

and my thoughts on a system rely on USER provided details (BUT not blindly allowed as your proposal still would do) in addition to what myself and Egg would be producing since it would allow for user contributions, but not via a wiki setup but as patches to a maintained singular file (so taking the wiki approach as such but doing what would work best with how things have to be integrated). as i much prefer not having to wait for help pages to load and is why an offline version is more appealing (and yes lots of us have fast internet speeds, but a lot don't or don't want to waste it on looking up help, hence another reason why an offline / local version is more appealing).

and my idea on things also meant that the version of information provided to the user would be correct for the version of Winamp being used (as the possible system would allow for versioning of the help information to specific clients), as a wiki / online would most likely either be for the current release (or lag behind) and would then be providing out of date / incorrect information. as we have clearly seen, people don't update unless they have to and why would they want to see incorrect information for v6.1 when they're on v6.03.

anyway, what may or may not happen, any option requires in-Winamp changes to facilitate things. and like i've said already it's just ideas we were floating around internally and will most likely not come to anything, but a wiki option is pretty much not going to be officially sanctioned, i can be fairly certain about that.

[Aminifu]

Originally Posted by DrO

*.* will work and it'll then just use the first image which can be loaded. the specifics of what is allowed is based on how the OS determines things since we're just passing it as <folder_of_file>\<search>. i've left it open since i don't know what people may try and if junk is entered, it's just not going to provide a match and so nothing would be enabled.

Ok, the ability to use a wildcard (*.*) along with disabling 1 or more the specified names are potentially great additions for savvy users. This greatly extends Winamp's versatility in handling artwork.

Does "we're just passing it as <folder_of_file>\<search>" mean that a path to an image file should not be entered or is something like 'C:\<folder_of_image>\usethis.jpg' acceptable?

[DrO]

correct, a full file path should not be entered with how its coded though I might allow for that to work by checking the type of value entered. as it would otherwise be appending a path to the folder path of the containing folder of the playing file.

[Aminifu]

Originally Posted by MrSinatra

I don't know what was unclear? I would not want a scenario where winamp is using one image from whatever source, while windows explorer/wmp uses another from its own source, as that could easily lead to divergence.

Ok, I get your concern now. But if you want Winamp and WMP to use the same image, then you have to use an image named "folder" and you're stuck with the current situation. Namely, having that image changed at random by what you call "windows malpractice".

Explorer, on the other hand, can and will use a number of variously named images, what Windows provides for it and what you provide (if you delete what Windows provides and name your images the same way).

In this case, trying to get multiple apps to always use the same image is probably a hopeless cause.

[Aminifu]

Originally Posted by DrO

correct, a full file path should not be entered with how its coded though I might allow for that to work by checking the type of value entered. as it would otherwise be appending a path to the folder path of the containing folder of the playing file.

The ability to use a full file path would make the handling more powerful, but it is probably not needed. After all, the external image should be in the folder with the files it is associated with. This does require each group of files to be in a separate folder, but that is the scheme being urged on us anyway when using external artwork.

[DrO]

my thinking more of allowing full path support is that you can then provide a different 'no artwork' irrespective of the skin being used (especially with some of the bento artwork changes I've made recently). and its a simple change to make anyway

[Aminifu]

Originally Posted by DrO

my thinking more of allowing full path support is that you can then provide a different 'no artwork' irrespective of the skin being used (especially with some of the bento artwork changes I've made recently). and its a simple change to make anyway

Yeah. I was thinking of that too, but I like the llama.

Whatever, you decide. I currently use embeds with my local files, but appreciate the help being provided for those who use external artwork and when playing streaming files that don't provide artwork.

[DrO]

well hopefully there'll be some stream + artwork improvements as well, though the primary aim for all of this is really for local file handling.

[Aminifu]

Thought I read somewhere that some improvements were already made for stream, but that is OT for this thread.

[MrSinatra]

one reason to provide a full path would be to allow for the users who keep ALL their artwork in ONE folder, that isn't necessarily relative to any songs folders, and yes, they do exist. while I would never do that, it is an accepted method for some apps. the art is then matched via filename to album tag I believe. I didn't bring this up b/c I think its somewhat outside the scope of what winamp should do, but maybe its not hard to implement?

i'll respond to some other points above below.

[DrO]

this is turning into the rating threads all over again. i've implemented what i will implement and that's it (and i'm almost at the point of regretting even adding the damn options page).

[MrSinatra]

Originally Posted by DrO

well hopefully there'll be some stream + artwork improvements as well, though the primary aim for all of this is really for local file handling.

in this regard, and maybe its this way already, but I'd like winamp to use the albumart that the file says belongs to it, but if none is found, I would like to specify a generic station logo.

so say u have 10 songs, nine with their own art. the 9 broadcast that art, and the 1 broadcasts a static generic station logo. that way the llama is never seen on the station broadcast.

[MrSinatra]

Originally Posted by DrO

this is turning into the rating threads all over again. i've implemented what i will implement and that's it (and i'm almost at the point of regretting even adding the damn options page).

I really don't understand this reply at all, what is the problem? I am not arguing or doing anything other than just talking. you always do what you want to do anyway, so where is the harm in just talking?

you do realize this is a forum where people are supposed to be encouraged to say things, yes?

and all your work is greatly appreciated, so don't come back saying its not or something like that.

[DrO]

i was just stating my position. as obviously there's other things you're wanting, but as time and resources are limited (since i'm the only dev), i've done what i will towards things for local artwork and if you want to go into more of what you want to see, then i am not stopping you - but it's just looking like the ratings thread all over again with going down a rabbit hole for _everything_ that could be done and that's just not practical.

[MrSinatra]

Originally Posted by Aminifu

Ok, I get your concern now. But if you want Winamp and WMP to use the same image, then you have to use an image named "folder" and you're stuck with the current situation. Namely, having that image changed at random by what you call "windows malpractice".

Explorer, on the other hand, can and will use a number of variously named images, what Windows provides for it and what you provide (if you delete what Windows provides and name your images the same way).

In this case, trying to get multiple apps to always use the same image is probably a hopeless cause.

this is what I tried to explain earlier.

afaik, windows explorer only works with Folder.* (or maybe only Folder.jpg) if using external files.

if i want that to remain the case, but be more robust from a winamp POV, I could specify a filename, say xyz.jpg to winamp, and let Folder.jpg be the backup. that would be the opposite of what I do now, (b/c I do not have the options available being discussed in this thread)

so yeah, windows / wmp might still overwrite the backup file, but them doing that will ALWAYS be a possibility and concern, there is no way out of that, IF you want folder art in explorer. but my main art would remain unaffected, and I could use it to reinstate the backup, should malpractice ever occur.

(I started using backups in the folder long ago b/c I noticed the windows/wmp thing, but also that viruses would target folder art, b/c at that time my art files were also system files, since WMP provided them. since them I have mass converted them all to just hidden archive files)

[MrSinatra]

Originally Posted by DrO

i was just stating my position. as obviously there's other things you're wanting, but as time and resources are limited (since i'm the only dev), i've done what i will towards things for local artwork and if you want to go into more of what you want to see, then i am not stopping you - but it's just looking like the ratings thread all over again with going down a rabbit hole for _everything_ that could be done and that's just not practical.

I am happy with EVERYTHING being done and I am NOT requesting anything else be done, at least not in the post that you replied to, (all art in one folder). personally, I think that's a dumb way to store art, but I only mentioned it in case you and aminifu (or others) didn't know about it, and if it were "easy" to implement as the other similar sounding things you two were talking about seemed to be.

I agree its very rabbit hole-ish.