Back to Top

Unusably slow downloads

27 posts / 0 new
Last post
deltabgjim
Offline
Last seen: 11 years 2 months ago
Joined: 06/16/2011 - 11:05
Unusably slow downloads

I'm using version 1.2.2374 on a TMobile G2 (Android 2.2). The app is now becoming unacceptably slow at downloading podcasts. I download one from a radio show daily that is usually about 33 MB. For example, today Doggcatcher timed out for the fifth retry over the course of an hour. The Android Browser was able to download the same file from the same Url in just under two minutes using T-mobile's "4G" network. The only time I can get Doggcatcher to download this podcast successfully is when the phone is connected to my home wifi, which uses a cable modem that runs at 6Mbps. Even then, it's slow.

In fact, every download is slow, but the ones that are ~10 MB generally make it all the way to completion.

The error log shows for the first timeout:
Detail: java.net.SocketException: Connection timed out.
Cause: Unknown

Later, it shows:
Detail: com.snoggdoggler.util.PartialFileException: partial: received 4271089 of 3552276
Cause: Either the network connection dropped during a download or a pre-android 2.2 |IT is enabled (it is not supported)

Help! I once described Doggcatcher as "quite possibly the killer app for Android" but now it's worthless!

eric
Offline
Last seen: 2 years 5 months ago
Joined: 11/06/2008 - 22:02
That error essentially means

That error essentially means that android is not able to establish communication to the feed host within a given timeout which I think is a few minutes. DC (and any other android app) relies on android for network communication. If android can't establish that communication, the error will bubble up to the app as it did for you.

If you are seeing different speeds between DC and other android apps, it's possible that the feed host (or your carrier) is discriminating traffic based on the user agent. That's how DC and all other apps that use HTTP identify themselves to the server. The user agent is configurable in the DC preferences. You could edit the preference to be a typical IE or firefox user agent. Just google user agent to see what they look like.

The only other thing I can think of is that if you have AV or ad-blocker software installed, it's possible that they can interfere with connections but I don't see how the ad-blockers at least could slow down the transmission or block an existing connection.

citapinc
Offline
Last seen: 11 years 3 months ago
Joined: 06/22/2011 - 13:02
Google Listen vs Doggcatcher

I'm also experiencing very slow download speeds as well.

I just switched from Google Listen to Doggcatcher based on a podcast I heard and I'm ready to switch back to Google Listen. I'm always connected to my WiFi either here at work or at home and at both locations the download speed is at least 6mb. With Google Listen, when I download a podcast that's around 40mb in size it takes about 2 minutes and it's done. With Doggcatcher, it's been downloading the same podcast for over 2 HOURS and it's only 53% done.

UNACCEPTABLE!!!

Doggcatcher should work as good or better than Google Listen right out of the 'box' after it's initial install and I shouldn't have to do any configuration to make it so.

I'm not a tech head or a geek, just a regular user who loves to listen to podcasts. Therefore either give me instructions on what to do to make this faster, or give me an email address so I can ask for a refund.

citapinc
Offline
Last seen: 11 years 3 months ago
Joined: 06/22/2011 - 13:02
BeyondPod Podcast

I just downloaded and tried out BeyondPod Podcast just to see if this issue is wireless speed issue or not. Within 10 minutes of downloading BeyondPod and adding my three podcast URL's to the software, I had all three episodes, one from each podcast, downloaded and ready to listen. Each podcast is about 30mb in size.

So the issue is all Doggcatcher related and has nothing to do with wifi speed or anything else.

eric
Offline
Last seen: 2 years 5 months ago
Joined: 11/06/2008 - 22:02
If there's some network

If there's some network throttling going on then it's going to take some configuration to get it working. I'd be happy to issue a refund if the app isn't working for you, you can send a refund request to the address in the google market app where you purchased DoggCatcher.

I'm sorry you're having these troubles but it's pretty difficult to diagnose problems like this that only occur in certain environments without any access to that environments.

I do have an issue to make it easier to change the user-agent. I just moved it up so we can at least identify if that's the cause or not.

http://mantis.snoggdoggler.com/view.php?id=709

Thanks for posting.

citapinc
Offline
Last seen: 11 years 3 months ago
Joined: 06/22/2011 - 13:02
I think I found the source of the problem....

Eric:

I did some testing tonight and I found something interesting.

I first rebooted my phone so all I have running is your program.

I then turned WIFI off and started downloading a podcast. Yes, this is slow.

I waited until about 5% then I turned on the WIFI. It timed out but then started again but this time it was faster. I got about 50% downloaded then I turned off WIFI. At this point it stopped downloading all together and it just shows partial. If I turn the WIFI back on, nothing happens. In fact, the download queue is empty.

I think this is the source of the problem. If a podcast fails to download completely or if the phone gets rebooted in the middle of a podcast, the podcast no longer appears in the download queue and never finishes downloading.

Hope this helps.

eric
Offline
Last seen: 2 years 5 months ago
Joined: 11/06/2008 - 22:02
So a download will retry 5

So a download will retry 5 times and then it will be removed from the download queue. In the case you are describing, you are left with a partial/failed download. There's a button on the download queue screen to re-add all the failed/partials to the queue.

What really needs to happen is that the feed update should re-add the failed items to the queue, or maybe at least the partials. I added this at some point but ran into some cases where it didn't make sense to re-add on each update, so I reverted the change. It does deserve another look, I can't think of a good reason not to re-add partials on feed updates.

Maybe preferences to 're-add partials' and 're-add failed' would make sense.

I added an issue for this - http://mantis.snoggdoggler.com/view.php?id=962

Thanks for testing this out.

arnab_das
Offline
Last seen: 10 years 4 months ago
Joined: 08/06/2011 - 11:25
Facing same problem

I'm facing the same issue here. Downloads are way too slow. On the same connection however, google listen downloads are incredibly fast. Whats wrong?

eric
Offline
Last seen: 2 years 5 months ago
Joined: 11/06/2008 - 22:02
The application log in the dc

The application log in the dc menu shows the transfer rate. What rates are you seeing?

arnab_das
Offline
Last seen: 10 years 4 months ago
Joined: 08/06/2011 - 11:25
holy cow!

the log file is enormous! i searched the document for kbps and didnt find anything. i could send the file to you if you want, its just impossible to search through every single line.

eric
Offline
Last seen: 2 years 5 months ago
Joined: 11/06/2008 - 22:02
There an in app log that is

There an in app log that is more concise, in DC, press on menu, then application log. That will have details on any download that occurred since the app was started.

arnab_das
Offline
Last seen: 10 years 4 months ago
Joined: 08/06/2011 - 11:25
empty

application log is completely empty! not a word in there. i actually waited for a day of usage to pass before i posted this. no change. still empty.

eric
Offline
Last seen: 2 years 5 months ago
Joined: 11/06/2008 - 22:02
Can you try manually

Can you try manually downloading a media file and then checking the app log? The app log doesn't persist across app restarts, so it possible was cleared when the app was terminated by android.

wb8vmn
Offline
Last seen: 11 years 1 month ago
Joined: 07/08/2010 - 21:34
Slow Downloads

I have been experiencing this same issue on my T-mobile G2. I have been using DC for over 2 years. First on a G1. I've had the G2 for about 10 months. Initially, downloads were fast over HSPA+. Over the last several months it has gotten slower. Today it took 45 minutes to download a 19MB podcast (TNT 301). The whole time I had several bars and the"H" was displayed, for HSPA+. Both the up and down arrows were on solid, and the phone got very hot.
Sometimes resetting the phone helps. The first download after a reset might finish quickly. Killing DC doesnt seem to help.
I can Ustream live video so I dont think bandwith is the issue.
Download speed is excellent on wifi.
Thanks for a great app!

eric
Offline
Last seen: 2 years 5 months ago
Joined: 11/06/2008 - 22:02
Nothing has changed in DC

Nothing has changed in DC related to the downloading in a very long time. Also, DC uses the a very popular open source library for downloads that I doubt has any bugs that would seem to throttle the downloads.

My guess is that either your carrier is throttling or the publisher is throttling based on the user agent. If it's the latter, you might try changing the user agent in the preferences.

dboreham
Offline
Last seen: 10 years 8 months ago
Joined: 01/19/2012 - 09:13
Possible Diagnosis for this Syndrome

I too have been afflicted by this slowness. I switched from an iPad to a Galaxy Nexus as my primary device for watching the daily "Mad Money with Jim Cramer" show, which is available from NBC at this URL : http://podcast.cnbc.com/mmpodcast/lightninground.xml

Previously, with the iPad the download time for each episode (around 400Megs) was less than 10 minutes.
After changing to Android and DC the download time jumped to more than 30 minutes.

