Then this is solved by 65db706e.
Contact photos are continuously degrading
@korelstar’s solution fixed the issue for me, too!
I have found out that the affected contacts remain marked as “dirty” in the android backend.
So this is working as intented – when a contact can’t be uploaded, the DIRTY flag will not be removed so that it will be tried at the next sync run again.
However, the “version” of the raw contact is continuously increasing.
I’d need logs to say whether this is working is intended. In case that OwnCloud returns a 500, but changes the ETag of the contact, it’s correct that it will be downloaded again (maybe with other photo data). However, the DIRTY flag should be removed then.
@rfc2822: Although this particular error (synchronization is not finished) origins in owncloud, one could argue, that DAVdroid should not behave in this way, i.e. the continuously degrading of quality should not happen.
Indeed. Although DAVdroid – as already mention – doesn’t touch the image data itself.
However, I have not looked in the code to find out why the degrading happens and how to prevent it. But, maybe you can use the provided information in order to harden the error treatment of your app, if possible.
Without detailled logs, it’s impossible for me to track this issue.
A detailed log can now be found under http://daten.korelstar.de/unsortiert/davdroid-owncloud.log.txt
I will delete it later.
Was this fixed in OwnCloud? I vaguely recall reading about it there a while back.
Yes, it is fixed in ownCloud by owncloud/contacts#598 (master branch) and owncloud/contacts#681 (stable7 branch). However, the fix is not included in the current stable release 7.0.2. But it should be included in the next release 7.0.3 and a future ownCloud 8.
I am also noticing this with Baikal and DavDroid. I think its Android’s contact provider that compresses images further every time a contact is updated.
I have put something on CM’s JIRA. Whether it’ll fix the issue or not I don’t know. If no-one picks it up at CM i’ll have to checkout the whole of CM and try and see if I can adjust the contact providers behaviour myself
I think this should be closed, it’s an ownCloud issue (which I also used to experience before I switched away) that allegedly has been fixed.
Oh yes, sorry. Totally forgot about it.
@tribut : I do not agree on closing this issue. Indeed, this issue is caused by a bug in owncloud. However, it is not owncloud which degrades the contact photo’s quality – it is android/davdroid! (see the above discussion: https://github.com/bitfireAT/davdroid/issues/296#issuecomment-53894868)
Due to the bug in owncloud, davdroid receives a “500 Internal Server Error” from the server. At this point, there is a misbehavior on client side: The synchronization does not complete successfully, but the image data is nevertheless updated (this is the problem). In my opinion, davdroid should handle such a case in a more better way. Otherwise, this issue will come back again, if another server software produces another “500 Internal Server Error”.
A detailed davdroid log can still be found under http://daten.korelstar.de/unsortiert/davdroid-owncloud.log.txt
The degradation is not caused by DavDroid. I experienced this issue with CalDAV-Sync too.
I also experience the same problem using the latest owncloud and DavDroid. The source of the problem has already been found?
At least I don’t have this issue with Radicale…
Joao, I think this has been fixed several ownCloud releases before. If you’re still experiencing this, could you check whether
0.) You really use the latest releases of everything
1.) Your pics are degrading with every sync or when editing a contact on your phone – the latter might be a different but similar bug, perhaps specific to your ROM?
2.) Whether switching ownCloud to Radicale fixes it
3.) Whether switching DavDroid to CardDAV Sync fixes it (AFAIK they have a free trial)
On 11 May 2015 11:18:15 CEST, “João Paulo Barraca” email@example.com wrote:
I also experience the same problem using the latest owncloud and
DavDroid. The source of the problem has already been found?
Reply to this email directly or view it on GitHub: