As I understand it, Rob liaised with the VLC team, they made changes.

The traffic dropped off back to normal levels within a month or so.

Now that the database server is much happier, I have increased the rate limits somewhat:

• global changed from 1100 to 1300
• vlc/nsplayer changed from 10 (each) per 10s to 20

Looks like the ratelimit was lowered even further a couple of hours ago - 10 req per seconds for each for libvlc, nsplayer.

They seem to be using it to find cover art.

Unclear what VLC Player is actually using Musicbrainz for.

Illustrates drop in requests when NSPlayer clients were rate-limited too.

Since (for reasons not yet known) it looks like these clients were trying VLC ua-string, then NSPlayer UA-strings, rate-limiting only VLC did not cause a reduction in traffic going to the back ends (which was, after all, the goal of the rate limit). Rate limiting NSPlayer too, though, has.

Forgot to say, hence also rate-limited user-agent=NSPlayer clients.

Noticed today that the VLC clients are retrying a fair bit, e.g. each client makes 1-2 requests per second, the first few with the VLC User-Agent string, then with "NSPlayer/7.10.0.3059".

Top user-agents, all requests, last 10000 log lines just now:

0.73% 73 Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.0.18) Gecko/2010032613 Songbird/1.7.3 (20100608172956)
0.91% 91 vlc 1.1.0-rc
0.94% 94 MusicBrainz-Picard/0.11
1.84% 184 Magic MP3 Tagger 2.2.6
2.29% 229 Banshee/1.6.1 (http://banshee-project.org/)
4.44% 444 Jaikoz/3.6.0
4.75% 475 -
6.99% 699 MusicBrainz-Picard/0.12.1
17.84% 1784 NSPlayer/7.10.0.3059
41.12% 4112 vlc/1.1.0 LibVLC/1.1.0

Hence VLC/NSPlayer == approx 58% of all requests right now.