BeyondPod is streaming downloaded podcasts

[Silex]

While I am an avid user of Google reader, I don't use it for any podcast feeds and I don't use any of the Google reader sync features that are a part of BeyondPod. Basically, the data logging app shows every app and process on my phone using less than 200kb of data a day other than USB tethering and BeyondPod. BeyondPod uses anywhere between 30mb - 100mb per day and I play podcasts pretty much the entire 8 hour period that i work each day. I think we should let this rest until I hear back from the other developer. I would hate to learn that I have wasted your time only to find out that the data logging app is the culprit.

[JNavas]

In the meantime, you might want to try a different app data monitor and compare the results.
Onavo Count | Monitor Data is very well-regarded.

[paulroberts]

I just checked this in the data usage screen on ICS, BP has used 50.6MB of mobile data in a month and BP is by far the #1 user of mobile data.





in ICS you can set limits and warnings for mobile data and also block access to mobile data on an app by app basis.

[JNavas]

BP (3.0.19) isn't rigorous about the type of connection. Here's a test where I

• Turned off Mobile Data in Android (4.0.4) with no Wi-Fi connection
• Turned off Mobile Data in BP
• Opened a feed, swiped up and then down, triggering a Refresh
• BP tries Refresh even though there is no data connection
• Refresh eventually times out with a connection error

My issues with this scenario:

1. BP shouldn't try connecting when no data connection.
2. BP shouldn't try connecting when Wi-Fi not connected and Mobile Data unchecked.
3. Triggering refresh unintentionally is all too easy when swiping up and down.

I especially don't like issue #3. The refresh icon is sufficient.
I'd at least like a way to turn off this behavior.

[paulroberts]

I'd also add that my data use ould mainly be just on my commute to work as i connect to wifi at home and at work

[StefanK]

BP shouldn't try connecting when no data connection.
BP shouldn't try connecting when Wi-Fi not connected and Mobile Data unchecked.

In ideal world that certainly would be the case. The problem is that versions of Android and device implementations vary on how they handle and report those conditions. In many cases the device will report that it does not have a connection until you actually try to connect, so you can't just blindly trust that there is no connection. Even more many WiFi modems are actually wired in a such way that they need the screen to be On in order to connect, so not only you have to wait but also turn the screen on in order for everything to work. All those qurks in how devices manage and report their connections require a complex, difficult to debug and test logic. What we currently have is a compromise that we (empirically) found to work for most cases (even if it sometimes is not optimal).
In the particular case you describe, the delay is actually not connecting, but waiting to see if WiFi may connect at some point. (If I remember correctly, in the past there were some early tablets where it you could not reliably tell if WiFi is permanently off or it was in power saving mode and may connect at some point, so the safest thing was to do is to wait for a while).

Triggering refresh unintentionally is all too easy when swiping up and down.

I agree "pull to refresh" does make it easier to do unnecessary refresh if you are not careful. I am not sure how big of an issue is this, but it is easy to turn it of if this turns out to be a problem.
Does anyone else have issues with unintentionally triggering feed update using pull-to-refresh ?

[JNavas]

In ideal world that certainly would be the case. The problem is that versions of Android and device implementations vary on how they handle and report those conditions. In many cases the device will report that it does not have a connection until you actually try to connect, so you can't just blindly trust that there is no connection. Even more many WiFi modems are actually wired in a such way that they need the screen to be On in order to connect, so not only you have to wait but also turn the screen on in order for everything to work. All those qurks in how devices manage and report their connections require a complex, difficult to debug and test logic. What we currently have is a compromise that we (empirically) found to work for most cases (even if it sometimes is not optimal).
In the particular case you describe, the delay is actually not connecting, but waiting to see if WiFi may connect at some point. (If I remember correctly, in the past there were some early tablets where it you could not reliably tell if WiFi is permanently off or it was in power saving mode and may connect at some point, so the safest thing was to do is to wait for a while).

With respect, I'm testing with a reference device (Nexus S), which shouldn't be compromised to a lowest common denominator without any means of control (e.g., advanced option to enable sloppy connections).

I agree "pull to refresh" does make it easier to do unnecessary refresh if you are not careful. I am not sure how big of an issue is this, but it is easy to turn it of if this turns out to be a problem.
Does anyone else have issues with unintentionally triggering feed update using pull-to-refresh ?

With respect, the problem with the current implementation isn't that it's "easier to do unnecessary refresh", it's that it's difficult to avoid an unnecessary refresh when using rapid ballistic scrolling, which runs contrary to the Android UI paradigm. To avoid the issue I have to wait until ballistic scrolling stops before another swipe or pause at the end of every swipe. And it's unnecessary, since there's a refresh control in the header.

[StefanK]

With respect, I'm testing with a reference device (Nexus S), which shouldn't be compromised to a lowest common denominator without any means of control (e.g., advanced option to enable sloppy connections).

You can't imagine how I wish that all (more, larger portion, or at least significant portion) of users used "reference" devices. As you know 90% of the users use "non reference" devices and those are the devices we have to make it work (as automatic as possible).

it's that it's difficult to avoid an unnecessary refresh when using rapid ballistic scrolling,

Agreed.

[DHK1001]

I would like to second the problem that Silex is having. I was also surprised to see how much data I had used last month. I installed Onavo to track it. I never use wifi. I download anything I will listen to. I am careful to make sure I have downloaded podcasts rather than stream them.

I think there is more to it than just BP doing an extra data download. I haven't tried experimenting with the problem much. But the first time I used the tracking program, last Wednesday, it indicated I had downloaded 370mb on "Streaming Media". This happened while I was in the car listening to 40 minutes worth of podcast. Even if it was streaming the episode I had downloaded, that episode was nowhere near 370mb. I was using Google Navigator at the same time, so maybe there was some overlap in usage that I don't understand. But even so, I can't imagine either of them using that much data over 40 minutes. Onavo tracks Beyondpod downloading separately from the Streaming Media. It says that I've done 400mb of Streaming vs 165 of BP.

I've tried a couple of times to replicate the streaming and haven't had any success.

Thanks!

[Silex]

I have determined that this data usage was a false positive given off by "My data manager" The developer says there is a known bug they are trying to fix that mistakenly logs wifi tethering data usage as other apps using that data. I don't tether via wifi. I tether over usb cable. The developer suggested downloading a free firewall app. I blocked BeyondPod with the firewall app and BeyondPod no longer logged any data usage.

I still was not convinced that BeyondPod was the culprit so I did as JNavas suggested and downloaded Onavo. I used to use Onvao but dropped it for "My data manager" for 2 reasons. It does not break down the logging so that you can see usage for the current day (only cumulative for the month). It also lumps all data not used by installed apps into one item labeled system. There is no way to see your tether usage this way. After a week of using Both logging apps (with firewall off) The former logged hundreds of MBs of data for BeyondPod and the later logged none. This usage appears to only accumulate when I tether so I have determined that this wifi tether bug also resides in usb tethering.

Thanks for all of your help with this. I will say I have found that I have accidentally streamed more podcasts than I ever realized before doing all of this research. I notice that sometimes when I go to delete or play a certain podcast it will actually do that action to a different one than you press. This causes me to stream a podcast that I thought was downloaded. Right after you press on a podcast it moves to a different one and does the action to that instead. I once hit play on a video podcast and found a few minutes later I was streaming it and it had downloaded 275 MB in that short time. I get a warning when I try to download or update a feed warning me that the action uses mobile data. I find it disappointing that I can't configure the app to get this same warning when I try to stream a podcast. Please consider adding this feature.