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 1346759 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

Re: foo_discogs

Reply #2650
Hi zoomorph,

sorry if it's been asked already but is anything planned regarding Discogs Tracks Feature?
What I'd love to have for instance is fetching genres / styles individually based on tracks.
Currently tracks aren't available via the API and track pages are pretty useless (they don't have genre/style info for example). However they will likely be added too foo_discogs if Discogs fully develops the feature.

Re: foo_discogs

Reply #2651
sorry if it's been asked already but is anything planned regarding Discogs Tracks Feature?
What I'd love to have for instance is fetching genres / styles individually based on tracks.
Currently tracks aren't available via the API and track pages are pretty useless (they don't have genre/style info for example). However they will likely be added too foo_discogs if Discogs fully develops the feature.

In case you guys care about Discogs Tracks and the future thereof, I made a thread about an angle that I felt is missing from the main Tracks discussion, which is mostly about the basic writing credits at this point and most people comment on from a pop/rock/jazz angle, therefore favour certain problems most found in those very large musical areas to be solved first.
Whereas for me there's a huge fundamental/conceptual black box, as to how Compositions are linked & treated withing this future system that is developing over the next months/years, which is especially notice-able when it comes to re-interpretations [which is the core of all musical evolution & progression of genres imo] (i.e.motifs, homages, remixes, covers, mashups, etc pp ). In case you have thoughts about this and want to chime in, here's a thread:
Tracks Update - compositions & handling of remixes, covers & versions ?
https://www.discogs.com/forum/thread/771656

Churs.
c.

Re: foo_discogs

Reply #2652
If you quickly scroll through the master releases, with tapping the CURSOR UP key from the last entry of the master releases list up to the first entry. every second master releases is skipped from opening and needs an extra tap to be opened. kinda strange.
It now only loads one at a time so you'll have to scroll more slowly.

Oh, thats not a good fix. Now, every second or third release will not open.

May it be possible to load the releases one after another, regardless how many times the user clicks on it?
So, if I click (or move the cursor), on a release, the fine component will remember to open it later, if all the loading has finished.

It also needs two or three clicks on a master release to load. (I guess, loading has not stopped yet, but how can I see it?)

Re: foo_discogs

Reply #2653
I found another release, where foo_discogs aborts and the user needs to restart f2k. Otherwise, the foo_discogs window is not closing and accepting any pressed buttons.

https://www.discogs.com/release/9456725

See the screenshots for the error: invalid map<K, T> key
The release date for that release on Discogs is invalid. The next release of foo_discogs will catch that error rather than crashing.
Thanks zoomorph,
I just wanted to try to fix the invalid date (now, there is a nice error description), but the date is empty?

Will the component now always show an error on empty release dates? This, I would love to silently be dropped and not shown as an error, because no date is no error, IMHO, its just no release-date.
Or am I missing something here?
The release date coming from the API is actually invalid (even though it shows blank on Discogs website). If you replaced it with a valid one, it would probably start to work.

Hmm. Ok, The Release Date from the "webgui" => https://api.discogs.com/releases/9456725
shows "2008-16-12".

How can I see the invalid date, like you see it? 8-)

Or I might open a ticked at discogs, maybe there is a problem with the release?


Re: foo_discogs

Reply #2655
Hmm. Ok, The Release Date from the "webgui" => https://api.discogs.com/releases/9456725
shows "2008-16-12".

How can I see the invalid date, like you see it? 8-)
year 2008, month 16, day 12.
OMG... thank you. I fixed the release date.


Just another note to:

Oh, thats not a good fix. Now, every second or third release will not open.
Some [M]aster releases do not open after some hours of work with tagging music with the fine component.
Foobar2000 restart is necessary to open the Master Release (and show all the releases) again.

For my testing I used "Figub Brazlevič" as artists and "Audiodope" as Filter.

The two shown results were
[M] Audiodope 02, 2013
and
[M] Audiodope 03, 2016
but the first (Audiodope 02, 2013) couldnt be opened.