Like previous posters here I had always assumed some sort of throttling at the publisher, or in the
network inbetween. However this morning the slowness irritated me to the point where I decided to do
some investigation: First I tried to download the podcast using wget on a server I own in a colocation
facility that has Gigabit connectivity. The podcast downloaded at 680Mbits/s, so clearly the server
at NBC (or their CDN) is not a limiting factor. Next I tried downloading to a linux box in my house
using wget. This time the download proceeded at roughly the available network capacity (10Mbits).

So then I Google searched and found this thread.

The suggestion that throttling at the publisher may be UA-dependent was interesting, so I
ran a command on my router that allows me to see the network usage second-by-second (ifstat)
and tried downloading with DC before and after changing the UA (I changed it to "Mozilla").
Result : no difference. However, in performing this experiment I did notice something very interesting:
DC was downloading at full speed, some of the time. Some analysis of the numbers and playing around
shows that the condition that leads to the slowness is : the device is "powered down" (really
the screen is not lit, since obviously it is still powered up and running). I tried plugging the
device into a charger : this does not make a difference. The thing that matters is the screen
being on. Perhaps Android is performing some "clever" resource throttling in an attempt to
improve battery life ?

Here's an example of the results I'm seeing :

eth1
Kbps in Kbps out
1246.68 57.91
1330.18 56.18
808.54 35.19
1143.74 35.87
952.96 24.83
1889.99 42.11
2082.69 61.83
2454.63 88.59
2254.38 474.25
1068.67 94.62
713.65 61.47
654.57 42.91
1200.75 86.51
1123.64 59.44
3265.55 333.78
6400.29 354.99
6589.01 136.97
7334.95 148.95
8070.65 144.26
8519.33 160.42
9251.05 161.13
9238.46 92.38
8570.39 67.27
9998.02 198.50

Right at the point in this output (one line per second) where you see 654.57 (Kbits/s) is where I pressed the "on" button on the phone. You can see the traffic rate jump right up to 6,7,8Mbits/s.

Hope this helps in tracking down this rather annoying issue.

eric
Offline
Last seen: 2 years 5 months ago
Joined: 11/06/2008 - 22:02
Thanks for the thorough

Thanks for the thorough analysis. As I was reading, I was almost expecting the UA to be the cause. There have been some publishers that treat DC's user agent differently. That's actually why the configurable user agent was added.

I would guess that you are seeing some type of low power mode as you suggest. The problem is that this differs by device. Some devices go completely to sleep, some stay awake, and this new discovery is that some go partly to sleep.

There's a preference - "misc / prevent sleep during downloads" that was added to handle devices that go to sleep. It may also work for your situation. You probably wouldn't have to do in depth testing to find out. You could just set the pref and then do a download, and then check the application log (in the dc menu) to see the download rate.

dboreham
Offline
Last seen: 10 years 8 months ago
Joined: 01/19/2012 - 09:13
Hi, I can confirm that

Hi, I can confirm that enabling the no sleep during download option resolves the problem : downloads progress at full speed.

eric
Offline
Last seen: 2 years 5 months ago
Joined: 11/06/2008 - 22:02
Thanks for the confirmation,

Thanks for the confirmation, I think I'm going to make that preference enabled by default. I created an issue for this - http://mantis.snoggdoggler.com/view.php?id=1211

percy
Offline
Last seen: 10 years 5 months ago
Joined: 03/10/2012 - 17:43
Same problem

I am experiencing the exact same problem. Downloads are slow or even fail when the screen is off. When a download succeeds the application log shows that the bitrate was throttled down to around 128kbps or sometimes 256kbps. When I am turning on the screen the download speed goes up but not to the maximum that my DSL connection is capable of. It seems that only when using the phone online while downloading - for example browsing the web - I get the full download speed.

2 things here:
1.) I set the feed update to automatic. So the option to keep the screen on while downloading does not help because normally my screen is off when the automatic update happens.
2.) I have the impression that before one of the latest updates this problem did not happen.

I am using Doggcatcher since around 1 month on a Galaxy Nexus with ICS 4.0.2.

To test my assumption at 2.): Is there a way to download earlier versions of Doggcatcher to make a downgrade? I would like to test if these also show the download problem.

About 1.): I think there needs to be way to turn on the screen automatically when doing downloads and the options to keep the screen on is active. On the other hand, maybe there is a more elegant way to solve this? BeyondPod and Google Listen don't seem to have this problem.

Thanks for the otherwise great application!

