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: foo_discogs (Read 1365699 times) previous topic - next topic
0 Members and 4 Guests are viewing this topic.

foo_discogs

Reply #1875 –
Quote from: paregistrase on
Hi zoomorph !

I'm having a little bug with last update and the blocked field DISCOGS_TRACKLIST_INDEX:
Code: [Select]
<DISCOGS_TRACKLIST_INDEX> : «multiple values» 1/?; 2/?; 3/?; 4/?; 5/?; 6/?; 7/?; 8/?; 9/?; 10/?

and the update tag feature does not work.

Yup. DISCOGS_TRACKLIST_INDEX got removed. The direction I was heading with this update was in matching tracks via a variety of methods, not relying on DISCOGS_TRACKLIST_INDEX (which is just one method, and not a very user-friendly one). Update tags feature is still under development, and doesn't use these methods yet.

Quote from: paregistrase on
Also I find some problematic releases, mostly related with hidden tracks:
Code: [Select]
<DISCOGS_RELEASE_ID> : 6939
<DISCOGS_RELEASE_ID> : 17435

How can I get all tracks from this kind of releases?

Thanks for providing these examples. This is an unfortunate case where Discogs goes by what is written on the release instead of following a logical method of generating track numbers, hence it becomes impossible to perfectly parse the track list. In cases like this, the tracklist will happen to look like something else, just because it was written that way on the sleeve. I'll have to think about whether anything can be done to improve this.

foo_discogs

Reply #1876 –
I just installed Windows 10 and installed Foobar with plug-ins. I seem to remember there was some kind of initialization required with this plug-in? Some kind of Username and Password?

foo_discogs

Reply #1877 –
hi,
just a small glitch in the newest version.

I'm still trying to figure out how all the magic works, so no hardcore testing form my side atm. I'm deeply sorry ;-/

foo_discogs

Reply #1878 –
Hi zoomorph,
I got some time to play around, but cannot say anything in detail about the great flexibility you now gave us, BUT
what I miss very much in the GUI:

-the possibility to reset a default for *each* tag, not only defaulting *all* tags (via right click menu?). this would facilitate the finetuning a lot, becaue users do not have to store the original config anywhere in notepad to get them back when needed.

-save/load (extra buttons?) all the formatting strings to a file, because sometimes, the config is screwed up completely and I'd like to go back to yesterdays working configs.

Cheers,


foo_discogs

Reply #1879 –
Hi zoomorph,

I found a "bad behaviour", which could also be a feature... but I personally would call this an undesirable effect, which is not expected by the user (me)

When having an empty formatting string and the write/update is enabled, the component empties that tag from the file while updating all the tags.

That way the component deleted all the maybe filled tags from the file, which the user maybe does not realize, or way too late, like me.

I sadly deleted a lot of my composer/performer tags while betatesting. (my fault, no blame goes to anybody but me...)


Can you please skip the deleting/erasing of a tag, when the string is not set? that would prevent users from erasing their tags without knowing it.

Cheers

foo_discogs

Reply #1881 –
Hi zoomorph,

I've got

"Unhandled exception in "Updating tags..."
invalid stoi argument

when trying to update some/all/one tags  from an album.

Is there anything, I can try to not get this error but update the files? (I remember there was an issue, but not exactly what issue...)


also,
for the useful matching tracks feature:

when unsuccessully matching tracks, the message "FAILED TO MATCH..." is red.

when successully matching tracks, the message is just plain. I would prefer to have it i.e. green, because then the user recognized, something was done.

if nothing was matched, the message should be plain, imho.

foo_discogs

Reply #1882 –
i guess the problem is that zoomorph mentioned more than once, that the update-feature isnt implemented as of yet. this is why i'm not using the component for now. want to rebuild my database on a solid system while of course keeping some of the tags i wrote with bubblegums plugin.

foo_discogs

Reply #1883 –
Quote from: alexinc on
i guess the problem is that zoomorph mentioned more than once, that the update-feature isnt implemented as of yet. this is why i'm not using the component for now. want to rebuild my database on a solid system while of course keeping some of the tags i wrote with bubblegums plugin.
I remember, it was experimental, but implemented ;-) but I guess, u're right, because its not possible in any contellation of selected tracks to update anything.