(I guess its hard to reproduce as it worked fine after some tests, the glitch came after some hours of tagging...)

Re: foo_discogs

Reply #2656
2.16 fixes another crash I encountered when parsing certain track positions.

Re: foo_discogs

Reply #2657
2.17:
* Ignore/skip releases which 404 when updating tags.
* Wait longer with each successive http 429.
* Fix a problem with arrays only getting depth 1 when they should have depth 2, causing certain tagging strings not to work as they should.
* Fix wrongly parsing single track mix releases which use "1.x" for every track position.
* Skip "(silence)" when parsing hidden tracks, but add the duration of silence to the track duration.
* Add the duration of hidden tracks to the track duration. This is returned by DISCOGS_DURATION_SECONDS and used in matching tracks to files by duration.

Re: foo_discogs

Reply #2658
Zoomorph, thanks again for this most excellent extension and all your efforts to maintain it, great job!
Quis custodiet ipsos custodes?  ;~)

Re: foo_discogs

Reply #2659
2.18:
* Fix update tags not actually working if tag is set to update only (not write+update) and remove other tags option is enabled.
* During updating tags, write all tags in one task rather than opening a separate task for every release (potentially hundreds all at once).
* Error pop up to notify user when releases skipped due to 404 in updating tags.
* Use index track duration as track duration when only 1 track (including hidden tracks) is under the index track, if sub-track durations aren't specified.
* Fix parsing hidden tracks on vinyl with positions such as "A.1".
* New option to skip parsing Video tracks. (Skips any tracks in Discogs tracklist with "Video" or "DVD" in the track position.)
* "Previous" button to go backwards when matching tracks for multiple releases during updating tags.


Re: foo_discogs

Reply #2661
I think something broke over the updates from the past week?

I've tagged several releases with it (currently 2.18) and for some reason many of them do not fetch release or track CREDITS tag?

e.g.
https://www.discogs.com/Nova-Mob-The-Last-Days-Of-Pompeii/release/4826914
Those credits use "-" instead of " to " (as per the guidelines) to specify track ranges. This has never been supported by foo_discogs, but I just added it so the next version will support it.


Re: foo_discogs

Reply #2663
* "Previous" button to go backwards when matching tracks for multiple releases during updating tags.
Hi zoomorph,
thanks for the enhancements.
May it be possible to set some kind of keyboard-shortcut to all the buttons in your fine component?
So the users can simply use the keyboard to navigate and does not need to press buttons.
Say, the Previous button is accessible via ALT+P and the Next button via ALT+N.
The Write Tags button will be quickly usable via ALT+W.
The most important would be (for me): ALT+U and ALT+D for move up and down,
or ALT+R access the Remove button.

All those little helpers can make the fine component even more userfriendly.

Btw: I have not activated the Automatic Matching of tracklenghts, but the reddish indicator still shows me (some kind of useless) information about being not able to match. How can I disable the automatic matching?
Please see the attached images.

Re: foo_discogs

Reply #2664
smallish "bug":
prev button is not very useful when the user is on page 1 while updating some tags via "update tags..."


EDIT: Silly question:

What will happen, if the user selects "skip" while on match number 2 and 3, but then uses the prev-button and walks straight to match number 1 ?
Are the "skips" memorized?
 (Maybe we can get a little yellow skipped icon/text to recognize if a match is skipped or not)

Re: foo_discogs

Reply #2665
I just added it so the next version will support it.

thanks much - your work and this plugin are invaluable!
Actually, I take that back. My change to support this caused problems parsing the credits on some other releases so I reverted it. For the time being I suggest correcting the credit for this release on Discogs as per the guidelines (use eg. "1 to 5" for a range of tracks, not "1-5").

What will happen, if the user selects "skip" while on match number 2 and 3, but then uses the prev-button and walks straight to match number 1 ?
Are the "skips" memorized?
 (Maybe we can get a little yellow skipped icon/text to recognize if a match is skipped or not)
Skips are not remembered if you go back. The "previous" button was added mostly in case you make a mistake clicking "next" too soon and need to go back one. Yes, it's useless on page 1, but it's harmless.

If your files are in sorted order before tagging, I suggest checking both "match using track length durations" and "assume tracks are in sorted order". On the releases I'm tagging, about 75% of the time it's successful. Something like the example screenshot you show wouldn't need to be reviewed manually. :-)

Re: foo_discogs

Reply #2666
I think I found a bug in the plugin, or I completely miss a setting.
The plugin doesn't seem to force UTF8 encoding where necessary. I have a cue file with "Track##" filenames in ANSI codepage, and I'm searching for an album with tracks named in Polish with letters like ł and ń. I found correct release, pressed "Write tags" and saw correct letters in the playlist view. However the cue file got written in ANSI codepage instead of UTF8.

Re: foo_discogs

Reply #2667
I think I found a bug in the plugin, or I completely miss a setting.
The plugin doesn't seem to force UTF8 encoding where necessary. I have a cue file with "Track##" filenames in ANSI codepage, and I'm searching for an album with tracks named in Polish with letters like ł and ń. I found correct release, pressed "Write tags" and saw correct letters in the playlist view. However the cue file got written in ANSI codepage instead of UTF8.
I'm not quite sure, I can help, nor, if this component is responsible for this, but maybe you can test with this foobar2000 internal setting.

Re: foo_discogs

Reply #2668
What will happen, if the user selects "skip" while on match number 2 and 3, but then uses the prev-button and walks straight to match number 1 ?
Are the "skips" memorized?
 (Maybe we can get a little yellow skipped icon/text to recognize if a match is skipped or not)
Skips are not remembered if you go back. The "previous" button was added mostly in case you make a mistake clicking "next" too soon and need to go back one. Yes, it's useless on page 1, but it's harmless.

If your files are in sorted order before tagging, I suggest checking both "match using track length durations" and "assume tracks are in sorted order". On the releases I'm tagging, about 75% of the time it's successful. Something like the example screenshot you show wouldn't need to be reviewed manually. :-)
Thanks,
are you sure skips are not remembered ? In my tests, they were. funny.

Most of my files are in sorted order too, but the reason, I barely use this -maybe good working- function, is, that I need to switch the settings to see if it worked for the current release. Maybe you can think about a way to place some buttons on the Match Tracks window to get all the sorting options all at once? No settings-changing would be needed if there were 3 buttons with different sorting options. And its directly accessible from the gui, no need to fiddle with settings for each different-sorted release.
I think, this would be a benefit for most users, who then, just click a button to activate the sorting or revert it.

Re: foo_discogs

Reply #2669
Heya,
yea, it does work if the files have discogs tag syntax previously... try tagging completely empty files, and it will fail to inject the feat artist correctly. So you will need to run it once, to get the main tags, then run it again where it injects the feat artist on top. Odd & an annoyance, but works, once just has to remembeer to run the foo_discogs tagger twice on each new tagged release...

ah, I think I know what it's due as well now... but no idea how to fix it.
When running first, the %DISCOGS_CREDIT_FEATURING% field on file is empty, so once it's run, it's filled correctly, and only then does the $if engage... just a hunch, and not sure why it's not detecting the incoming foo_discogs data correctly here, but needs it to sit in file tags seemingly for this to work.
c.
What you're doing is reading the value of the DISCOGS_CREDIT_FEATURING tag when creating your TITLE tag, but the DISCOGS_CREDIT_FEATURING tag hasn't been written yet so it's blank. None of the tags actually get written to file until the end.

What you can do is use the special $pput(N,V) function to store the value of the DISCOGS_CREDIT_FEATURING tag when it's created, then use the $pget(N) function to retrieve the value when creating the TITLE tag. Note that the DISCOGS_CREDIT_FEATURING tag should come first in the list of tags for this to work.

