topic Re: Dynamic playlist download queue ignores "Download over cellular" being off when switch in Android

Dynamic playlist download queue ignores "Download over cellular" being off when switching network

ericvw — Sun, 26 Jul 2026 23:11:06 GMT

Plan: Premium
Country: USA

Device: Pixel 10 Pro

Operating System: Android

Data-saving and offline

Data Saver Mode: Automatic
Offline access: On
Download over cellular: Off

Media Quality

Wi-Fi Streaming Quality: Lossless
Cellular Streaming Quality: Automatic
Auto-adjust: On
Download: Lossless

Description

I am seeing intermittent, extreme cellular data spikes from Spotify—typically 1.5 GB to 2 GB in a single short burst—despite strictly disabling "Download over cellular".

This issue likely went under my radar before, but switching my download quality to Lossless has made the bandwidth impact immediate and severe. A standard 50-track Daylist in Lossless format aligns perfectly with the 1.5–2 GB spike profile I am experiencing.

Suspected Root Cause

The bug occurs during network transition when a download queue is already active:

While on Wi-Fi before heading out, I open Spotify and notice that a dynamic playlist (like Daylist) is out of date or needs to sync.
I initiate the sync/download on Wi-Fi, then switch to playing a previously cached static playlist.
When I step outside, and my phone switches from Wi-Fi to cellular, Spotify fails to pause or cancel the active background download job.
The app continues downloading the dynamic playlist over cellular until completion, completely ignoring the "Download over cellular: Disabled" setting.

Steps to Reproduce

Set Download Quality to Lossless and ensure Download over cellular is turned OFF.
Connect to Wi-Fi and trigger a download/sync for a dynamic or large playlist (e.g., Daylist).
Immediately disconnect from Wi-Fi while the queue is actively downloading.
Expected Behavior: Spotify halts all active download tasks until Wi-Fi reconnects.
Actual Behavior: Spotify keeps pulling the queued track files over cellular, consuming gigabytes of data in minutes.

Supporting Evidence

I have attached screenshots from my device showing the precise nature of the spike:

Google Fi Data Usage History: Shows a normal baseline of <50 MB/day, punctuated by a single ~1.8 GB spike during a 6-minute walk. (See attached image 1)
Google Fi Daily Data Usage
Android Data Usage by App: Confirms Spotify as the sole culprit at 1.68 GB of usage. (See attached image 2)
Android Data Usage by App

Additionally, I have downloaded my streaming history to see if I could get any more insight into the timeframe when the spike occurred. I see the 4 songs I played that were from my static, downloaded playlist, which wouldn't have contributed to nearly 2GB of data usage. This further indicates that, in some circumstances, the dynamic playlists set to download may not respect the cellular download settings.

Has anyone else replicated this handoff bug where an in-flight download queue bypasses the cellular download settings being Off?

Re: Dynamic playlist download queue ignores "Download over cellular" being off when switching net...

Ivelina — Mon, 27 Jul 2026 10:03:58 GMT

Hello there @ericvw,

Thanks for reaching out via the Community! We really appreciate the thorough details and screenshots, they're incredibly helpful for our investigation.

As we've come across similar reports, we need a bit more context to pinpoint the issue you're experiencing. When you have a moment, please share the following details and try these quick tests:

Your current Spotify version, as well as the Android version on your phone.
Did this start happening right after a specific Spotify or Android update?
Remove the specific dynamic playlist (e.g. Daylist) from your library. Does the download stop, or does it continue in the background?
Start downloading a large static playlist on Wi-Fi, then disconnect from Wi-Fi while it's actively downloading. Does it continue over cellular?
When the data spike occurs, do you see a download progress indicator (like the green arrow) or does it happen silently?

It's also worth going over the following troubleshooting steps if you haven't already:

Go to Android Settings > Apps > Spotify > Mobile data & Wi-Fi. Is Background data enabled? If yes, does turning it off prevent the spike?
As a last resort, you can also perform a clean reinstall to clear the cache and possibly fix performance issues. Note: This will remove your downloaded content, so you will need to re-download your music afterwards.

Thank you once again! We hope to hear back from you soon and are here in the meantime if anything else comes up.

Re: Dynamic playlist download queue ignores "Download over cellular" being off when switch

