Unwanted download over mobile while in car with WiFi

[aiemdavalrus]

Plan

Premium

Country

Device

Samsung S20

Operating System

Android

My Question or Issue

I think there is a bug in the application regarding downloading only over WiFi, in some particular conditions (see below).

I have enabled the setting to allow mass-downloading only over WiFi. However, one fine day, over less than one hour, I got about 300MB of MOBILE DATA activity. All I did was drive around a bit with Spotify on mobile phone IN THE CAR. A couple of regular songs (no more). That cannot add up to 300 MB.

And this is the catch. My car has wireless Android Auto. The phone connects to the car using WiFi for Android Auto functions BUT the car WiFi AP has no Internet exit. Therefore the mobile data remains connected on the phone and it is used for all traffic to Internet.

This is normal and expected. I accept that I will use mobile data for songs I play in the car (those which are not already downloaded). But the mobile app THINKS it has WiFi and starts mass-downloading even if the actual traffic goes over mobile.

Therefore, I think you should forward this message to your developers because probably they should check if WiFi is really the path used by the download or not. And adjust the app so it refrains from mass-downloading unless the route out is confirmed to be over WiFi.

Thank you,

Florin

[OscarDC]

Hey @aiemdavalrus,

Thank you for reaching out to the Community.

We can confirm that the Spotify app just checks the OS WiFi setting if it is turned on and if it can ping our servers through the WiFi connection.

However, if the WiFi is actually routed to a mobile hotspot, since the app relies on the OS to tell it if WiFi is active or not, there's no way for Spotify to know this is the case and assumes it's a regular WiFi connection.

We hope you’ll find this information useful. If anything else comes up, the Community will be here for you.

[aiemdavalrus]

Hello Oscar,

Thank you for answering.

I am an IT professional. If you do not mind, please tell me exactly how do you check this in code: "it can ping our servers through the WiFi connection". I do not say you cannot do it, but I'd like to know how you do it.

I can definitely assure you that in my case the WiFi is NOT routed through a mobile hotspot. And if it was, the 300 MB would have been associated at the PHONE level to the wireless, not to the mobile data connection.

Please note: In my particular case, the mobile is connected to a WIRELESS Android Auto implementation. That does not have access to Internet.

This means that the WiFi is active and connected but the default gateway is NOT through the WiFi because my car does not offer Internet access through the WiFi.

Also, please give me another explanation for 300 MB assigned by OS to Spotify during 30 minutes, while I played at most 5 songs overall.

I do not care THAT much for the 300 MB. But I'd like to help you or the developer team to find a possible glitch.  

Thank you,

Florin

[OscarDC]

Hey @aiemdavalrus,

Thank you for the clarification and for keeping in contact.

We're sorry about the confusion the previous message may have caused. Let us clarify the information better. What we were referring to when saying “ping our servers through the WiFi connection”  was that the application will prioritize WiFi as a connection source if it can actually access the internet through it.

For the 300MBs - it depends on your quality settings, the type of content you've played and how long it was. At high-quality, it is not unusual for a longer song to exceed 10MB. Also, the app pre-fetches related content to allow for a buffer free streaming experience, even before said content is played. In addition, other data like covers, stream counts and stats are also synced over. Hence why even when playing a couple songs, the data used can be higher than that for just those songs.

But to be on the same page, can you confirm with certainty that your WiFi connection did not have any access to the internet whatsoever?

[aiemdavalrus]

Hello @OscarDC,

(I think) I sent a reply on Sunday but I do not find it here. Maybe I did not press "Post" or something happened.

I'll write again, but only a bit later.

Thank you. 

[aiemdavalrus]

Hello @OscarDC,

Sorry for the delay. First the lost message, rebuilt from memory:

~~~

I think that at that time I had "Normal" for mobile data and "Automatic" for WiFi.

My calculation goes like this: 30 minutes of playing music in the car, even at "Very High" (320kbps) is 30*60*320/8 = 72MB. Let's take an overhead of 50% for prefetch, images, whatnot. It goes to 108MB. I saw 300 MB cellular data jump. Not quite close.

I promised then to try some more (ping, tracepath, something) while on car Android Auto, to see how/where it goes.

~~~~ (that was the gist of lost message) ~~~

Now the new info, which I think is relevant:

I did not had the time to fire up a terminal and try ping or something else, as promised.

But I did some other test. I started AA (Android Auto), then I made sure WiFi was connected to the car, then I went to Spotify App, then I clicked on "download" icon for one of my playlists which was not already clicked. A swirling "working" circle appeared instead, but it stayed like that (no download notification, no "green icon"). Looks that this scenario is properly covered and probably if I would have left it like that it would have started to download only when I got connected to a "real" WiFi.

