Minor bug in "Volume ease up" and new feature request

[Quqas]

1. Bug Report: "Volume ease up" initialization issue
Description:
It seems that the "Volume ease up" feature requires some form of persistent state or cache to function correctly. On a "cold" start e.g., in Incognito mode , the feature fails to trigger for the first track.
Steps to Reproduce:
Open in Incognito/Private mode.
Start playback of the first song.
Observe the initial volume level.
Actual Behavior:
The first song starts immediately at 80% volume without any gradual increase.
Expected Behavior:
The volume should transition smoothly from 0% to the target level even on the first run.
Notes:
Refreshing the page fixes the issue, and the feature starts working as intended.
In standard browsing mode, it works consistently, likely because the necessary data is already cached.

2. Inquiry/Request: Investigate Geo-blocking Bypass after User Login
Description:
I would like to request an investigation into a recurring geo-restriction issue that appears specifically when a user is logged into their account.
Guest Mode: If not logged in, the service (and the script) works normally even in restricted regions.
Logged-in Mode: Immediately after authentication, the site redirects to https://www.di.fm/restriction.html with the message: "We're sorry, but ad-supported DI.FM service is not available in your region."
Reproduction for the Author:
You can reproduce this by using a VPN (e.g., HolaVPN for Chrome) and setting your location to Russia. You will notice that the redirect only triggers for logged-in accounts.
Technical Note:
I have tried monitoring the process with the "Preserve log" option enabled in DevTools, but I am unable to pinpoint the exact function or request causing the redirect. It seems my technical knowledge is insufficient to track down the cause in the console logs .
The Ask:
Since the script was recently updated, I was hoping you might have come across the logic responsible for this location check. Is there any way to intercept this check or suppress the redirect via the userscript? I hope your expertise can help uncover a workaround for this restriction.

[lethak]

Hi, as always thanks for your report.

In this case, the volume is set to 80% in the native code. This probably happens after the ease up is triggered, and is consequently interrupting it immediately because it is set to interrupt if the user is making a volume change during the ease up.
Since there is no easy way to know if the volume change was requested by the user in the volume bar or programmatically ordered from the native code, this may be tricky to fix, I'll try to see if something can be done in a next script release (as always no ETA)

As for your other point I already checked years ago and geofencing is done server side, nothing the script can do about it.
The fact it only do it while logged in is weird tho, but don't change the fact the logic is outside of the script realm.
Have you tried creating a new account while using a VPN ? or do the geofencing work based on your current IP location only ?
Depending on their logic you may be able to use an account created from outside the fence. You'll have to test.