for me, the update-feature is a very important feature, because its would allow me to quickly update a lot of albums all at once.

Now, when I want to "update" any old information in, say, 5 albums,  I need to select each of the 5 albums at once and write the tags to the files. this is, of course, for 5 albums nothing big, but imagine 20 or more...
With the update feature working, I just could select the 5 albums and press my keyboad shortcut to magicially get them updated in one single flush.

For me, its important to update a single track, as well as a whole album.

Anyways, its not usable by now ;-)
Hopefully zoomorph has some ideas to implement this.







another glitch found:
the components cuts off the end of the formatting string and so does not show the complete formatting string.

foo_discogs

Reply #1884 –
i hear you!

foo_discogs

Reply #1885 –
Hi zoomorph,

for this relase, track 3, the default formatting string for DISCOGS_CREDIT_VOCALS did not work, because there is a nasty space in the TRACK_CREDITS_SHORT_ROLES.

I fixeed it quickly with some $multi_trims, but I'm pretty sure, I can be done smarter...

default:
Code: [Select]
$flatten($multi_if($any($multi_strcmp($sextend(%<<TRACK_CREDITS_SHORT_ROLES>>%,%<<RELEASE_CREDITS_SHORT_ROLES>>%),'Vocals')),$multi_if($put(aj,$sextend(%<<TRACK_CREDITS_ARTISTS_JOIN>>%,%<<RELEASE_CREDITS_ARTISTS_JOIN>>%)),$join($put(an,$sextend(%<<TRACK_CREDITS_ARTISTS_NAME>>%,%<<RELEASE_CREDITS_ARTISTS_NAME>>%)),$multi_wrap($get(aj),' ')),$get(an)),))

now working:
Code: [Select]
$flatten($multi_if($any($multi_strcmp($sextend($multi_trim(%<<TRACK_CREDITS_SHORT_ROLES>>%),$multi_trim(%<<RELEASE_CREDITS_SHORT_ROLES>>%)),'Vocals')),$multi_if($put(aj,$sextend($multi_trim(%<<TRACK_CREDITS_ARTISTS_JOIN>>%),$multi_trim(%<<RELEASE_CREDITS_ARTISTS_JOIN>>%))),$join($put(an,$sextend($multi_trim(%<<TRACK_CREDITS_ARTISTS_NAME>>%),$multi_trim(%<<RELEASE_CREDITS_ARTISTS_NAME>>%))),$multi_wrap($get(aj),' ')),$get(an)),))


Maybe you want to add a smarter way to ignore "whitespaces", like I did? Otherwise, we need to put the $multi_trims in every formatting string, I guess, which will make them even more unreadable ;-)

foo_discogs

Reply #1886 –
Hi zoomorph,

a Bug:

when removing a track from the "files", the tagging is not correct, and the removed track is tagged.

the screenshot shows:
-untagged files (top of screen) in f2k
-selected track on the right, which is removed while pressing DELETE, in the next screenshot.


this screenshot is taken, after removing the file.
Left and right are showing both the "same" tracks:


after tagging, the result is this:


wrong: not tagged track 6, track 5 tagged as track 6
expected: removed track not tagged, track 6 tagged.

have fun :-)

foo_discogs

Reply #1887 –
Hi zoomorph,

for this release, I always get this error while tagging:
Quote
(skipped) Error: Error writing tag DISCOGS_ARTISTS_ALIASES [Error processing field ARTISTS_ALIASES :  Too many triangle brackets.] for file
(skipped) Error: Error writing tag DISCOGS_ARTISTS_ALIASES [Error processing field ARTISTS_ALIASES :  Too many triangle brackets.] for file

[ESCAPE to close]

regardless, of what formatting string I use, i.e. :
%RELEASE_ARTISTS_NAME%, <%RELEASE_ARTISTS_NAME%>, $join($multi_replace(%<RELEASE_ARTISTS_NAME>%,'Various','Various Artists'),$multi_wrap(%<RELEASE_ARTISTS_JOIN>%,' ')), or the default one

