BlockTheSpot's config.ini is the instruction file for the patch. It holds the log level, the developer patch, a URL block list for ad and telemetry paths, LIBCEF offsets, the interface bundle files to modify, and a set of signatures and offsets for each patch. Each section can be enabled or disabled with an Enable flag. Use the official copy, change nothing you do not understand, and keep a backup.
Most ad blockers have a settings screen. BlockTheSpot uses a text file, and that is an advantage for transparency. You can read exactly which paths are blocked, which interface file is touched, and which bytes are changed. The file is also the record of what the project tested. Its header names the Spotify version it was written for, which at the time of our check was 1.2.83.461.
The file has two kinds of content. Some sections are simple settings: a log level and a list of URL paths. Others are signature-based patches. A signature is a short sequence of bytes or text that the patch searches for, and an offset tells the patch which byte to change relative to that signature. Because signatures depend on the exact code of a Spotify build, these sections are the ones most likely to break after an update.
The [Log] section has one setting, Level. The file explains the values: 0 disables logging, 1 records information, and 2 records debug detail. The copy we checked has Level=0. Leave it there for normal use. Raise it when you are troubleshooting, then set it back, because logs can hold details about your system.
The [Developer] section has Enable=1, and it contains a signature, a value, and an offset. This section is the developer-mode patch. The README describes developer mode as a way to open a debug window from Spotify's menu and try experimental options. It is not the ad-blocking section, so changing it will not turn ads on or off. Our developer mode guide covers the menu and its cautions.
This is the most readable section, and it is the core of the network-level blocking. It has an Enable=1 flag and a numbered list of paths. In the copy we checked, the list is:
/ads//ad-logic//gabo-receiver-service//desktop-update/Each entry is a path that the patch blocks, so requests to it do not complete. The first two are ad-related by name. The third has a name that does not say what it does, and we do not claim to know its exact purpose beyond what the file shows. The fourth has a name that appears to relate to updates, so blocking it may affect how the app checks for new versions. We cannot confirm that from the file alone. Read our update guide before you change that entry.
The [LIBCEF] section has Block_crashpad=1, which blocks the crash-reporting pipeline in the embedded browser layer. It also has three offsets: CEF_REQUEST_GET_URL_OFFSET=48, CEF_ZIP_READER_GET_READ_FILE_OFFSET=112, and CEF_ZIP_READER_GET_FILE_NAME_OFFSET=72. The file itself labels these as details for people who know what they are. Do not change them without a clear reason, because they are tied to the internal layout of the embedded browser.
This section has Enable=1 and lists two interface bundle files: xpui-snapshot.js and xpui-pip-mini-player.js. Those names tell the patch which Spotify interface files to modify. Each name links to its own section further down the file, which contains the actual patches.
This section lists the patch names for one interface bundle: adsEnabled, ishptohidden, skipsentry, disable_metric, premium_btn_begin, and premium_btn_end. Each name has its own subsection with a signature, a value, and an offset. The adsEnabled patch is the one behind audio ad blocking. The disable_metric patch targets a page-load metrics call. The premium_btn entries target the upgrade button. The skipsentry entry targets a function that appears to read a build version and make a network request. Its patch changes a comparison so the condition is false, which means the call is skipped. The file's comments are the best guide to its purpose.
This section holds the mini-player patch. It has two patch names, miniplayer_begin and miniplayer_end, each with a signature and a value. Because the mini-player is an interface component, these patches only change how that component renders. If the mini-player misbehaves after a change, the patch and your build likely disagree.
This section has Enable=0 in the copy we checked, so it is off by default. It has a signature, a value of none, and an offset of 97. The 2026.02.12 release is titled "hide canvas option(home_vbar)", which suggests this is the option for hiding a canvas element on the home screen. Enable it only after reading the release notes, and only if you are prepared to test the result.
Most sections begin with an Enable flag. A value of 1 means the patch uses that section. A value of 0 means it skips it. This makes it possible to test one section at a time, which is a sensible way to troubleshoot: turn off a section, restart Spotify, and see whether the behaviour changes. Always make one change at a time, and write down what you changed.
The config is tied to a Spotify build. When Spotify changes its code, the signatures may no longer match, and the patch skips them or fails to apply. That is why the README asks you to download the latest config.ini on each update, and why our status page points to the version named in its header. A matching config is the best sign that the patch is current for your build.
config.ini is the readable heart of BlockTheSpot. Its URL block list shows exactly what is blocked, its signature sections show what is patched, and its Enable flags let you switch parts off. Treat it as a precise instrument: read it, back it up, change it rarely, and always match it to your build.
Once you understand the sections, the features page lists what each one does in practice. Before you change any value, keep a backup as described in the uninstall guide, and verify the files on the verification page.
It is the plain-text file that tells the patch which URL paths to block, which Spotify interface files to modify, and which byte signatures and offsets to look for. It is the instruction set for the patch, and it is published in the official repository.
Most people should not. The default values match the project's tested setup. Edit only if you understand the section you are changing, and keep a backup of the original file so you can restore it.
The section is switched off, so the patch skips it. In the copy we checked, the Homepage_vbar section has Enable=0, which means that option is off by default.