So far so good.

BUT!

Today it happens that I left my car away from home and used another car (with no AA). 

When I got into my car again, AA connected automatically and I still had the phone in my hand. And it showed the notification for downloading!!!. Rather quickly it finished the download but I am very sure that:

1. there was NO other WiFi AP around

2. I saw for a while the "downloading" progress bar while music was already playing with the mobile connected to AA

3. My WiFi in the car does not offer me Internet access

Based on my experience, I suspect it's a race condition or a "time-of-check-to-time-of-use" bug.

Somehow, the app thinks it's on WiFi and performs the download even if it actually goes over cellular data.

I am sorry that I cannot offer a way to reliably reproduce the problem. 

However I hope these details are helpful and one hawk-eye developer will take time to look and will be able to spot the problem by carefully checking the code. 

If there is any other experiment you want me to try, I'll do my best.

BR,

Florin

[Vasil]

Hey again Florin (@aiemdavalrus),

thanks for that detailed, step-by-step recollection of the events that occurred. The app should behave like in the first scenario, where it enters a "queued" state and waits for a WiFi connection to our servers before initiating the download.

Regarding the time you saw the download notification - are you sure a download actually occurred? The notification can appear shortly when the app tries to initiate a download, but should disappear afterwards if it detects it actually can't complete it. We're guessing you didn't manage to track if any mobile data was used for that instance?

[aiemdavalrus]

Hello @Vasil

Thank you for joining and caring. 

I saw the notification bar and numbers counting (nnn/mmm). You are right; I cannot say for sure that it was actually downloading or just "running over them". The numbers were counting - that is sure. They were counting rather fast, but not significantly faster than other times I recall - (but we can have very good cellular data in some places).

Unfortunately the event was a surprise and I did not take a baseline on cellular data usage before it.  Looking at data usage "after" is useless. 

So basically I do not have anything "solid" on this particular event except for the notification.

BUT you know what? I will try to see the _carrier_ data logs at that approximate time. If I can. Maybe it will take a week or so to get them, but it's definitely possible.

OTOH: Maybe you can tell (from the code) or at least guess (from experience):

What if a download was started (on a legit WiFi) then the WiFi access is lost? How should the download behave (or rather how it _does_ behave)?

1. Will it pause (and sit waiting in the background for WiFi to reappear)? Then continue?

2. Will it abort and try fresh "from the top" as soon as a WiFi is seen again?

If it's (1), will it check _again_ the "quality" of the WiFi or it will continue blind (but using cellular)?

In my case, I can have the home WiFi strong enough until I get in the car. Then AA forces the mobile to connect to the car AP, using Bluetooth, as soon as I enter the car. If a download was in progress at that time, what would happen? Will it pause? Will it continue (erroneously) on available default route (which is cellular)?

Thank you,

Florin

[aiemdavalrus]

Hello @Vasil, again,

Luckily I got the logs from the carrier right now, without delay.

In that morning (08:08), I "scored" 168MB then another 8MB at 08:13

That was the time I got in the car, drove a while, then left the car there. By the timing it seems the timestamps are "start of session". There's no way I could have reached 168MB in that short time just by playing music at any rate.

And there's more:

At 16:04 I got another 127MB. That is the time I got back in the car, saw the notification, then I drove around for some 30 minutes (with Spotify playing). I agree, this one may or may not be proof. I cannot really say what I played and whether it was from a predownloaded playlist or not.

I also know it's global traffic and it may include other stuff but if proportion means anything, Spotify has by far the largest numbers right now (3.66GB vs Maps which is next one with 533M).

So I am inclined to take these numbers as mild confirmation that background downloads _may_ happen over cellular in some particular conditions, albeit difficult to reproduce.

Thank you,

Florin

[aiemdavalrus]

One more thing:
I checked the phone monthly cellular data for Spotify app:
cycle Nov-Dec = 165MB
cycle Dec-Jan = 352MB
cycle Jan-Feb = 4.17 GB!!!
cycle Feb-Mar = 3.66GB (and not over yet).
My usage habits did not change.
It's surely some app change which has occurred at some point in first half of January.

[aiemdavalrus]

Correction.  Second half of January.

Here I attach the overall data consumption in the first "fat" month.

The blue line is drawn by me and it's the usual data consumption (matches previous month).

The red line is also drawn by me and it matches the _current_ data consumption. Way steeper. And most of it is Spotify.

Nothing has changed in my usage habits. Did you have any new version pushed around that date where the blue gradient ends?

[Vasil · Accepted solution]