is it me, or the component which causes the error? other releases are working fine the last days of testing.

some other releases with the same error:
1438836
1912661
4253278
892808
3381267

foo_discogs

Reply #1888 –
Hi zoomorph,

in addition to this post:

could you implement something which removes anchors from the url given in the "release id/url" textbox?

Quote
(FATAL) Error: Error loading release history?release=739629#latest: Page Deleted or Missing (404)(url: http://api.discogs.com/releases/history?re...=739629#latest)


Anyways, I tested the last days and need to say, that it is -beside some glitches and things which don't work right now- it is a pleasure to work with your adapted component of bubblegum.

-inserting an url or the plain release id is pretty cool. just add, whats in the clipboard and you're fine.
-resizing the windows to my viewing needs. its possible after all these years! (although it seems the resizing is not remembered and the position is wrongly remembered, but the most important thing is to size the windows...)
-configuring my own release formatting string (configuration->searching) is very useful.
-my expericence with track matching was ....not that good, so i deactivated it. need to play with all the preferences in the configuration, when I start again with testing.
-playing with the formatting strings is fun (as long as I get usable results), though, I don't really understand the very well written help. you could add more examples for dumb users like me, just to give them something to play and get interested.
-navigating inside the componens via the buttons or with keyboad-shortcuts makes is very fast to use.
-the release-caching problem I had the last versions seems to be gone. fine.
-no crashes anymore!

well and a lot more, I can't recall right now.

t-h-a-n-k you!!

foo_discogs

Reply #1889 –
Hi fuffi,

Thanks for all the feedback/reports. I wasn't around for awhile and I haven't read all of your posts yet, but I will read them and incorporate your feedback & reply to the rest when I get a chance. :-)

Quote from: fuffi on
hi,
just a small glitch in the newest version.

I'm still trying to figure out how all the magic works, so no hardcore testing form my side atm. I'm deeply sorry ;-/

I'm not sure what causes this, but sometimes the same releases are shown twice under the master release (seems to be the case in the top picture).

Quote from: fuffi on
-the possibility to reset a default for *each* tag, not only defaulting *all* tags (via right click menu?). this would facilitate the finetuning a lot, becaue users do not have to store the original config anywhere in notepad to get them back when needed.

Very good idea. Right click option to restore default (when applicable).

Quote from: fuffi on
-save/load (extra buttons?) all the formatting strings to a file, because sometimes, the config is screwed up completely and I'd like to go back to yesterdays working configs.

I've thought of that. For the time being at least, you can back up the foo_discogs.dll.cfg file which includes all the format strings, in case of a problem so that you can restore them.

Quote from: fuffi on
Hi zoomorph,

I found a "bad behaviour", which could also be a feature... but I personally would call this an undesirable effect, which is not expected by the user (me)

When having an empty formatting string and the write/update is enabled, the component empties that tag from the file while updating all the tags.

...

Can you please skip the deleting/erasing of a tag, when the string is not set? that would prevent users from erasing their tags without knowing it.

This is actually a feature. There needs to be some way to erase a tag if desired, and setting the value to an empty is the logical way to do that. If you want to possibly modify the tag, possibly not, then in your formatting string you should be able to do something like: $if(condition,new value,%ORIGINAL_TAG_VALUE%). Tags that you don't want to modify should be disabled!

Quote from: fuffi on
http://www.discogs.com/Metallsp%C3%BCrhund...release/1722388

is accepted,

www.discogs.com/Metallsp%C3%BCrhunde-B%C3%B6se-Wetter/release/1722388

is not accepted. (only the protocol is missing)

Thanks, fixed for future versions.

Quote from: fuffi on
I've got

"Unhandled exception in "Updating tags..."
invalid stoi argument

when trying to update some/all/one tags  from an album.

Sorry, updating tags isn't figured out yet. (Partly because I never used that feature so it doesn't bother me personally, partly because it's quite difficult to decide what to do and there's no easy solution. :-p)

I suggest using an old version of the plugin for now if you need to update tags.

foo_discogs

Reply #1890 –
Quote from: fuffi on
Hi zoomorph,

for this relase, track 3, the default formatting string for DISCOGS_CREDIT_VOCALS did not work, because there is a nasty space in the TRACK_CREDITS_SHORT_ROLES.

I fixeed it quickly with some $multi_trims, but I'm pretty sure, I can be done smarter...

Maybe you want to add a smarter way to ignore "whitespaces", like I did? Otherwise, we need to put the $multi_trims in every formatting string, I guess, which will make them even more unreadable ;-)

Nice catch! I've changed it so that the SHORT_ROLES are trimmed of whitespace internally, which should fix this issue going forward. :-)

Quote from: fuffi on
Hi zoomorph,

for this release, I always get this error while tagging:
Quote
(skipped) Error: Error writing tag DISCOGS_ARTISTS_ALIASES [Error processing field ARTISTS_ALIASES :  Too many triangle brackets.] for file
(skipped) Error: Error writing tag DISCOGS_ARTISTS_ALIASES [Error processing field ARTISTS_ALIASES :  Too many triangle brackets.] for file

[ESCAPE to close]

regardless, of what formatting string I use, i.e. :
%RELEASE_ARTISTS_NAME%, <%RELEASE_ARTISTS_NAME%>, $join($multi_replace(%<RELEASE_ARTISTS_NAME>%,'Various','Various Artists'),$multi_wrap(%<RELEASE_ARTISTS_JOIN>%,' ')), or the default one

is it me, or the component which causes the error? other releases are working fine the last days of testing.

some other releases with the same error:
1438836
1912661
4253278
892808
3381267

Hmmm, interesting, all of these releases have no artists. I see what causes this error. The check for triangle brackets was meant to be helpful but it doesn't work these cases so it will have to go. Removing that check, things work as expected.

foo_discogs

Reply #1891 –
Quote from: zoomorph on
Quote from: fuffi on
When having an empty formatting string and the write/update is enabled, the component empties that tag from the file while updating all the tags.
This is actually a feature. There needs to be some way to erase a tag if desired

Short question: Why (should there a way to delete a tag in the component, while writting tags is the reason, I started the component)?

My thinking (until now) is:
If the user likes to delete a tag/any tags, it is easier to open the properties of the file(s) and just delete the tag(s) by hand, than to start your fine component and update all the tags just because he likes to delete a single tag which is left empty in the formatting string.

But knowing this, user can simply disable the empty tag(s) (assumes, he bears that in mind).

Also while working with the fomatting strings on a 24" monitor, I found it very hard to check the state of a string (enabled/disabled...),because its at the right outer space of the window and mostly minimized/shrunken so that the important formatting stings gets more space to read.

It would be great, to just move the column to the left like in the screenshot/mockup:



Quote from: zoomorph on
I suggest using an old version of the plugin for now if you need to update tags.

I guess, the old component will only update the "old" tags, no the new ones introduced by your changings?

Also, could you please explain to me, whats so difficult about updating tracks?

My thinking is very rudimentary here: the component get a release-id and a tracknumber, so it fetches all the infos for all the selected tracks which the user has checked as "updateable"

but it seems its not that easy... :-)


Thanks for your work+time!

foo_discogs

Reply #1892 –
Quote from: fuffi on
Short question: Why (should there a way to delete a tag in the component, while writting tags is the reason, I started the component)?

My thinking (until now) is:
If the user likes to delete a tag/any tags, it is easier to open the properties of the file(s) and just delete the tag(s) by hand, than to start your fine component and update all the tags just because he likes to delete a single tag which is left empty in the formatting string.

But knowing this, user can simply disable the empty tag(s) (assumes, he bears that in mind).

Two reasons:
1. It's more flexible. No way to delete a tag (write an empty string to a tag) when writing tags, would limit the abilities of tagging with foo_discogs.
2. It's more correct. Imagine something like REMIXED_BY was originally written to the tag, but upon updating tags the REMIXED_BY credit is gone or moved to a different track instead. Shouldn't the tag be erased from the old track? User won't manually delete tags in these cases.

Quote from: fuffi on
I guess, the old component will only update the "old" tags, no the new ones introduced by your changings?

Also, could you please explain to me, whats so difficult about updating tracks?

My thinking is very rudimentary here: the component get a release-id and a tracknumber, so it fetches all the infos for all the selected tracks which the user has checked as "updateable"

but it seems its not that easy... :-)

There are a few problems, like....

1. What if the track number tag is wrong? (It could have changed on Discogs?) The old method of updating tracks treats the track number tag as infallible.
2. What if the tracklist is parsed incorrectly, or the user manually "deleted" Discogs tracks when tagging the first time? The old method treats tracklist parsing as infallible (and yet is much dumber about parsing track lists, not supporting sub-tracks, hidden tracks, etc).

So my thoughts for the new version are...
- Is it possible to match tracks based on more things than just the track number? If matching can be done based on multiple things, then we'll have higher confidence in the results. If matching conflicts for different methods, the user should be prompted to intervene and match the tracks manually.
- However, I'm not sure if matching can be done on anything other than track number and durations (when available; often not). I haven't implemented any of these yet.
- One issue with this is that all the tags (even track number) can now be written very arbitrarily by the plugin. A likely good solution (haven't tried it yet) is to compute all tags for all tracks for the release, then compare those tags to the existing tags in the tracks, and match tracks based on which tracks have the most existing matching tags.
- Matching a single track is less reliable than a whole release, by the way. A matching option to assume all tracks are present would be very useful for detecting if the parsed tracklist has more tracks than files (ie. if the user "deleted" some tracks when tagging the first time, or something else is not right).

As you can see, I have a lot of ideas. The next thing I should implement is matching tracks based on existing tags (maybe which tags are used for this purpose should ultimately be configurable). Then I need to change how "update tags" works internally, to update a whole release at once instead of track by track. Then, I just have to figure out what options to put in the settings to allow the user to configure the behavior of their choice. Some users will only care to match based on track numbers, while others will want more reliability. :-)

foo_discogs

Reply #1893 –
Quote from: fuffi on
Hi zoomorph,

a Bug:

when removing a track from the "files", the tagging is not correct, and the removed track is tagged.

Good catch. Fixed.

Quote from: fuffi on
Hi zoomorph,

in addition to this post:

could you implement something which removes anchors from the url given in the "release id/url" textbox?

Quote
(FATAL) Error: Error loading release history?release=739629#latest: Page Deleted or Missing (404)(url: http://api.discogs.com/releases/history?re...=739629#latest)

I've added that.

Quote from: fuffi on
Anyways, I tested the last days and need to say, that it is -beside some glitches and things which don't work right now- it is a pleasure to work with your adapted component of bubblegum.

Thank you very much for the feedback!

P.S. - In case of interest, here is an updated build with all of the above fixes/updates. As well, the way tracklists are parsed should be improved as I encountered a few more cases that were parsed incorrectly before. https://www.sendspace.com/file/r7y3g2

foo_discogs

Reply #1894 –
Hi zoomorph,
I copied the new beta and will continue to test with that version. Thank you for the quick fixes!

Meanwhile, a little bug:

when loading a huge release-list from artist (A) and canceling the "find release"-window (not the fetchging-process-window, just the "find release"-window), to search for another artist (B), the release-list from the artist A shows up, although the name of artist B is typed in the Artist field.

Try to reproduce (maybe clear cache first):

1) open the "find release"-window, search for artists "Faith No More" 12937 (or any other with huge discography)
2) press "cancel"-button in the "find release"-window, (let the download fetching process window do its work in the background. don't touch it.)
3) open the "find release"-window, search for artist "Feder (3)"  2638565 (or any other with tiny discography)

result is, that the list from artist A is shown instead of artists B's list.

I couldnt reproduce it every time, you need to find the "right" time to open the "find release"-window a second time.

Anyways, its not bad, just a little iritating sometimes, and I could live with that, because:
its a great feature to let the artist list fetched in the background, while doing other work with the component. therefore, we save a lot of time, instead of waiting for each fetch-process to be completed.



another bug:
an empty tag name is possible, but never shows up in the properties window of the file:



Quote from: zoomorph on
Quote from: fuffi on
Short question: Why (should there a way to delete a tag in the component, while writting tags is the reason, I started the component)?
Two reasons:
1. It's more flexible. No way to delete a tag (write an empty string to a tag) when writing tags, would limit the abilities of tagging with foo_discogs.
2. It's more correct. Imagine something like REMIXED_BY was originally written to the tag, but upon updating tags the REMIXED_BY credit is gone or moved to a different track instead. Shouldn't the tag be erased from the old track? User won't manually delete tags in these cases.

hmmm.... I don't see its more flexible that way, I think its more dangerous then.

Second point, I'm not quite sure, I understood: the REMIXED_BY tag would always be ereased with an empty formatting string, never updated. So all files get their (filled or not filled) REMIXED_BY tag removed. What, when I have playlist-view-scripts in f2k which rely on the content of that (old) tag? The component just deleted my information.
(I don't talk for the REMIXED_BY tag only, also COMPOSER/PERFORMER and any other I could create in the component)

My optinion:
When the REMIXED_BY tag is delivered empty by discoGS Api (or emptied by the users custom string), then its fine&correct to write an empty tag to the file, or erase the tag).
The tag should not be removed when the formatting string field is left empty.

Idea: Maybe you implement another Status? Say "--REMOVED--" in addition to "Write/Update/Disabled", so the user needs to click explicit on "remove" to let the component erase the tag?

Well, I guess, I'll see what will happen in the future. Until then, I try to remember to disable empty formatting string, to not get important tags erased by accident.


As with the updating-tags-thing: I see you have great ideas! and I'm looking forward to test them ;-)  I would prefer the simple and fast solution first: update the tracks, identified by the tracknumber, because this simple task worked reliable for years with the "old" component.

foo_discogs

Reply #1895 –
Hi,

I don't quite understand why the Artist Name Variation only gives a single hit "Large Pro" on this release.

Artists Website shows:
Extra P, Larde Professor, Large Pro, Large Pro*, Large Prof, Large Prof., Large Professor, The, Large Proffessor, The Large Prof., The Large Professor, Xtra P


My settings in the components formatting strings:
DISCOGS_ARTIST_NAME_VARIATIONS: %<ARTISTS_NAME_VARIATION>%
Shows only: Large Pro

DISCOGS_ARTISTS_ALL_NAME_VARIATIONS: %<<ARTISTS_ALL_NAME_VARIATIONS>>%
Shows (same as website): Extra P, Larde Professor, Large Pro, Large Pro*, Large Prof, Large Prof., Large Professor, The, Large Proffessor, The Large Prof., The Large Professor, Xtra P

Why are those two contents differ? shouldnt they be the same?

Anybody can explain or help?

foo_discogs

Reply #1896 –
Hi zoomorph,

in your last beta (btw, pls add something like a versionnumber to the find release window, or update the internal version of the component so we know, what version we are testing) you did change something with the HIDDEN tracks, I guess? ;-)

for this release:

the working tracklist

changed to something way too trimmed:


Can you please change it (back), so its working again like expected (showing all tracks)?

foo_discogs

Reply #1897 –
I have a problem about album art. Although the configuration of the plugin is File prefix: %album% the filename of the image saved in folder is: _.jpg
How can I fix this?

foo_discogs

Reply #1899 –
Quote from: fuffi on
Hi zoomorph,
I copied the new beta and will continue to test with that version. Thank you for the quick fixes!

Meanwhile, a little bug:

when loading a huge release-list from artist (A) and canceling the "find release"-window (not the fetchging-process-window, just the "find release"-window), to search for another artist (B), the release-list from the artist A shows up, although the name of artist B is typed in the Artist field.

Wow you're good at finding bugs! Fixed this one and a couple similar.

Quote from: fuffi on
another bug:
an empty tag name is possible, but never shows up in the properties window of the file:

Yes, the component doesn't stop you from putting an empty tag name. It probably should as I don't think this is valid. :-)

