audiobookshelf-app
audiobookshelf-app copied to clipboard
advplyr
Local playback generating a huge mobile data usage
Steps to reproduce
- Download a Audiobook
- Keep the audiobook playing for a few hours
Expected behaviour
- With local downloaded audiobooks there should only be minimal bandwith usage. The bandwith should not be much higher than the actual local file size of the audiobook
Actual behaviour
- After playback and long usage the app generates huges amount of traffic (>2GB) even though its only playing a single previous downloaded audiobook
Environment data
Audiobookshelf Version: 0.9.46-beta
- [ X ] Android App?
- [ ] iOS App?
Android Issue
On newest Samsung and Lineage OS
😳 Just played downloaded books
I think this is happening to me, too. I never stream books while I am driving; I always download them over wifi first. But my mobile data usage is about 200mb over the past three days, which is basically what it would be if I streamed everything I listened to over that period. A definite fix (e.g. a "Never stream via mobile data" setting) is urgently needed.
EDIT: Also, I would just like to thank @chonki for reporting this issue. If I hadn't seen this bug report coincidentally, I probably would have learned of this problem about a week from now, after burning through all my mobile data for the month.
EDIT 2: I can confirm that this is happening to me as well.
My assumption is that the download feature was intended to allow a user to download their content from their server remotely to play in another player and was not initially built with the intent of local playback through the app. I could be wrong, but it appears to be the case.
An update on this: I installed a network-traffic monitoring app on my phone, and it appears that the excessive traffic is upload.
I have no idea how this could be happening. It is not happening predictably—playing local audiobooks uploads about 0.01 MB per minute (which is totally fine), but somehow during about the half hour I was driving today, it uploaded dozens of MB. I am trying to chase down when this is happening so I can see if it is associated with any particular log entries, but I'm having no luck so far.
Update: Nothing in particular seems to cause the high upload usage (e.g. skipping around in the book, switching books, playing/pausing), and the uploads are inconsistently sized. In the time I've been trying to pin this down, there was a ~10MB, a ~4MB, and a ~1MB upload.
EDIT: Thought I had identified a partial cause, but couldn't replicate that cause—I think it was just coincidence.
When connected to your server a downloaded book will still play the local file.
I've been monitoring the usage while using the app and not noticing anything unusual so far.
I spent yesterday evening testing this and monitoring data usage for downloaded audiobooks and podcast episodes.
I found that the the media is being played locally and not streamed. I believe the high data usage is coming from the web socket connection receiving every update/log from the server. Even if you are doing nothing else but listening to the downloaded book over several hours this can add up.
I've already reduced the amount of traffic the clients receive from the web socket connection considerably but I'm also considering having the web socket connection be disabled when not on wifi. This would just mean that any updates happening on the server outside of what you are doing in the mobile app will not be received. For instance if you were listening on the web browser you wouldn't receive those progress updates on the phone unless you were on a wifi network (or re-opened the app).
Alternatively I might be releasing the update with a setting to opt-out of the web socket connection when not on wifi.
Every 5 seconds the mobile app is sending an update to the server with the progress. This is considered "upload" data and should be minimal, but we could also increase the time between those requests when not on wifi. For instance we could send an update to the server every 30 seconds when not on wifi. I'm not sure if the upload data usage was a concern though.
Thanks for catching this and helping to test.
Alternatively I might be releasing the update with a setting to opt-out of the web socket connection when not on wifi.
I think this is a great idea! Maybe with some additional info in a tooltip or description section somewhere around it!
Let me know when you want some testing done! I'd be happy to help out!
Every 5 seconds the mobile app is sending an update to the server with the progress. This is considered "upload" data and should be minimal, but we could also increase the time between those requests when not on wifi. For instance we could send an update to the server every 30 seconds when not on wifi. I'm not sure if the upload data usage was a concern though.
At least for me, the unexpected data usage was entirely upload. And ordinarily, each "tick" sent on the websocket connection is barely a kB upload, which is not problematic at all, but there were sudden bursts of 5–15 MB. But I have not been able to reproduce today, so I'm optimistic that an unrelated update somehow fixed this issue.
I made some updates that may help with the data usage. Please update to 0.9.52-beta mobile app and 2.0.24 server version and let me know if you are still seeing high usage.
Thanks @advplyr for spending time on the issue.
I patched to the versions you mention, but I still have the same problem. Around 25 min listening generated 55MB tx traffic over mobile data (listening to a downloaded book).
I can confirm the app now detects if I'm on wifi or mobile data
@Kybeer Is that 55MB of upload or download?
@advplyr It's upload, i.e. transmit from the phone.
I did another listen now. About 35min, 80MB upload
An update was made in v0.9.54-beta to help address the data usage issue.
First the app is going to detect whether you are on a metered connection. Metered vs unmetered connections are more accurate to what we want as compared to wifi vs cellular data because you could be on an unlimited data plan over cellular or a metered wifi connection.
I have been notified that a metered wifi connection may not detect properly, but my device has properly detected metered cellular connections. You will see the connection icon at the top turn yellow if it is metered, and you can click it to see the full description.
If you are on a metered connection then progress is going to sync with the server every 60s or anytime you pause the media. For regular unmetered connections the progress syncs every 5s.
With this I expect the data usage to be 5 to 10x less for regular use.
Let me know!
Why not just sync when media is paused on any connection? What is the purpose of the constant syncing? I'm never going to switch to another device while still playing audio.
It could be longer than 60s but I think it should sync after some time and not just when you pause. If you listen for 6 hours straight then your server goes offline, then you hit pause it fails to sync, then your server boots up again you see the progress hasn't updated and you open an issue on github saying the progress sync is broken.
Maybe have it be a user configurable time period for period sync, and pause only sync as an option. Manual sync could be an option as well for the offline server problem. Manually push a sync if the server lost track, but the client still has the right position.
I use Moon+ Reader for epubs. It syncs when the app loses focus (when you switch to another app), similar to pausing audio in my mind. And supports manual push/pull of reading position from the cloud.
I tried today with Android app 0.9.54-beta and server 2.0.24
It seems to be working now :) 25 min playback over 4G+VPN caused just 3MB of data usage.
The latest server release will also reduce the download size. This should be fairly minimal now