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

Re: foo_discogs

Reply #2425
Hi zoomorph,

I'm jumping in a limitation of the DG-api...dunno why, "{"message": "You are making requests too quickly."}"

but the real problem here is, that I cannot abort the "Generating tags...." Process/Window while trying to update tags.

Pressing a very often on the ABORT button does nothing. since 5 minutes, I click the ABORT button, but the f2k-log shows that the fine component is still fighting... I can see it tries to load all the artists in the "queue" of the release, but cannot, because of the rate-limit...

I guess, the ABORT button works, when the queue is done.... so I'll wait ... because I don't want to kill f2k.


Quote
[01:52:42] foo_discogs: Rate-limited. Retrying: 2
[01:52:46] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:52:47] foo_discogs: Rate-limited. Retrying: 3
[01:52:50] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:52:51] foo_discogs: Rate-limited. Retrying: 4
[01:52:55] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:52:55] foo_discogs: Rate-limited. Retrying: 5
[01:52:59] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:52:59] foo_discogs: Rate-limited. Retrying: 6
[01:53:03] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:53:03] foo_discogs: Rate-limited. Retrying: 7
[01:53:07] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:53:07] foo_discogs: Rate-limited. Retrying: 8
[01:53:11] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:53:11] foo_discogs: Rate-limited. Retrying: 9
[01:53:15] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:53:15] foo_discogs: Rate-limited. Retrying: 10
[01:53:19] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:53:19] foo_discogs: Rate-limited. Retrying: 11
[01:53:23] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:53:23] foo_discogs: Rate-limited. Retrying: 12
[01:53:27] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:53:27] foo_discogs: Rate-limited. Retrying: 13
[01:53:31] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:53:31] foo_discogs: Rate-limited. Retrying: 14
[01:53:35] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:53:35] foo_discogs: Rate-limited. Retrying: 15
[01:53:39] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:53:39] foo_discogs: Rate-limited. Retrying: 16
[01:53:43] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:53:43] foo_discogs: Rate-limited. Retrying: 17
[01:53:47] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:53:47] foo_discogs: Rate-limited. Retrying: 18
[01:53:51] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:53:51] foo_discogs: Rate-limited. Retrying: 19
[01:53:55] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:53:56] foo_discogs: Rate-limited. Retrying: 20
[01:53:59] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:54:00] foo_discogs: Exception handling: https://api.discogs.com/artists/75617?oauth_consumer_key=sVfZTDvOdz&oauth_nonce=1485566784&oauth_signature=THdhO%cnBQq9DI%3D&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1485305556&oauth_token=DVvpJwdAkTojNMzxN&oauth_version=1.0
[01:54:00] foo_discogs: Error processing field ARTISTS_ALIASES : Error loading artist 75617: Too Many Requests (429) [Discogs API rate-limit reached.](url: https://api.discogs.com/artists/75617)
[01:54:00] foo_discogs: https://api.discogs.com/artists/75617?oauth_consumer_key=kQTDvOdz&oauth_nonce=148504ae1&oauth_signature=eeN2kbs6ORUEwt%2Fuk%3D&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1485305640&oauth_token=DVvvcaLroWWjUUenzxN&oauth_version=1.0
[01:54:02] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:54:02] foo_discogs: Rate-limited. Retrying: 1
[01:54:06] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:54:06] foo_discogs: Rate-limited. Retrying: 2
[01:54:10] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:54:10] foo_discogs: Rate-limited. Retrying: 3
[01:54:14] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:54:14] foo_discogs: Rate-limited. Retrying: 4
[01:54:18] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:54:18] foo_discogs: Rate-limited. Retrying: 5
[01:54:22] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:54:23] foo_discogs: Rate-limited. Retrying: 6
[01:54:27] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:54:27] foo_discogs: Rate-limited. Retrying: 7
[01:54:30] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:54:30] foo_discogs: Rate-limited. Retrying: 8

