BUG: Small bug in ML

[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.