eric
Offline
Last seen: 2 years 5 months ago
Joined: 11/06/2008 - 22:02
The 'UI / keep screen on

The 'UI / keep screen on during downloads' preference should make the screen dim during downloads even if the screen is off when the download starts. Is that not happening? If not, I can do some testing to see what's going on.

I also gave you access to download the older versions from the site here if you want to give some oldest ones a shot. Just click on the paypal user download forum.

You should make a backup (in the dc menu) prior to downgrading, and be sure not to go before version 2523. There were some database changes in that release that will break your DC if you downgrade across that boundary.

Thanks for posting.

percy
Offline
Last seen: 10 years 5 months ago
Joined: 03/10/2012 - 17:43
Hi

Yesterday I checked with 2 older versions but it didn't make any difference. So the problem already existed with the older versions but I wasn't aware of.

I am not sure if the screen turns on automatically when a download starts, have to further investigate this. But I saw that even with the screen lid the download is slower than what my connection is capable of.

I checked with the browser by downloading a large file and had the same problem. As soon as I turn off the screen the transfer rate goes down. This evening I will compare with Beyondpod and Listen to see if they really do better.

So at the moment it seems that this is a limitation of Android in general (a colleague said he has the same problem with Android 2). I even found this thread with some ideas or workarounds:

http://stackoverflow.com/questions/7617459/how-to-keep-cpu-from-sleeping...

BTW: I even tried myself to keep CPU awake with SetCPU from the market but it didn't work.

eric
Offline
Last seen: 2 years 5 months ago
Joined: 11/06/2008 - 22:02
So it sounds like this is

So it sounds like this is device specific behavior aimed at minimizing power consumption. Android uses 'wake locks' to let apps like DC try to keep the screen (and other things) on. There are different levels of wake locks, but the one dc uses during downloads is a dim wake lock. It's possible that the device still allows the itself to go into a low power mode in this case.

percy
Offline
Last seen: 10 years 5 months ago
Joined: 03/10/2012 - 17:43
Finally

Yesterday I could see the screen turn on when a download started. The transfer rate also seems to be okay. I think there is a problem with some server hosting podcasts being slow.

For a final test I downloaded one podcast several times, first checking with my desktop that this server has no speed limitations. I checked with Google Listen, PodTrapper, BeyondPod and DoggCatcher. I started the download of the episode manually and immediately locked the screen. On my desktop the complete download took 5 minutes so after 5 minutes I unlocked to phone to see how far the download went.

The result: every app but BeyondPod was throttled down to around 20% of the desktop speed.

So to close my support request:
1.) Maybe you find out what BeyondPod is doing because even with the screen looked I had the full download speed. I checked this twice. What about experimenting with different wake locks?
2.) After having seen several other podcast apps I can tell you that for my taste DoggCatcher has a superior UI.

Thanks so far!

eric
Offline
Last seen: 2 years 5 months ago
Joined: 11/06/2008 - 22:02
Those are interesting

Those are interesting results.

I don't really have the ability to test the effect of the alternate wake lock because I see the same download speeds on all the devices I regardless of the type of lock.

I am going to be upgrading the library that does the downloading to a newer version in the third release from now (the next two have already been released to beta testing). There's a chance that this may have an effect if it's something not wake lock related. I would be surprised if a different wake lock would make a difference if beyondpod keeps the screen dim or off...the same as DC.

Let's check this out after I upgrade the download library, or actually you can join the beta group if you want to test it out. Just let me know if you are interested.

Thanks for doing all the testing.

percy
Offline
Last seen: 10 years 5 months ago
Joined: 03/10/2012 - 17:43
Beta

Yup, a bit of beta testing would be fine.

Is there a way to get notified of replies to my own postings so I don't have so scan the forum for answers to my posts?

Another thing: What about localization? I would be glad to help out with translating the app. Don't know how this is on Android but I know from my own Linux development that you could extract all strings into a file and a translator could add the translations into this file and send it back to the developer.

eric
Offline
Last seen: 2 years 5 months ago
Joined: 11/06/2008 - 22:02
I just set you up for the

I just set you up for the beta, you'll get an email in a couple mins with details.

For notifications, just click on my account (down at the bottom of this page) and then subscriptions. You can set up your preferences for how you'd like to get notified.

Localization - that's on the todo list. I'm pretty sure android handles this, it's just a matter of putting tokens all through the app and coming up with the dictionaries for different language.

Thanks for posting and helping out with the beta.