Email attachment download slower than snailmail

Bug Reports
1

REPRODUCIBILITY: Always
OS VERSION: 4.5.0.21
HARDWARE: XPeria 10 II
UI LANGUAGE: German
REGRESSION: Yes

DESCRIPTION

PRECONDITIONS:

gmail account, maybe a second work-related account on gmail.

STEPS TO REPRODUCE:

  • Get a free GMail inbox
  • Get a mail with an attachment
  • Try to download the attachment in the mail program

EXPECTED RESULT:

The attachment starts downloading straight away

ACTUAL RESULT:

The attachment does not download straight away, but at some point later.

ADDITIONAL INFORMATION:

Mail sync is also really slow.
While aync is in progress, its impossible to display mail previews (the mail page stays blank)

2

Can’t reproduce, 120mb attachment test is still pending ‘uploading attachments’, but the 2.9mb tar.gz of midnight commander with .jpg attached passed and download completed in couple of seconds, archive still intact. Is the attachment huge?

3

No GMail here but two commetcial, one university and one self hosted email account. No problems. Maybe this is a GMail problem?
Attachments are limited in size at GMail, I understand.

4

I used to have this problem, but don’t any more. IIRC, the change for the better was unrelated to any updates, or anything i did.

5

100KB at most.
20 chars

6

Grrr i bet its some race condition

1 Like
7

Does download work on PC, maybe it’s a ‘virus’ (like mc source code tar/gzed is detected by GOOGOL)?
Edit: your irritation is probably GOOGOL saving you from malicious open source software, you should be happy

1 Like
8

Nope no virus, happens every time with any attachment.
And on PC all ok. Come to think of it, i have also a calendar sync on a work gmail account. Could that influence (timeouts?)

9

I’ve enabled that recently so doubt it, does wifi vs mobile make a diference?

1 Like
10

Hmm good point. Ill check.
Edit: same same.
but in general, synch also takes a really long time
whats the journalctl to trace mail client activity ?

1 Like
11

One more thing: Is it a googol account or generic mail?

12

Until recently, I was experiencing the slowness described above. Even the smallest files took ages to download:
It appeared as some kind of delay before the actual download started.
I’ve just checked again and it’s gone. The download starts immediately. I used two different accounts (Google and Microsoft) and both worked fine.
I would guess that this was fixed with 4.5.0.21, but I have no real proof that this is really the cause of it.
I bet more people have noticed the same thing. Can anyone cross-check?

1 Like
13

Exactly, however for me it has remained exactly the same.

14

See the bug description :slight_smile:

15

Ok so same as here, weird

16

For me it seemed to be in sync with the problem that accounts were often erroring out when sync’ing and it was solved when I removed and re-added the mail accounts…

1 Like
17

Well ill be damned, the sync is fixed by this. Ill test the attachments soon.
Edit: attachments load properly now!
incredible; maybe some timeout that crashes the lonely thread synchronizing all accounts??
Is the relative code available/open?

18

You probably got assigned another actual server behind the load balancer or whatever setup they have. :slight_smile:

19

Could it be caused by a very large, or very fragmented, SQLite database?

Deleting an account will delete all data in the mail db for the associated account. That could make sqlite perform better again.

Maybe there’s even an explicit VACUUMing somewhere in the account deletion/creation/first sync process.

To test this theory:

  1. Have an affected account
  2. kill/stop all processes and services accessing the database
  3. Make a backup of the database using either .dump or vacuum into sqlite commands (plain file copy is not recommended but should work also)
  4. Execute vacuum; on the original database
  5. Restart all services
  6. Test whether performance improved.
20

Hmm given authentication is still valid; I have a hard time finding reasons as to why the server would be the issue…except, if the server is really slow…but from google id expect this not to happen, as it would be a wider issue, i.e. Be fixed with urgency