Open GoogleCodeExporter opened 9 years ago
This should already be working; it seems to work for me. Of course, I could be
mistaken.
Can you describe the precise sequence of events that led to think that there's
a problem?
Is your wifi signal quality always high when the problem occurs?
Original comment by Dave.Revell@gmail.com
on 27 Jan 2010 at 9:33
Same problem on HTC Desire, Android 2.1 - phome goes to sleep and connection
fails.
Original comment by pasc...@gmail.com
on 18 Apr 2010 at 3:15
there is the same problem in my HTC Desire too, screen goes off and wifi is not
working properly
Original comment by Krzyszto...@gmail.com
on 2 May 2010 at 10:28
I have HTC Desire and when the phone goes to sleep connection does not exactly
*fail*
but becomes unusably slow. Slow in like, wait 10 seconds for `ls' output, or
don't
have nerve to wait for a file transfer to begin.
Original comment by egcros...@gmail.com
on 11 May 2010 at 5:44
... I think that #48 and #57 are essentially duplicates of this
Original comment by egcros...@gmail.com
on 11 May 2010 at 5:47
I can't reproduce this on Droid or G1. Can someone post detailed (extremely
detailed)
instructions on how to reproduce it? E.g. press this button, wait for X seconds,
upload a file of size Y, fails after Z seconds
Thanks,
D
Original comment by Dave.Revell@gmail.com
on 5 Jun 2010 at 9:23
To anyone experiencing this problem: are you running any kind of power manager
app?
Original comment by Dave.Revell@gmail.com
on 6 Jun 2010 at 3:24
I do not run any power management application. I do run sipdroid which *may* do
something to keep the wifi adapter alive but in 'economy' state (don't know if
such state exists but it feels like such). When I am transferring a file, and
the screen gets blank, transfer speed drops below 100 Kb/sec. Interactive
commands start taking looong time (tens of seconds) to respond. When I unlock
the screen, transfer speed jumps to normal 2+ Mb/sec. Also tried with sipdroid
stopped and it makes no difference.
Original comment by egcros...@gmail.com
on 8 Jun 2010 at 8:54
I have seen this behavior on multiple devices too (running Eclair and Froyo).
I use FileZilla as the client application on the other side of the connection,
and once the display turns off the throughput drops from megabytes per second
rates (if RF & network conditions are good) to almost zero. No special power
management applications are running. I'll check again when I return to my home
network setup but I believe this is true regardless of the WiFi sleep policy
setting. I know that by default it is set in most devices to be "Never when
screen turns off". Will report more later.
Original comment by tfroehl...@gmail.com
on 9 Jun 2010 at 6:12
I have found an app called 'Screen On' which will keep the screen on whilst
running certain apps. Seems to be working for me, but its not as configurable
as I'd like i.e. no option for only when on power, or schedules or whatever.
I'll maybe have a look at some scheduling apps to see if they can integrate
with it.
Thought I'd mention it in case it is of use to anyone, or maybe the code it
uses can be integrated into swiftp.
I also thought I'd mention that I see this behavior on a different android FTP
server so it looks like an android issue rather than a swiftp issue.
Original comment by kevinrob...@gmail.com
on 11 Jun 2010 at 9:12
I have a beta release that I think fixes this problem, but I can't be sure
since I can't reproduce it. There is a new configuration option on the setup
screen at the bottom ("Keep phone awake") that should be turned on to fix this
bug.
Anyone who is willing, please install the 1.24 beta at
http://swiftp.googlecode.com/files/SwiFTP_1.24_beta1.apk and let us know if it
helps.
Thanks, Dave
Original comment by Dave.Revell@gmail.com
on 27 Jun 2010 at 7:17
Nope, same problem, transfers stop when phone (screen) goes to sleep. If
there's anything I can do to help please ask.
Original comment by pasc...@gmail.com
on 27 Jun 2010 at 7:31
When the phone put to sleep, speed drops as it did before the update.
Just a wild guess: maybe it's the WiFi chip that switches to low-power
low-throughput mode and causes the slowdown, not the CPU?
Original comment by egcros...@gmail.com
on 27 Jun 2010 at 12:50
ecgrosser: the fix should be that the phone never sleeps. Do you have the
checkbox checked for "keep phone awake" in the setup screen?
Thanks for testing, by the way.
Original comment by Dave.Revell@gmail.com
on 27 Jun 2010 at 4:10
I should explain a bit more. In SwiFTP 1.23 (the old version currently in the
Android Market), two locks are held whenever the server is running. The first
is a wifi lock, which should prevent the wifi from turning off or throttling.
The second lock is a PARTIAL_WAKE_LOCK, which should prevent the CPU from
turning off or throttling, but allow the screen to go off. The problem is that
these locks seem not to have the desired effect on some devices. I tentatively
claim that this is a bug in some devices (Google for PARTIAL_WAKE_LOCK
android-developers).
Since some people were able to work around the problem by forcing their device
to stay awake, I added a new configuration option in SwiFTP 1.24 that will
force the phone to remain fully awake whenever the server is running (use
FULL_WAKE_LOCK instead of PARTIAL_WAKE_LOCK). This may fix the problem, or it
may not. I still haven't been able to reproduce it on my own devices (a G1 and
a Droid).
Best,
Dave
Original comment by Dave.Revell@gmail.com
on 27 Jun 2010 at 4:22
It works as explaind above. The reason I previously said it didn't is that I
tested what happens when the screen goes off (I didn't have the patience to
wait for it to go off by itself). Swiftp does indeed now keep the phone from
sleeping and works properly. Not the best solution but it works. Thanks Dave!
BTW, I have a Desire.
Idea/request: can you implement a sleep function so that the app checks if
there are active transfers it keeps the phone alive, but if there is no
activity it will allow the phone to sleep after a preset time?
Original comment by pasc...@gmail.com
on 27 Jun 2010 at 5:42
It indeed does not go to sleep on its own accord, and that should help in many
circumstances. (But not in the case that I had in mind, i.e. automatically
recursively copy /sdcard/backup in the depth of the night.)
Original comment by egcros...@gmail.com
on 27 Jun 2010 at 6:04
Thanks for the feedback. I just pushed 1.24 to the Android Market containing
this fix (and some others).
I know it's not ideal. However, I think my options are pretty limited. If I had
a device with this behavior, I could try to figure out precisely what type of
CPU-lock shenanigans are required to make it work while saving as much power as
possible. But I don't, so my best solution is to just add the FULL_WAKE_LOCK
option and move on.
pascanu: I like your idea of allowing the phone to sleep after a while.
However, there are complications. Locks have different behavior depending on
when they are taken. If you take a FULL_WAKE_LOCK when the phone is awake, the
screen will stay on. If you then release the lock, the phone will sleep
instantly. If you take the lock again, the screen will remain off. Since the
locks are known to be buggy, I have no confidence that this will address the
problem, and no way of testing it. So that solution isn't going to work in this
case.
Original comment by Dave.Revell@gmail.com
on 27 Jun 2010 at 7:21
I would be more than willing to beta-test for you any idea. Feel free to
contact me on Gmail.
Original comment by pasc...@gmail.com
on 27 Jun 2010 at 7:24
For what it's worth, the problem seems to stem from the adapter going to
"Power-Save Polling" mode, see my comment #3 here:
http://code.google.com/p/csipsimple/issues/detail?id=71#c3
Original comment by egcros...@gmail.com
on 15 Jul 2010 at 5:13
May I suggest the following approach: when swiftp is just listening, let the
device go to sleep. When there is at least one connection, get (FULL_WAKE_LOCK
| ACQUIRE_CAUSES_WAKEUP). This should make the device fully awake even if it
was sleeping. After all connections are closed, release the lock and the device
will go back to sleep. This will allow my usecase (comment 17).
Original comment by egcros...@gmail.com
on 15 Jul 2010 at 5:37
Same problem with Acer Iconia A500. Can't really transfer large files as the
connection dies when the unit goes to sleep.
Original comment by mattias....@gmail.com
on 13 Oct 2011 at 9:11
Original issue reported on code.google.com by
anguschu...@gmail.com
on 27 Jan 2010 at 11:38