Hey Florin (@aiemdavalrus),

that's some thorough investigation there, cheers for that!

On your question, we mods aren't fully versed with the app's code and inner workings, but do know the intended behaviors of it. So in the scenario you list, of a download session starting over WiFi and then losing WiFi signal, provided "Download over cellular" is disabled, what should happen is that the download pauses. If the app is not used, after a while the Android ROM should suspend the app and put it into deep sleep. Download would then only resume if the app is actively opened over a WiFi connection. If it's opened while on mobile data, it can re-initiate the download sequence but will not complete successfully due to a failure to connect over the WiFi access point. Same will happen if the app is fully closed instead of just being in the background.

So yes, it will try and download over WiFi only. What you're saying does make some sense if it is a very fluent transfer from WiFi to mobile data, although I personally and my fellow team members do not know if this is indeed possible and if it is actually governed by the ROM itself and if the app continuously checks if the connection is currently going through the WiFi AP.

We're also not aware of any changes to the download process or how the app is using data. We also aren't able to find elevated reports about this throughout our CS channels. This is indeed quite the mystery because evidently something must've happened to cause this data spike.

Have you by any chance had any Android updates around that time period? We know Android 12 is slowly rolling out, could it be that you've received an upgrade around that time? The app is not yet optimized for the new OS and Android 12 is still in its infancy, so that could be cause of issues. This is just a personal assumption, but maybe even the WiFi detection isn't ironed out in it (or provided it is indeed handled by the Android ROM, there're some kinks there)?

If the above is not the case, have you maybe started listening to podcasts? They're much larger in data size, so that would be some sort of indicator what's happening.

For the time being, the best advice we mods can give is to disable WiFi until you're sure it can't ping our servers and enable it afterwards. In the meantime, we'll pass this on to some of our tech folks to see if they have any ideas what's going on.

Take care!

[aiemdavalrus]

Hello @Vasil and thank you,

I really appreciate your help and insight.

Yes, I am on Android 12. The version quoted by the phone for some components have "February" or '04 Feb" in it. 

Pretty consistent with the graph gradient change. Maybe you are spot on with that.

Please pass on these findings to the developer team, if you have the contacts. That's all I can hope for.

if you do so, please make sure you mention the _wireless_ Android Auto detail. It's essential, because it uses a "blind-alley" WiFi while leaving the cellular data as the default Internet communication path.

And thank you again for your help!

BR,

Florin

[aiemdavalrus]

One more question, please.

I suppose that an album, being immutable, once tagged to download and downloaded is not re-downloaded again, right?

What about playlists tagged with "download" (and I am not talking about true dynamic ones like Discover Weekly, Release Radar, Daily Mixes)? Plain thematic playlists. Once downloaded, are they re-downloaded? In what conditions?

Can I check somewhere _when_ a particular playlist was changed (because I suppose this implies at least some downloading)?

I untagged "download" from all Daily and RR and DW. I'm curious to see how my traffic evolution will look like.

[aiemdavalrus]

Small update: Today, I found both the browser and the phone app logged out and I had to reinput credentials. Is someone troubleshooting the issue? 🙂

[Jeremy]

Hi there @aiemdavalrus,

Thank you for getting back in touch with us.

We can confirm that it's been reported and that it's being looked into.

Even thematic playlists and albums can re-initiate downloads. This is because content on Spotify gets constantly reuploaded as licenses renew, when publishers submit new versions, etc. So it can be that specific tracks get reuploaded and as that is technically a new "file", it gets downloaded. Only the Content team at Spotify can look into specific upload dates / content change logs.

Let us know if you have any questions or if we can help you with anything else in the meantime.

Take care!

[aiemdavalrus]

Thank you!

[Jeremy]

Hi again @aiemdavalrus,

Thank you for your reply.

No worries 🙂
 

We're always one post away if something comes up.

Cheers!

[aiemdavalrus]

Just wanted you to know that something has apparently fixed the situation, and quite for a while now.

The download gradient is back to reasonable expectations (I waited a while, to check that, before posting).

Maybe it's something that changed in Spotify app, maybe it's some change to phone OS, maybe it's a car software update (yes, I think all three have happened for me in the meanwhile but it's difficult to tell them apart).

Anyway, I want to thank you all for your efforts if any of those have reached the heights of the dev team and have done some good.

Have a great day!

F.

[OscarDC]

Hi there @aiemdavalrus,

Thank you for keeping us in the loop.

We're glad to know that everything is up and running again. It's always a pleasure to help and we appreciate the time you took following the steps and sharing the solution.

If anything else comes up, the Community will be here for you. 

Cheers!