android
android copied to clipboard
owncloud
[BUG] Image autoupload uploads images twice under certain conditions
Actual behaviour
When image autoupload is turned on, images are uploaded twice, the second time with (2) at the end of the file name.
Expected behaviour
Images get uploaded only once.
Steps to reproduce
It usually happens when both image and video autoupload is turned on, however for example right now I only have image autoupload turned on and it still happens. Also yesterday, I took two images, one was uploaded once and the second one got uploaded twice. Fiddling with enabling/disabling image and/or video autoupload sometimes fixes the issue.
Can this problem be reproduced with the official owncloud server? not when I tried it now
Environment data
Android version: 12
Device model: Xiaomi Poco F3
Stock or customized system: Custom ROM (Pixel Experience 12)
ownCloud app version: 4.0-beta1 (but I have the problem with the latest stable version as well)
ownCloud server version: 10.11
Logs
ownCloud log (data/owncloud.log)
Hi @Dehumanizer77! Thanks for opening a new issue for this! We'll take a look and let you know about our findings 😉
I have had this for several months now, it basically happens every time. The difference being for me I often get (2), (3) and several more versions of the same file. The original is sometimes, but not always zero sized. I am happy to provide further info if this helps.
It's totally unreliable, sometimes it uploads the file fine, sometimes with zero size, sometimes multiple times, sometimes just once...
Hi. Same for me. I did not notice zero size on the original file. I get even (3), (4), (5) sometimes. Usually I just delete such files and the original ones seem to be OK. It happens for quite a while already - half a year for sure and survived a few app upgrades. Just upgraded to the most recent version recently. I have Samsung S10e.
Actually, I upgraded to v3.0.4, and first time in a while did not have these dupes today. Let's see..
Since 4.0 beta does have the problem as well, I would be surprised if it was fixed in 3.0.4, but maybe some accidental change fixed it, let us know if the problem didn't reappear later.
So far only one file got a dupe since I upgraded to 3.0.4. This version is definitely better than whatever 2.x I had before.
I'm on 3.0.4 and still getting the same issues. Multiple dupes, sometimes zero sized, along with sometimes originals zero sized also. This is the most worrying for me as it means that images are not in fact being synced but the OwnCloud app thinks they have been. Until later when I go to import them for processing and find that the images are empty/broken and have to see if I've still got the originals on my phone.
I have a similar issue where one image is uploaded to the /CameraUploads folder and the same image is uploaded to the /Camera/Igor folder.
That second folder is actually the one I configured in the ownCloud android client Settings and that is the folder I would expect to get uploaded files
I can't get rid of the original /CameraUpload folder
The original problem seems to be fixed now, at least with 4.0-beta4 I didn't notice duplicate files anymore.
The original problem seems to be fixed now, at least with 4.0-beta4 I didn't notice duplicate files anymore.
Cool, installed, let's see!
I installed the latest 4.0 beta version, but this bug still exists
Good thing is that it seems that other issue (uploading files to the default /CameraUpload and custom folder set in the settings) is being fixed
This is a known issue right now, no specific fix for it in the 4.0 version of the app. We'll check it ASAP and will keep you updated in this thread 🚀
FWIW this is still happening in version 4.1.1, only some files and usually only one extra copy
I moved to Nextcloud, and don't have this issue anytime
On Tue, 24 Oct 2023, 02:36 Jeff Siddall, @.***> wrote:
FWIW this is still happening in version 4.1.1, only some files and usually only one extra copy
— Reply to this email directly, view it on GitHub https://github.com/owncloud/android/issues/3983#issuecomment-1775980087, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATBZIJSL5OJYFJP2PUBCT2LYA3IN5AVCNFSM6AAAAAAWDUUNWSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZVHE4DAMBYG4 . You are receiving this because you commented.Message ID: @.***>
Almost same issue observed with latest version (4.1.1) and with OCIS backend. Some detailed logs (android app) available: https://github.com/owncloud/ocis/issues/8239
I observed 2 slightly different outcomes:
- one file on OCIS, but corrupted
- two file on OCIS, the first one is partially uploaded (0 < size < real size) and the second one is OK, but with (1) in the name.
I updated to the latest Android client 4.2.2 a couple of days back and today opened up the app for the first time since the upgrade. After a while it auto-uploaded all the new photos exactly twice. No errors or failures in any of the uploaded files. This seems to be happening on the client because in the upload list I noticed it uploaded the photos, in date order, once and then immediately uploaded them again in the exact same order. Somehow it seems to be detecting new photos twice.
Android client recently updated to 4.3.1. This time I got exactly triplicates of every file!
I happened to see the client uploading and got a screenshot of the client simultaneously uploading the same file twice so the duplicates are being initiated by the client for sure. I don't know how to upload screenshots from Android but if it would be helpful I can figure it out.
I did not get any duplicates or triplicates with 4.3.1 so far... But I'll keep an eye on that for a few days or a week if I just have been lucky.
Yeah, I should have been more clear: I don't think 4.3.1 in itself is the cause of the triplicates. Just that whatever bug is causing it is still around in 4.3.1.
It is definitely somewhere in the code that finds new images. I don't know about other people's experience, but my client goes dormant after some time and doesn't upload new images until I open it again. Then, some minutes after re-opening, it uploads all the new images, and sometimes more than once.
Guessing that Android is preventing it from running in the background for some reason, but I am not sure how to fix that, or whether it would even prevent this issue.
Hi everyone! 👋
Just as an update: no, we have not been working on this lately, so the bug must be somewhere yet... 😿 We know this is so ugly, but we have a problem and it's that we are not able to reproduce this bug consistently. This happens arbitrarily, only some times and only with some files, so, it's also difficult for us to locate the error somehow. You know logs are welcome (if you get them just ask and we'll provide a secure way of uploading them so that only us are able to see them), or if you find out a way to reproduce it consistently, it would be very useful as well.
I don't know about other people's experience, but my client goes dormant after some time and doesn't upload new images until I open it again. Then, some minutes after re-opening, it uploads all the new images, and sometimes more than once.
Guessing that Android is preventing it from running in the background for some reason, but I am not sure how to fix that, or whether it would even prevent this issue.
About this, as you say, it is likely provoked by the Android Operating System. Android tries to save energy by killing, revoking permissions or even "deactivating" apps that have not been used for a long time (time decided by Android internally, not by apps developers). So, to help here, I would advice you to check your battery saving settings, but if everything looks OK there, just try to open the app more oftenly (once per week should be enough I guess...).
We'll keep updating here in any case, thanks for your patience and help 👍
After I switched to Nextcloudpi, zero issues with duplicates and overall much better experience :)
Hi @vvzinovyev! Glad to hear that! But this issue is aimed to discuss about the bug in the ownCloud Android app, and you already commented the same some messages above, so please, don't spam the GitHub tickets. Thanks for your collaboration 😃
Oops, sorry, did not see I'm repeating. Unsubscribing from this conversation )
After I switched to Nextcloudpi, zero issues with duplicates and overall much better experience :)
Interesting. Since the client seems to be the thing doing the duplication it is surprising that it would work differently on NextCloud.
Hi everyone! 👋
Just as an update: no, we have not been working on this lately, so the bug must be somewhere yet... 😿 We know this is so ugly, but we have a problem and it's that we are not able to reproduce this bug consistently. This happens arbitrarily, only some times and only with some files, so, it's also difficult for us to locate the error somehow. You know logs are welcome (if you get them just ask and we'll provide a secure way of uploading them so that only us are able to see them), or if you find out a way to reproduce it consistently, it would be very useful as well.
I don't know about other people's experience, but my client goes dormant after some time and doesn't upload new images until I open it again. Then, some minutes after re-opening, it uploads all the new images, and sometimes more than once. Guessing that Android is preventing it from running in the background for some reason, but I am not sure how to fix that, or whether it would even prevent this issue.
About this, as you say, it is likely provoked by the Android Operating System. Android tries to save energy by killing, revoking permissions or even "deactivating" apps that have not been used for a long time (time decided by Android internally, not by apps developers). So, to help here, I would advice you to check your battery saving settings, but if everything looks OK there, just try to open the app more oftenly (once per week should be enough I guess...).
We'll keep updating here in any case, thanks for your patience and help 👍
Ah, yeah, I think I have the Android power saving mode enabled. Maybe that is making this occur more often for me than others. Still, I don't get duplicates every time so there is an element of unpredictability to it.
I do have logging enabled. There are lots of files. Am I looking for one that has the next more recent date after the problem occurred? The last issue occurred 2024-07-28 about 11:47 PM local time. There is a large log file (3M) dated 2024-07-28_22.54.00 which is earlier than the problem. The next log is dated 2024-07-29 and it is tiny (1K).
Please let me know about which files and where I can provide those.
I do have logging enabled. There are lots of files. Am I looking for one that has the next more recent date after the problem occurred? The last issue occurred 2024-07-28 about 11:47 PM local time. There is a large log file (3M) dated 2024-07-28_22.54.00 which is earlier than the problem. The next log is dated 2024-07-29 and it is tiny (1K).
Please let me know about which files and where I can provide those.
It's important that the Log HTTP requests and responses is also enabled. I'll will give you some context about how the feature works, so that, it's easier to understand what's going on:
When pictures/videos auto-uploads are enabled, a background process runs every fifteen minutes (time slot is internally decided by the Android operating system), saving the latest execution timestamp after every run. The background process checks the camera roll to find pictures/videos which capture timestamp is newer than its own latest execution. Then, it sends those pictures/videos to the uploads queue, and finally updates the execution time as reference for the next run.
If you have duplications, it means that the background process is enqueuing pictures/videos that were already enqueued in previous runs. I have some guesses, then:
- The latest execution timestamp is not being correctly updated. Iin that case, it'd be easier to reproduce, it'd be a bug in the logic.
- The pictures/videos' capture date is stored somehow wrongly, leading the background process to kind of confusion when fetching the items to enqueue. Every vendor or camera app running over any OS variant might cause this... but nothing to assure at the moment.
I hope that it helps to understand. We agree that this is an ugly bug, you are totally right. But, as @JuancaG05 stated, we can not fix it without reproducing it correctly.
If you are kind to fetch some logs including the repeated uploads' scenario, you can push them to this link:
https://infinite.owncloud.com/s/IcWNuXBUbQwMUti Pwd: aa55AA..
Any other further idea or suggestion from anyone is also welcome!
How is the upload-mechnism handling network connection problems when a picture is in the upload-queue?
For myself, I experience this problem more often when I am hiking and taking pictures. In the mountains I do not always have a (stable) data connection but the queueing should still take place. Is it maybe requeuing a failed upload and therefore uploading multiple queued files when it's online again?
I can't remember a duplicate when I am home and have a stable WiFi connection, but I will pay more attention to these scenarios going forward.
Just as another input and this scenario should somehow be reproducible.
How is the upload-mechnism handling network connection problems when a picture is in the upload-queue?
this should not have nothing to do, but i'll explain a little bit: we handle different statuses for a transfer: enqueued, current, uploaded and failed. A new upload is enqueued, then goes to current (ongoing) and finally uploaded. If something wrong happens, it goes to failed. Here, we have two different scenarios: failed because a lack of connection or connection problems, and other failures (f. ex. server down). In case of failure because lack of connection, failed uploads are automatically retried when connection is back, otherwise they must be retried manually (retry button available) when the blocking issue is fixed.
I said it does not has to do, because the background process that i described above just sends the new pictures/videos to the queue. Transfer's handling it is not its responsibility, that's other process.
Anyway, i will get your idea. Maybe @Aitorbp can check in the code whether the execution date is always updated with no restrictions, after every process runs (it should but sometimes bugs happen).