Re: foo_discogs

Reply #2426
It seems, the DiscgoGS guys have limited their API (of just my account...?) for requests per $time.

Now it takes about 5 minutes to tag a release with more than 8 artists (say, a compilation with 15 artists) or just to retrieve the release-list for cliff richards:

Quote
(FATAL) Error: Error loading artist releases125101: Too Many Requests (429) [Discogs API rate-limit reached.](url: https://api.discogs.com/artists/125101/releases)

[ESCAPE to close]
(also see the log from the above post)

I figured out, that after 8-13 single fetches, a "foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests" comes up in the log and -unfortunately, after a long waiting time-, an error message appears, telling the user of f2k the above message.

For some small releases, the cache will store the fetched releases (i.e. when updating some albums at once) and then it is possible to continue tagging, but for most (big?) releases, it fails to fetch the information completly.

Thats a pitty and makes tagging files very inconvenient and time comsuming, sometimes impossible.


@zoomorph, is there a way to specify the time, the cache will stay in f2k? now, it seems, the cache is deleted every f2k-restart, or when the user switches the hidden-track-feature.

would it be possible to specify an amount of time (say, in minutes, so we can specify 10 days to refresh the cache for a single artists or release)


On the other hand, I can understand the DG guys, limiting their access bandwitdh, when we're fetching a release list of, i.e.,  the beatles, because that took about 4 minutes and -maybe?- caused a lot of traffic/moving on their server(s).

When I got the time, I try to read in their forum, if its really a limitation of the API (and not only to my account), I wonder, what other software will be affected too, and what the ppl say.

Re: foo_discogs

Reply #2427
I took a look at the page but as I don't have the original release by my side, I cannot correct something, I do not have a clue about.
Obvious mistakes, spellings or adjustments I can fix, but here, I don't know (also do not understand), what the original submitter wanted to add.
If people can't fix a Discogs page, they can still leave a comment in the edit history so that others who can fix it will see that there is a problem.
Quis custodiet ipsos custodes?  ;~)

Re: foo_discogs

Reply #2428
Thanks so much for this great plugin!  I use it just about every day.

Re: foo_discogs

Reply #2429
anyways, just another boring old question:
why is the "parse hidden track"-feature working here,
but not here?
foo_discogs doesn't support parsing subtracks in vinyl track names. IMO it's not really a valid way to enter track positions, but some clarification is required to the Discogs guidelines.

[/quote]
would it be possible to skip invisible/non-printing chars while tagging a release?
here https://www.discogs.com/x/release/8250412
is a hidden tab (or something like that) in track 01.
You could try the function $trim(), not sure if it will remove a tab. Otherwise you could try $replace(). It is a clear error in the database though, so I would suggest removing it there.

Hi zoomorph,

its been a long time, since I changed something to my formatting strings.

Today, I regognized, that to my tag "DISCOGS_ARTISTS_ALL_NAME_VARIATIONS" with the formatting string "%<<ARTISTS_ALL_NAME_VARIATIONS>>%", something like this is written to a file:

[...], Michael Sammes Singers And Orchestra, Michael Sammes Singers, The, Mike Sammes & His Famous Singers, Mike Sammes & Male Quartet, Mike Sammes & The Singers, Mike Sammes Chorus And Singers, Mike Sammes Quartet, Mike Sammes Singers And Orchestra, Mike Sammes Singers, The, Mike's Singers, Sammes Chorus, Sammes Chorus, The, The Michael Sammes Singers, [...]

Is there a way to replace the comma "," with an semicolon ";" ? so automatic scripting or manual reading of ANVS do not confuse? :-)
Yes, if you use the $join() function you can specify it. If you don't specify, then by default it's joined with ",".

Re: foo_discogs

Reply #2430
unfortunately, DISABLING all the release_credit tags did not work.
the error does not stop for this release.