Heya,
the above was one of those holiday projects to look into when I have more time...  as I would love to have a foobar/discogs title formatting code that:
- writes the track title
and - IF these credits exist:
- adds (Ft. '%DISCOGS_CREDIT_FEATURING%')
- adds ('%DISCOGS_CREDIT_REMIXED_BY%' Remix)
to the
%TITLE%
resulting in:
%TITLE% (Ft. '%DISCOGS_CREDIT_FEATURING%') ('%DISCOGS_CREDIT_REMIXED_BY%' Remix)
if either of the credits is available.

Alas, I only managed to get these to work IF the DISCOGS_CREDIT_FEATURING / DISCOGS_CREDIT_REMIXED_BY are set on the files itself previously... i.e. via:
$if(%DISCOGS_CREDIT_FEATURING%,%TRACK_TITLE%' (Ft. '%DISCOGS_CREDIT_FEATURING%')',%TRACK_TITLE%))
$if(%DISCOGS_CREDIT_REMIXED_BY%,%TRACK_TITLE%' ('%DISCOGS_CREDIT_REMIXED_BY%' Remix)',%TRACK_TITLE%))
which means I have to run the tagger 3 times...  :/
Any other attempt to do multi layered IFs & gets into foo_discogs ended up producing nothing usually... or utter nonsense in a hand full of cases...

In case zoomorph or anyone else fluid with Discogs formatting logic has examples of how one would cache discogs api/server data via
$put(N,V)
&
$get(N)
for discogs formatting of other fields; or maybe even post the above example, which seems to be a queried here as to how to get both injected correctly on the foo_discogs formatting documentation, that would be grand...

Churs.
c.

Re: foo_discogs

Reply #2670
Another Bug was found
It's a big one IMHO, I only had it a few times the last year(s), but now I could reproduce it.
Please see the attached animated GIF.

steps to reproduce:

Search for "The Vandals" with filter set to "Christmas With The Vandals".
It all releases are shown,  click "Vandals (10)" and then back to "The Vandals".

First, the fine component displays all found entries, after I clicked on "Vandals (10)" and back to "The Vandals" some releases are vanished.

Empty the cache and start again. All releases are shown.

Hope this helps.

Re: foo_discogs

Reply #2671
Hello alec.tron,

I'm not sure, I understood what you're trying to accomplish, but I read zoomorph stated $pput and $pget, but you trying to use $put and $get instead? I never have worked with those, so I cannot tell if one might be of better use.

What you can do is use the special $pput(N,V) function to store the value of the DISCOGS_CREDIT_FEATURING tag when it's created, then use the $pget(N) function to retrieve the value when creating the TITLE tag. Note that the DISCOGS_CREDIT_FEATURING tag should come first in the list of tags for this to work.
In case zoomorph or anyone else fluid with Discogs formatting logic has examples of how one would cache discogs api/server data via
$put(N,V)
&
$get(N)
for discogs formatting of other fields; or maybe even post the above example, which seems to be a queried here as to how to get both injected correctly on the foo_discogs formatting documentation, that would be grand...

Re: foo_discogs

Reply #2672
I'm not sure, I understood what you're trying to accomplish, but I read zoomorph stated $pput and $pget, but you trying to use $put and $get instead? I never have worked with those, so I cannot tell if one might be of better use.
True.
Looks like I grabbed $put & $get from:
https://wiki.hydrogenaud.io/index.php?title=Foobar2000:Title_Formatting_Reference#
which does not list $pput or $pget as available at all.

My main problem is understanding caching discogs API/server data to be used for other fields within foobars' scritpting/formatting syntax, and/or, constructing multiple nested IFs.
Oh how I wish there was python in foobar/foo_discogs...
c.

Re: foo_discogs

Reply #2673
Another Bug was found
It's a big one IMHO, I only had it a few times the last year(s), but now I could reproduce it.
Please see the attached animated GIF.
Another bug found (maybe the same origin)

This bug is similar to reproduce.
Please see the attached Screenshots to see the differens "before" -> "after" (check the "UK" in the Releases list)

search for "Andy Ash", filter "White Leaf".
Open the release, via Next-Button and then go back via Back-Button.
Click again on "Andy Ash", in the results list, or type something in the filter-window, or just click the Search-Button.
"UK" now shows up.