BUG: Small bug in ML

[MrSinatra]

so this is a small bug, and probably has to do with race conditions or something like that.

using win7 / latest winamp w/patches.

make a smartview and view it as albumartist/albumart with the art as icons.

have a wav file (b/c it has no tags, or an mp3 ur certain has no tags) in the smartview, along with some normal, properly tagged mp3s.

you will see a blank albumart placeholder in the upper left of the art pane. it represents the wav file. in the tracks pane, you will see the wav file as a mostly blank row except for title and filepath.

now select the art-pane album-art-icon, and you will see NOTHING in the tracks pane. 0 items.

so, its some minor bug of some sort afaict, which based on previous bugs and discussions we've had I'm assuming is based on race conditions.

[Aminifu]

Probably a design decision. Artwork is not saved in the media library records. Artwork is pulled from the file, folder, or Winamp artwork caches as needed. Since the placeholder image is used for any folder of song files without a recognized external image file or embedded image in the files, it is probably not associated with the records of such files. In other words, if you click on a placeholder image Winamp has no way to know which file is wanted (better to show no file than all those that fit that circumstance?).

How does the wav file or un-tagged mp3 get in the view? What is the smartview supposed to be listing?

[MrSinatra]

it is not a design decision. winamp shows a placeholder for something no matter what. what makes no sense, is that when you click on the placeholder no tracks would show. that would not be deliberate, or make sense if it were. the tagless tracks show if no placeholder is selected.

you can test it yourself, just stick a wav or tagless file into any given smartview you have.

Originally Posted by Aminifu

Probably a design decision. Artwork is not saved in the media library records. Artwork is pulled from the file, folder, or Winamp artwork caches as needed.

it has nothing to do with artwork or caches.

Originally Posted by Aminifu

Since the placeholder image is used for any folder of song files without a recognized external image file or embedded image in the files, it is probably not associated with the records of such files. In other words, if you click on a placeholder image Winamp has no way to know which file is wanted (better to show no file than all those that fit that circumstance?).

that's not how winamp works. this is something I have explained to you in various ways many times. winamp does not create multiple placeholders based on multiple artworks.

http://forums.winamp.com/showthread.php?t=348677

http://forums.winamp.com/showthread.php?t=278586

the way winamp works is that it DOES show ALL files that "fit the circumstance" which namely is the album name tag used. its just that in this circumstance, for some reason, it isn't. nothing to do with artwork. (if you had three greatest hits albums each with its own art, winamp would just use one artwork, and create one placeholder, but show all 3 albums tracks, as discussed in the links)

I think the reason for this bug is that this is an odd / unique case of being tagless and the race conditions don't account for it. just my best guess.

[MrSinatra]

also, in order to see this bug, the smartview must have some other normally tagged files in it. the bug does not appear if the tagless files are the ONLY files in the smartview, (afaict).

[Aminifu]

Originally Posted by MrSinatra

winamp does not create multiple placeholders based on multiple artworks.

I did not say that it does, don't know how you got that from what I said in post #2 above.

The circumstance I was talking about is where there is no artwork associated with the file(s).

Anyway, whatever the reason, that's an interesting glitch you've found. I only use embedded art and only see the placeholder if I temporarily add a file without an embedded image to the media library.

[MrSinatra]

b/c u suggested that its designed to show only one placeholder and no results when there would be multiple results, but whatever, the point is winamp does not work that way. contrary to what you said, winamp DOES show all results that fit the circumstance, just not in this niche tagless case, ergo the bug.

I am perplexed by your question, how can you not know how to get a file into a smartview? just scan it into the ML via whatever method of scanning into the ML u prefer, and use an existing view or create one that would show it.

[MrSinatra]

Originally Posted by Aminifu

The circumstance I was talking about is where there is no artwork associated with the file(s).

like I said, artwork has nothing to do with it. the bug is a result of being tagless. if the tagless files were in a dir with folder art, the folder art would show, but the bug and behavior would be EXACTLY the same.

[Aminifu]

Originally Posted by MrSinatra

I am perplexed by your question, how can you not know how to get a file into a smartview? just scan it into the ML via whatever method of scanning into the ML u prefer, and use an existing view or create one that would show it.

Sorry, took me a minute to figure it out. I don't put wavs or tagless files in my media library and have turned off all guessing when reading metadata.

[MrSinatra]

Originally Posted by Aminifu

Sorry, took me a minute to figure it out. I don't put wavs or tagless files in my media library and have turned off all guessing when reading metadata.

so I take it you are able to recreate the bug? (my guessing is also turned off)

[Aminifu]

Originally Posted by MrSinatra

b/c u suggested that its designed to show only one placeholder and no results when there would be multiple results,

What I meant was that the same placeholder image is used when Winamp does not know what else to display (no recognizable external art or embedded art).

In my case, when I click on the placeholder (llama) it does list the file without embedded artwork I added to test this.

[MrSinatra]

then there must be something wrong with your file, insofar as replicating this bug. try it with a wav file.

[Aminifu]

Don't think there is anything wrong with the file. Even with guessing turned off, the name of the file is put in the %title% tag (all the other tags are blank). When I get some time, I'll make a wav and try it.

I had noticed in the past that unexpected things happen if tagless or improperly tagged files are added to the media library, so I stopped doing that. I only use formats that support tags in my library and vet all my files before adding them to avoid trouble. I use Winamp to play wavs and such, just don't add them to my library.

But as I said, that's an interesting glitch (bug). Hopefully something will be done about it.

[MrSinatra]

Originally Posted by Aminifu

Don't think there is anything wrong with the file. Even with guessing turned off, the name of the file is put in the %title% tag (all the other tags are blank). When I get some time, I'll make a wav and try it.

the file is wrong in the sense that it is likely not what I am specifying. what format are you using? (I tested with mp3 and wav) it must have NO tags at all, of any kind. wav is that way naturally. a mp3 would suffice as well, if you go into alt+3 and uncheck v1 and v2 and anything else. I have not tested what happens if v1 or v2 is present but entirely blank.

do u mean to say the name of the file is put into the title column in winamp? (that's proper) or is also in the files tag? (improper)

Originally Posted by Aminifu

I had noticed in the past that unexpected things happen if tagless or improperly tagged files are added to the media library, so I stopped doing that. I only use formats that support tags in my library and vet all my files before adding them to avoid trouble. I use Winamp to play wavs and such, just don't add them to my library.

But as I said, that's an interesting glitch (bug). Hopefully something will be done about it.

its worth fixing if only for wav. but it makes no sense that you can not reproduce it, unless your scenario is fundamentally different somehow, and it would be good to know what that difference is, just in case its something unexpected.

[Aminifu]

Ok, I was able to reproduce the bug.

I had used an mp3. It had a populated title tag and the rest were blank. After removing all tags, the only things showing in the library is encoding info like length and bitrate.

The file is listed with other tagged files. You say if it was listed by itself or with other similar files, then clicking on the placeholder would list it. I'll try that tomorrow.

How do you find stuff like this.

[Victhor]

I told Winamp devs about this bug last year, wasn't in time to include a fix in the final build though.

The files affected are the ones with no artist field filled. I even made a set of screenshots to make my point clear in case I wasn't (I'm bringing it back from those mails):

[DrO]

I'd need to find out my reply but its basically due to the nature of the handling of untagged files vs the code used to generate the results.

like noted above it was already reported and I'm sure I could find prior reports if needed as well since its been around since at least 5.0 and might even go back to the 2.9x releases.

as such its already known about but nothing could be done when last raised and all I can do for now is keep it as a tracked issue as I don't know when it'll be looked into.

[MrSinatra]

yeah, I'm pretty sure I mentioned it way way back when I reported the other race condition bugs which did get fixed, as I've been aware of it for a long time; I just happened to come across it again now and figured it might be good time to raise it again.

I have not tested it to see if it only affects files with missing artist tags, but that seems like its probably true. it would also be interesting to see if its true when there is an albumartist tag but no artist tag, or an album tag with no other tags, etc.

my suggestion would be to use the filename for at least 3 fields: artist, album, and title. yes, its a heavy kludge, but its one that I think is called for, and better to have the field display something than nothing (and produce such strange behavior). I think wav users would appreciate it.