Is there anything I can do, beside updating the release on the discoGS database, which I'm too dumb to do..?
Parsing the credits is done at the same time as most of the other info for the release, so yea, it will throw the error even if you don't use the credits in your tags.

In this case, I think there is a "." instead of a "," in the last credit.

Re: foo_discogs

Reply #2431
There´s a bug:

"FATAL) Error: Error loading artist releases2549: Too Many Requests (429) [Discogs API rate-limit reached.](url: https://api.discogs.com/artists/2549/releases)

[ESCAPE to close]"

..happens, when an artist with more than 4 or 5 sites is being fetched.


EDIT: i think its a discogs problem - could it be that they have limited the number of possible requests)?
ic, im not the only 1 with this problem...

On Release 14 it hangs here...that happens with several Releases on different pages...


http://prntscr.com/e1dbjd


Re: foo_discogs

Reply #2433
@laerm
@kola
read my post(s), which are only 5 posts above yours.
after that, read the linked discogs forum threads and check for further information in the links listed there. (and so on)

Re: foo_discogs

Reply #2434
hi zoomorph,
today an error, which i never encountered before :)

as the image-title says, that came up, while updating some art from those releases at once:
367528; 367533; 682675; 749912; 4273779; 1174652; 1921374; 4135785

EDIT:
and while trying updating the tags


EDIT2:
and while trying to tag this below album just the "normal" way, via "write tags..." but after closing the error window, it's not possible to quit the find-release-window anymore. nor next, nor cancel is possible. I need to restart f2k.

Re: foo_discogs

Reply #2435
Heya,
I've had a bigger tagging session this weekend, and this was a first with/for foo_discogs, but has happened 5-10 times over the last days, so I thought I mention this:
- mostly happened with Various Artist / compilation albums
- when caching artist info, triggered through 'Preview Tags', this seems to have become a lot slower generally (or, the increase in discogs data I inject, i.e. all artist aliases etc, is to blame here ?). i.e. having it query discogs for 30-120 seconds per multi artist album seems to have become the norm.
- but, today I also had 5+ crashes, sometimes only "freezing" the foo_discogs & the fetch-status-bar window, for multiple minutes, after which an 'Abort', which takes a few minutes to complete too, produces this:
"
(FATAL) Error: Error generating tag DISCOGS_ARTISTS_ALIASES [] for file file://D:\folder\folder\folder\01_Artist-Track.mp3

[ESCAPE to close]
"

Furthermore, in 2 cases aborting the 'frozen' fetch window did not produce the above, but took down all of foobar. No data loss or file corruption afterwards, but odd still.
Anyone else experiencing this ?
Also, I have not found a way to reproduce it, other than that multi-artist albums being more likely to trigger the above.

Churs.
c.

ps. one other oddity - once the (FATAL) Error: Error generating tag DISCOGS_ARTISTS_ALIASES error appeared, when trying the same again from the same window where it previously failed and errored on 'Preview Tags', the 2nd attempt usually goes straight through and caching takes 1-2 seconds, and the Preview Tags window pops up as expected.

Re: foo_discogs

Reply #2436
In case it helps, and/or zoomorph sees something wrong with these - the foo_discogs freeze happened again. Maybe the artists it happens on could act as breadcrumbs ?
(with the status bar, of the "Generating Tags..." window stating:
Processing: Loading artist 387715...." ):

Stuck on this for 2+ minutes:
https://www.discogs.com/artist/387715-Chuck-Turner
then errored with:
"(FATAL) Error: Error generating tag DISCOGS_ARTISTS_ALIASES [] for file file://D:\folder\folder\folder\[greensleeves]\[GREZ 010] VA-Greensleeves Sampler 10\15 - Run Around Girl.mp3

[ESCAPE to close]"

Again, once the error occured, a second attempt of the same goes through immediately, I can even see the "Generating Tags..." window pop up, and it opens the "Preview Tags" window right away...

c.






Re: foo_discogs

Reply #2437
Parsing the credits is done at the same time as most of the other info for the release, so yea, it will throw the error even if you don't use the credits in your tags.
Is there any chance to tag a single file, say track 4-15 "Björn & Benny, Agnetha & Anni-Frid - Ring Ring" from this release
now that we have the new dg-api limitation?

having only this song in the "Match Tracks" window, it seems impossible to tag this single file. After a few artists a loaded,
the log throws endles amounts of
Quote
01:50:27] foo_discogs: HTTP error status: HTTP/1.1 429 Too Many Requests
[01:50:27] foo_discogs: Rate-limited. Retrying: 19


It seems, the fine component snatches too much and too often off the api and the api does not like that.
how can we lower the requests per .... errm... seconds... stupid idea, i know... but, I must say, using the fine component is now nearly impossible on compilations or releases with a lot of meta-data....

it was a very good start, now, with that api-limitation, it seems hopless to enjoy the disco-gs database we filled with this great f2k-component.

Re: foo_discogs

Reply #2438
anyone knows, where the error in this release is?
Quote
(FATAL) Error: Error loading release 2695782: JSON Parser ExceptionError parsing release credits.


Re: foo_discogs

Reply #2440
@frogworth
thank you, that worked. I guess, I'm getting a little bit more understanding time by time. thanks again!

@zoomorph:
In addition to my posting here,

its not possible anymore to load artist listings for i.e. artists with large lists of releases.

Quote
(FATAL) Error: Error loading artist releases89631: Too Many Requests (429) [Discogs API rate-limit reached.](url: https://api.discogs.com/artists/89631/releases)

it would be great if the fine component could resume the release-fetching and not start over again, when clicking on an artist.

I created and used different discogs users to verify its not my account which has the limitations, but the problem remains.

Re: foo_discogs

Reply #2441
It looks like Discogs added new/increased rate limits on how fast we can access the API. I'll have to look into that some time. For the time being, all I can suggest is to wait or try again later. If you open the foobar2000 console while foo_discogs is taking a long time, you'll probably see a lot of rate limit errors from Discogs. (Eventually after enough tries it stops and throws an error.)

Re: foo_discogs

Reply #2442
For the time being, all I can suggest is to wait or try again later.
Yes, imho, the most important "inconvenience" with that is, that the ABORT button will not abort ("Generating tags...") and the user has to wait until all the timeouts are processed. (so updating a compilation with >10 artists gives the user a 5-15 minutes waittime until the fetching is aborted.)

If you take a look at my posts above, you'll see all the log entries.


Re: foo_discogs

Reply #2444
This is a question only zoomorph, the maintainer of foo_discogs, could answer... but If that API query limit is timed at (240 / 60 =) 4 per second, it would explain why we're all running into timeouts /  rate limiting server responses regularly nowadays, especially when tagging compilations etc.
Stink.
c.


Re: foo_discogs

Reply #2446
This is a question only zoomorph, the maintainer of foo_discogs, could answer... but If that API query limit is timed at (240 / 60 =) 4 per second, it would explain why we're all running into timeouts /  rate limiting server responses regularly nowadays, especially when tagging compilations etc.
Stink.
c.
That indeed seems to be the case and you don't even need Wireshark, it's all in the console. The first four packets go through just fine, but on the fifth one you immediately get a 429. Then again those four requests fire within one second, more like three or four, but still.

Re: foo_discogs

Reply #2447
I still think though the main issue is with the user agent string, which seems to be set to "Opera/9.50". The API documentation encourages to use a "unique" user agent so that the number of requests doesn't get throttled. Not sure how to approach this exactly though. Should it be unique to the plugin? Unique to the user? Unique to each request?

Might try some stuff once I have all the dependencies set up and the project loaded correctly.

Re: foo_discogs

Reply #2448
the discogs pone script in mp3tag works flawlessly, so this seems not to be a problem with discogs at all...