ericvw — Mon, 27 Jul 2026 17:35:40 GMT

Spotify version: 9.1.68.1888

Android version: 17 (Build CP2A.260705.006)

This started "happening" (more likely noticed) since Lossless was rolled out, and I enabled it for my downloaded songs settings. My best guess is that, since Lossless consumes significantly more download space, it triggered thresholds in my Google Fi account for the spikes in usage, where High likely spiked but wasn't significant enough to reveal the latent issue.

If I remove the dynamic playlist from my Library, it will be removed from my Library and won't be downloaded. If I can catch my Daylist changing and redownloading, I will try this to see if I can observe whether it stops or continues downloading in the background. However...

When starting to download a large static playlist over Wi-Fi, then disconnecting from Wi-Fi, it continues downloading!!

So it appears to be a general downloading issue: when a playlist begins downloading over Wi-Fi and then transitions to Cellular, that is the bug. I would have expected it to pause or halt until Wi-Fi is reconnected.

When I was testing this, I did see the progress bar continuing to download with the count increasing when Wi-Fi was disconnected and my phone was on cellular

My Background data was turned off during the static playlist test above. When I conducted the test, I went back to my home screen (Spotify still running in the background) to check the notification tray to see the download progress.

I hope all this information helps. It seems we were able to reproduce this issue consistently with any playlist when switching from Wi-Fi to cellular. I hope this can be escalated to the appropriate Engineering team for review and resolution.

Re: Dynamic playlist download queue ignores "Download over cellular" being off when switch

Paula_Vi — Mon, 27 Jul 2026 23:36:06 GMT

Hi there, @ericvw

Thanks for coming back to us and thanks for all the details!

We haven't been able to replicate the issue, so it would be very helpful if you can send us a video/screen recording of the whole behavior. You can attach it to your next response by using the Insert Video option in the post editor.

You can also upload it as an unlisted video to YouTube or to Google Drive and share the link with us (make sure the video has all the permissions for anyone to watch it).

We'll be on the lookout for your reply!

Re: Dynamic playlist download queue ignores "Download over cellular" being off when switch

ericvw — Mon, 03 Aug 2026 11:02:32 GMT

I wasn't able to replicate the static playlist download issue as originally prescribed.

I requested my full data export (Account data + Extended streaming history + Technical log data) and dug through the technical logs for the day of the spike. Posting the findings in case it helps an engineer to track this down, and in case anyone else wants to check their own export the same way.

Spike observed: July 23 2026, ~12:50 pm - 3:15 pm ET (carrier data usage)

What the export shows

All times below are UTC unless marked EDT (UTC-4). Source files are named per section.

The setting was off the whole time.

[removed by Mod] - the setting snapshot closest before the spike (13:27:02 UTC) and closest after (21:20:43 UTC) both read:

[removed by Mod]

So "Download over cellular" was off, confirmed, bracketing the whole window.

A 1.2 GB download burst happened in about 2 minutes