[DrO]

or just force people to specify some sort of metadata for it instead of guessing (and i thought the ML guessing mode attempts to do what you're requesting as the solution). either way, it's not like ML specific metadata cannot be specified for such un-tagged files.

[MrSinatra]

yeah, but the problem is guessing is guessing, and even if you use it, it may not work. besides, a wav user might have other files they don't want guessed at, so they choose not to use guessing.

your point that the DB can have manual entries is well taken, but its not a permanent fix in the sense that the DB can lose the info, the file can be moved, etc. if a filename is used for the title, its not really that big a stretch to use it for artist and album as well, right?

that would address wav files and similar tagless files, but I'm not sure how to best address a situation where you have a mp3 that does have tags, and yet deliberately has say the artist field blank, (and I have not tested all such permutations yet anyway). so for that its a thorny issue, and I'd have to say that if any tags are present at all, even blank ones, winamp should reflect that reality, and ergo the bug might persist.

so fixing the race condition is probably necessary to address that scenario. but for tagless files, I do think using filename for artist, album, and title is potentially a good solution.

[DrO]

ofcourse it's not a permanent fix. that's never going to happen if you're working with tag-less files in a tag-centric media library.

guessing or manual input or force setting the filename for the value(s) is all the same - it's trying to do something to an item which doesn't natively provide the means and is thus a hack plain and simple.

as for tagged files with empty fields, they get left as-is i.e. if they're empty, that's how they're stored and treated. and that is likely what is going to happen with tag-less files as well. as it's going to mess up things more and with the way the library works, unless we store a flag or something to track 'real' tags vs 'fake' tags, it's just going to make the library more of a mess - as it doesn't care about the origin of the data as it doesn't use it - it just uses what was stored in the db.


whatever the case, the issue is logged and that's all that can be done for the time being. what gets changed / fixed will depend on what the cause of the issue is found to be or even if it will be fixed at all (as i know it's weird, but trying to cater for massively empty field items is also wrong imho when looking at the aim of the library, the same with applying the filename hack option).

[MrSinatra]

that's all kool and the gang. just to be clear, I'm not really arguing for anything to happen here, so much as think it thru... I like to do so b/c sometimes the exercise proves illuminating in other ways.

in my own usage, I do try to always use properly tagged files, to avoid these kinds of niche cases.

[Victhor]

Just to add some.. shades to this matter, there is a couple of scenarios where the artist or album field isn't necessarily filled, one is the collection of sounds (special effects sounds, that sort of things). I came across this bug precisely because I had among my music one file made to test holophonic 3D sound, so it had most fields blank..

[MrSinatra]

so I think its clear we all agree there is a bug here that in a perfect world would/should be squashed; but my question to you would be: knowing it exists now, would you not consider working around it by filling out those fields?

in other words, while you would not otherwise do so, given this, won't you do it now?

[Victhor]

The question is, if I were an animator with a huge collection of sounds / special effects, would I mix it with my music collection? Mmm... I don't know, but I would necessarily filled the album field to know what type of sound is and the artist field wouldn't be important I guess (there could go probably my name). So no, I wouldn't leave it blank.

Plus, luckily we are abandoning the era of ringtones, those didn't really have an artist field to be filled... (although recently I've found it is sort of an art too...)

[Aminifu]

Since the media library is tag-centric, people should expect inconsistent behavior if they put tagless, or improperly tagged, files in it. People should be encouraged to tag all files added to the library and not be provided means to avoid tagging them, imo.

The <Shift+E> editor can add tags to file records for tagless file formats and the <Alt+3> editor handles in-file tagging for most file formats that support tags. Both of these editors can now be accessed from the playlist editor. If anything is done in this area, these 2 tag editors should be made as inclusive and error-free as possible and that's all, imo.

How Winamp's tag editors can be used should be added to the Winamp features list. Maybe it's just me, but it took me a long time to realize that tags could be added to library records for file formats that don't support tags. That's probably because I seldom used the <Shift+E> editor, since it doesn't support artwork. If possible, the minimum list of which tags should be populated should also be provided.