Quote from: fuffi on
hmmm.... I don't see its more flexible that way, I think its more dangerous then.

Same thing! With great power comes great responsibility.

Quote from: fuffi on
Second point, I'm not quite sure, I understood: the REMIXED_BY tag would always be ereased with an empty formatting string, never updated. So all files get their (filled or not filled) REMIXED_BY tag removed. What, when I have playlist-view-scripts in f2k which rely on the content of that (old) tag? The component just deleted my information.
(I don't talk for the REMIXED_BY tag only, also COMPOSER/PERFORMER and any other I could create in the component)

My optinion:
When the REMIXED_BY tag is delivered empty by discoGS Api (or emptied by the users custom string), then its fine&correct to write an empty tag to the file, or erase the tag).
The tag should not be removed when the formatting string field is left empty.

I see, you're saying that tags should be erased by formatting strings that resolve to an empty string, as long as they aren't a blank formatting string?

In the settings, I added an option to remove existing tags from tracks before writing tags (with a possible list of exclusions). I see this ability to erase individual tags with a blank formatting string as being complementary; it allows deletion in advance of a specific tag, instead of everything but a specific tag.

Yes, I could ignore tags that have a blank formatting string, and then people would have to set it to something like "$if(,,,)" instead for this to work, but I find that quite odd. In my view, the user should just not set a blank tag formatting string if that's not what they want. :-\

Quote from: fuffi on
Idea: Maybe you implement another Status? Say "--REMOVED--" in addition to "Write/Update/Disabled", so the user needs to click explicit on "remove" to let the component erase the tag?

Overly confusing.

Quote from: fuffi on
Well, I guess, I'll see what will happen in the future. Until then, I try to remember to disable empty formatting string, to not get important tags erased by accident.

Why would you even create tags with an empty formatting string? I think some are there by default (COMMENT, etc) because they are in the foobar2000 properties window, but they are disabled. The intent was that users could enable and specify those tags if they desired, but by default foo_discogs didn't write them.

Quote from: fuffi on
Hi,

I don't quite understand why the Artist Name Variation only gives a single hit "Large Pro" on this release.

Artists Website shows:
Extra P, Larde Professor, Large Pro, Large Pro*, Large Prof, Large Prof., Large Professor, The, Large Proffessor, The Large Prof., The Large Professor, Xtra P


My settings in the components formatting strings:
DISCOGS_ARTIST_NAME_VARIATIONS: %<ARTISTS_NAME_VARIATION>%
Shows only: Large Pro

DISCOGS_ARTISTS_ALL_NAME_VARIATIONS: %<<ARTISTS_ALL_NAME_VARIATIONS>>%
Shows (same as website): Extra P, Larde Professor, Large Pro, Large Pro*, Large Prof, Large Prof., Large Professor, The, Large Proffessor, The Large Prof., The Large Professor, Xtra P

Why are those two contents differ? shouldnt they be the same?

Anybody can explain or help?

%<ARTISTS_NAME_VARIATION>% returns an array of name variations for the artist(s) for each track. This means either the track artist(s), if defined in the tracklist, or the release artist(s) defined at the release level. The name variation is the one used on the specific release, if applicable.

%<<ARTISTS_ALL_NAME_VARIATIONS>>% returns an array containing an array of ALL name variations available on the profile page, for the artist(s) for each track.

The latter one loads its info from the artist profile page, while the former loads from the release page only. They are returning quite different data. :-)

Quote from: fuffi on
Hi zoomorph,

in your last beta (btw, pls add something like a versionnumber to the find release window, or update the internal version of the component so we know, what version we are testing) you did change something with the HIDDEN tracks, I guess? ;-)

for this release:

the working tracklist

changed to something way too trimmed:


Can you please change it (back), so its working again like expected (showing all tracks)?

Yes, I changed the tracklist parsing algorithm. I have a list of about 20 odd cases that I want it to parse correctly. I found 2-3 cases that weren't working in the last release. Now it seems you've found a new case that isn't working. I'll add this to my list and see if I can get it parsing correctly, thanks!