[removed by Mod] (per-file download telemetry) shows 45 offline-sync downloads between 16:59:33 and 17:01:02 UTC (12:59:33-1:01:02pm EDT, totaling 1,214 MB, each at 700 kbps (myWiFii sync bitrate, not a cellular fallback bitrate).

Every single one of those 45 records reports:

[removed by Mod]

100% attributed to Wi-Fi. For context, carrier attribution isn't broken in general on my account - 234 other mobile download records elsewhere in 2026 do show nonzero [removed by Mod] - so the Spotify app genuinely believed this burst happened on Wi-Fi.

What actually triggered the burst: a silent daylist swap

This is the part I hadn't expected. Cross-referencing [removed by Mod] and my extended streaming history:

16:58:19 UTC: I was live-streaming "Keystone" by dwelyr ([removed by Mod], not played from cache). That track belongs to that morning's daylist, "chill house electronic thursday early morning," generated at 11:44 UTC.
16:58:53 UTC: 34 seconds later** - Spotify silently generated a new daylist, "chill house electronic melodic thursday afternoon," replacing the one I was still listening to.
16:59:33 UTC: 40 seconds after that, the 45-download, 1.2 GB burst begins, syncing the new daylist's tracks for offline playback.

So the trigger isn't a manual action - it's Daylist's automatic time-of-day refresh.

The smoking gun: I really was on T-Mobile cellular the whole time

[removed by Mod] (Spotify's own self-reported network type) shows [removed by Mod] at 14:11 UTC and again at 18:55 UTC, with nothing logged in between - and that same event listener is clearly sensitive enough elsewhere in my export (874 logged transitions across the year, some 119ms apart). I assumed a real handover during the burst would have been caught. So I initially concluded that this download must have genuinely happened on Wi-Fi.

Then I checked a different, independent signal: [removed by Mod] in my extended streaming history**, which is the public IP that Spotify's own servers saw my connection coming from - not something the client self-reports. I looked up who owns each IP block (via ARIN's registry):

[removed by Mod]

Every session from 13:31 UTC through 18:56 UTC, the entire afternoon surrounding the download burst, used a T-Mobile-owned IP address. That includes the session at 13:57:44 UTC (right before the gap starts), 16:58:19 UTC ("Keystone," spanning the entire download burst), and both tracks at 17:55:49 UTC and 18:56:06 UTC. Before 12:38 UTC and after 21:20 UTC, sessions cleanly switch to my home ISP instead.

Here's where it gets more interesting: I was in my office for the work day, stepped out ~1-3 pm ET for an external appointment, and was back shortly after 3 pm ET. My office Wi-Fi normally works fine for my phone; this isn't a
"Guest network doesn't cover personal devices" situation. But the confirmed T-Mobile window starts at 9:31 am EDT, three and a half hours before I actually left the building, and ends at 2:56 pm EDT, matching my return almost to the minute. So this wasn't "walked outside, cell kicked in as expected", my phone, according to Spotify's logs, was on cellular for the entire office day, appointment included, and the walk outside is just a narrower, confirmed
slice of a much longer problem.

Lining that up with [removed by Mod]: the flapping [removed by Mod] sequence at 13:28-14:11 UTC (9:28-10:11 am EDT) is almost certainly my phone struggling to hold a real connection to the office AP. It settled on [removed by Mod] at 14:11:38 UTC and then, per the IP evidence, never correctly re-checked for the next 4h45m, even though the real network (per T-Mobile IP ownership) stayed cellular the entire time.

So the most likely mechanism is a stale reachability read: Spotify checked once, cached WiFii, and kept trusting it
through a multi-hour period where that was no longer true. Within that same broader window, I noticed at some point that my daylist wasn't available offline (mid-swap, needing to re-download), so I switched to a downloaded static playlist before heading out for the appointment. That's the "Comes and Goes" track, played at 17:55:49 UTC. It's genuinely a different (non-daylist) playlist, exactly as I remembered, but that track and "The Only Answer" right after it are also logged [removed by Mod] (streamed live, not from the on-device cache) while on the same T-Mobile
connection. Even my deliberate fallback to an offline-downloaded playlist ended up streaming live over cellular instead of using the cache.

Spotify's own server-side connection logs show the device was on T-Mobile cellular for the entire window, while Spotify's client-side [removed by Mod] reported [removed by Mod] continuously during that same period. That's Spotify's own data contradicting itself, not a case of me misremembering or misattributing the spike, and not a case of my office
lacking usable Wi-Fi, as it normally works fine there. The app's network type detection was wrong for about 5 hours, and both the offline sync engine (1.2 GB burst) and normal playback (2 tracks that should've used the
cache) trusted that wrong self-report instead of the network Spotify's own servers could see.

Re: Dynamic playlist download queue ignores "Download over cellular" being off when switch

Ivelina — Mon, 03 Aug 2026 11:05:18 GMT

Hey again @ericvw,

Thank you so much for providing us with all of these details! This detailed description and observation from your end will be very helpful for the investigation.

We've forwarded all of the info on to the relevant team so they can take a look, and as soon as we've got any news on the matter, we'll let you know.

We really appreciate your input here!

Don't hesitate to let us know if there's anything else we can assist you with in the meantime.

Re: Dynamic playlist download queue ignores "Download over cellular" being off when switch

Yordan — Tue, 18 Aug 2026 10:10:36 GMT

Hey, @ericvw,

A new version of Spotify (9.1.74) should be out now. Could you confirm if everything looks good on your end after updating the app?

Keep us in the loop.