proxy.log (1.9 KB)
more over 10/15 seconds and even more
proxy 2.log (3.0 KB)
Anyway, thank you for the effort and dedication. Sometimes Iām a bit too meticulous, but as I imagine you already know, us IT people are all cut from the same cloth.
Mp3Tag crashed for CPU temperartures almost 100 Degree *Celsius*.log (3.0 KB)
@Norbox, the logs answered it, thank you for sending them.
The proxy is not where your time goes. In your own logs every request comes back in one to two seconds, and it never once had to solve a Cloudflare challenge all day. Beatport currently has no protection on at all, so the browser never even started.
The awkward part: v2.0.2, the one that feels fastest, is the slowest in your own logs. Its track pages took three, three and six seconds. Everything from v2.1.1 onwards took one or two. I think the older version uses an outdated TLS fingerprint, which is why.
Where the ten to fifteen seconds actually go is Mp3tag itself. Beatport sends a 628 KB page for one track. The script first strips the HTML around the data, then runs fourteen more search and replace passes over what is left, then parses it. That is all processor work on your machine, no network involved, which is also why your CPU hits 100 degrees and Mp3tag falls over. Your old script feels quick because it does far less of this, not because of the proxy version.
Now the interesting bit. Out of that 628 KB, the data for your track is 1766 bytes. The rest is the charts and recommendations sections, which nothing reads. The proxy is the one place where that could be cut before Mp3tag ever sees it, and cutting it would take most of those seconds away.
I am not promising it yet, because there is one thing I have to test first: whether Mp3tag's parser will accept the trimmed page at all. If it does, this is exactly the kind of machine it would help most. If it does not, I will say so rather than quietly drop it.
@Norbox the version I mentioned is out, v2.5.0.
Beatport sends about 630 KB of page for a single track. The part the scripts actually read is under 2 KB of it; the rest is charts and recommendations that no tag source touches. The proxy can now cut all of that away before Mp3tag sees it, so instead of running more than a dozen search and replace passes over 630 KB, Mp3tag gets under 2 KB.
Going by your logs, that is where your seconds were going, so this is the change most likely to help your machine.
It is off by default. Right click the tray icon and tick Faster Beatport tagging. You get exactly the same fields, cover art and length included.
One honest caveat: this shrinks the work Mp3tag has to do, not the time Beatport takes to answer. If it still feels slow with it on, send the log again and we will see where the time actually goes this time.
Thanks for pushing on this one.
I've done a ton of testing, but nothing works. It's extremely slow and basically unusable. When I click the correct track in the LIST OF SEARCH RESULTS, it remains stuck for at least 10ā15 seconds, and the CPU goes into Thermal Throttling.
I suspect that the key is the fact that I managed to solve the problem by creating a .Src file that works. It has a few minor errors, but it runs extremely fast.
I think the key lies in the fact that I modified the [IndexFormat] string.
#super slow
[IndexFormat]=%coverurl%|% ā EXCLUSIVE%|% ā LENGTH%|% ā ISRC%|% ā TRACK ID (ā£ā¢)ā¢%|% ā RECORD LABEL%|% ā RELEASED%|% ā CATALOG%|% ā TRACK NAME%|% ā RELEASE NAME%|% ā ARTIST/S%|% ā REMIXER/S%|% ā GENRE/S%|%_URL%
#super fast
[IndexFormat]=% ā TRACK ID (ā£_ā¢)ā¢%|% ā RECORD LABEL%|% ā RELEASED%|% ā CATALOG%|% ā TRACK NAME%|% ā RELEASE NAME%|% ā ARTIST/S%|% ā REMIXER/S%|% ā GENRE/S%|%_URL%
This
! Beatport Track Search - 2026-09-06.src (20.3 KB)
Hi, i have a short question. Is it possible to reduce the amount of search results from default 150 to say 30? The loading of 150 Coverarts for completely irrelevant results takes a lot of time. Since I search with Artist/Track the right track is within the first 10 to 30 results- No need to scrape 150 tracks. Thank You.
Look this file: Beatport by &stevehero v6_Version History.md
Thank You Norbox, I removed the %_coverurl% parts of the script and now the 150 results are loading in one second, without the cover thumbnails in the results list.
@deesar Beatport does not let you ask for fewer results, I checked, it always sends 150. But you do not need fewer. Your own test showed why: with the thumbnails gone, those same 150 results loaded in one second. The covers were the cost, not the number of results.
@Norbox you were right, and you found it yourself: it is the thumbnail column in [IndexFormat].
What happened is that Beatport now sends a full size cover for every search result, about 169 KB each. Mp3tag downloads and unpacks all 150 of them just to draw the small icons in the list. That is roughly 25 MB per search, and it is the unpacking that heats the CPU.
v2.5.1 fixes this for you, with no script editing. The proxy simply asks Beatport for small covers instead, about 65 times lighter. You keep the thumbnails and you keep all 150 results. The cover art saved into your files stays full size, as before.
Turn on Faster Beatport tagging in the tray menu. The same switch also makes the track page itself much smaller, which is the other half of the 10 to 15 second wait Norbox had after clicking a result.
Great job, guys! It was a real team effort!ā
Thank you @The_Zhu and @Norbox now it works like a charm (even with the thumbnails in the results list)
Thanks at all involved!
