Autoupload doesn't (autoupload)

[InfamousUser]

Steps to reproduce

1. Install fresh Nextcloud app on Android
2. Add one or two autoupload folders (custom) with the following: only "also upload existing files" checked, original file kept in original folder, if file exists -> rename new version.
3. Make sure it is turned on.
4. Wait

Expected behaviour

App should automatically upload the selected data.

Actual behaviour

App does not automatically upload the selected data, manual upload, on the other hand, works. Upload menu is empty, nothing is attempting to be uploaded. I do get notifications about other media folders being detected, but no feedback regarding the selected autoupload.

Can you reproduce this problem on https://try.nextcloud.com?

• Please create a test demo account and see if this still happens there.
• If yes, please open up a bug report
• If not, please verify server setup and ask for help on forum

Environment data

Android version: 14

Device model: Google Pixel 7 Pro

Stock or customized system: stock

Nextcloud app version: 3.27.0

Nextcloud server version: 28.0.2

Reverse proxy:

Logs

Web server error log

Insert your webserver log here

Nextcloud log (data/nextcloud.log)

Insert your Nextcloud log here

NOTE: Be super sure to remove sensitive data like passwords, note that everybody can look here! You can use the Issue Template application to prefill some of the required information: https://apps.nextcloud.com/apps/issuetemplate

[talesam]

I'm having the same problem autoupload doesn't work, it doesn't send images to the server.

[InfamousUser]

Well that's a fail, I hope they give this autoupload a revamp soon, it's riddled with bugs.

[tobiasKaminsky]

Maybe this is Android 11 related?
@talesam @madboykiller do you also have 11?

[talesam]

I'm using the DEV version and the auto-ship works and the app doesn't eat all the battery on the phone.

[talesam]

Maybe this is Android 11 related?
@talesam @madboykiller do you also have 11?

Android 10

[WarmChocolateCake]

Adding some "me too" information...

I'm on Android 10, with NC Client version 3.15.1, connected to NC Server 20.0.7 (running on a Raspberry Pi 4).
Autoupload is only set to monitor the "DCIM" folder on an "external" microSD card
I have 2x autoload entries - one for photos, the other for videos - both are pointing to the same "DCIM" folder
Autoupload is set to only upload with unmetered wifi, existing files, and use subfolders.

(I'm also using DAVx5 to sync CardDAV & CalDAV from the same phone to the same server)

The Autoupload appears to work for a while, then "jams" and doesn't appear to upload any more photos.
However, sometimes it will upload some recent photos but miss earlier ones.
Rebooting the phone then appears to reset something and Autoupload will then catch up with all the missing photos.

Often (everytime?) when I've rebooted the phone, after it has synchronised. I'll get a "file upload conflict" and it's a photo that appears to have correctly uploaded. So it appears that autoupload sends something to the server, but maybe doesn't cleanly complete the transfer and then that holds up the rest silently?

Using the filename of the photo that was conflicting today, I see the following in NC Server /data/nextcloud.log:

{"reqId":"UXvjRnmWRSJyf0kkD3yd","level":1,"time":"2021-05-06T21:16:51+01:00","remoteAddr":"192.168.6.24","user":"steve","app":"no app in context","method":"HEAD","url":"/remote.php/webdav/Photos/2021/05/20210506_205020.jpg","message":"Deprecated event type for {\"[object] (OCP\\SabrePluginEvent)\":{\"*statusCode\":200,\"*message\":\"\",\"*server\":{\"[object] (OCA\\DAV\\Connector\\Sabre\\Server)\":{\"tree\":\"[object] (OCA\\DAV\\Connector\\Sabre\\ObjectTree)\",\"*baseUri\":\"/remote.php/webdav/\",\"httpResponse\":\"[object] (Sabre\\HTTP\\Response)\",\"httpRequest\":\"[object] (Sabre\\HTTP\\Request)\",\"sapi\":\"[object] (Sabre\\HTTP\\Sapi)\",\"*plugins\":[],\"transactionType\":null,\"protectedProperties\":{\"...\":\"Over 20 items, aborting normalization\"},\"debugExceptions\":false,\"resourceTypeMapping\":[],\"enablePropfindDepthInfinity\":true,\"xml\":\"[object] (Sabre\\DAV\\Xml\\Service)\",\"*listeners\":{\"...\":\"Over 20 items, aborting normalization\"},\"*wildcardListeners\":[],\"*listenerIndex\":[],\"*logger\":null}},\"Symfony\\Contracts\\EventDispatcher\\EventpropagationStopped\":false}}: null","userAgent":"Mozilla/5.0 (Android) Nextcloud-android/3.15.1","version":"20.0.7.1"} {"reqId":"UXvjRnmWRSJyf0kkD3yd","level":1,"time":"2021-05-06T21:16:51+01:00","remoteAddr":"192.168.6.24","user":"steve","app":"no app in context","method":"HEAD","url":"/remote.php/webdav/Photos/2021/05/20210506_205020.jpg","message":"Deprecated event type for {\"[object] (OCP\\SabrePluginEvent)\":{\"*statusCode\":200,\"*message\":\"\",\"*server\":{\"[object] (OCA\\DAV\\Connector\\Sabre\\Server)\":{\"tree\":\"[object] (OCA\\DAV\\Connector\\Sabre\\ObjectTree)\",\"*baseUri\":\"/remote.php/webdav/\",\"httpResponse\":\"[object] (Sabre\\HTTP\\Response)\",\"httpRequest\":\"[object] (Sabre\\HTTP\\Request)\",\"sapi\":\"[object] (Sabre\\HTTP\\Sapi)\",\"*plugins\":{\"...\":\"Over 20 items, aborting normalization\"},\"transactionType\":\"head\",\"protectedProperties\":{\"...\":\"Over 20 items, aborting normalization\"},\"debugExceptions\":false,\"resourceTypeMapping\":[],\"enablePropfindDepthInfinity\":true,\"xml\":\"[object] (Sabre\\DAV\\Xml\\Service)\",\"*listeners\":{\"...\":\"Over 20 items, aborting normalization\"},\"*wildcardListeners\":[],\"*listenerIndex\":[],\"*logger\":null}},\"Symfony\\Contracts\\EventDispatcher\\EventpropagationStopped\":false}}: null","userAgent":"Mozilla/5.0 (Android) Nextcloud-android/3.15.1","version":"20.0.7.1"} {"reqId":"UXvjRnmWRSJyf0kkD3yd","level":0,"time":"2021-05-06T21:16:51+01:00","remoteAddr":"192.168.6.24","user":"steve","app":"webdav","method":"HEAD","url":"/remote.php/webdav/Photos/2021/05/20210506_205020.jpg","message":{"Exception":"Sabre\\DAV\\Exception\\NotFound","Message":"File with name Photos/2021/05/20210506_205020.jpg could not be located","Code":0,"Trace":[{"file":"/usr/share/webapps/nextcloud/3rdparty/sabre/dav/lib/DAV/CorePlugin.php","line":81,"function":"getNodeForPath","class":"OCA\\DAV\\Connector\\Sabre\\ObjectTree","type":"->"},{"file":"/usr/share/webapps/nextcloud/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"httpGet","class":"Sabre\\DAV\\CorePlugin","type":"->"},{"file":"/usr/share/webapps/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php","line":474,"function":"emit","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/usr/share/webapps/nextcloud/3rdparty/sabre/dav/lib/DAV/CorePlugin.php","line":262,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/usr/share/webapps/nextcloud/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"httpHead","class":"Sabre\\DAV\\CorePlugin","type":"->"},{"file":"/usr/share/webapps/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php","line":474,"function":"emit","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/usr/share/webapps/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php","line":251,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/usr/share/webapps/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php","line":319,"function":"start","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/usr/share/webapps/nextcloud/apps/dav/appinfo/v1/webdav.php","line":84,"function":"exec","class":"Sabre\\DAV\\Server","type":"->"},{"file":"/usr/share/webapps/nextcloud/remote.php","line":167,"args":["/usr/share/webapps/nextcloud/apps/dav/appinfo/v1/webdav.php"],"function":"require_once"}],"File":"/usr/share/webapps/nextcloud/apps/dav/lib/Connector/Sabre/ObjectTree.php","Line":173,"CustomMessage":"--"},"userAgent":"Mozilla/5.0 (Android) Nextcloud-android/3.15.1","version":"20.0.7.1"} {"reqId":"zZkHhJpXue7R7tu2WU7F","level":0,"time":"2021-05-06T21:19:46+01:00","remoteAddr":"192.168.6.24","user":"steve","app":"guests","method":"HEAD","url":"/remote.php/webdav/Photos/2021/05/20210506_205020.jpg","message":"/appinfo/app.php is deprecated, use \\OCP\\AppFramework\\Bootstrap\\IBootstrap on the application class instead.","userAgent":"Mozilla/5.0 (Android) Nextcloud-android/3.15.1","version":"20.0.7.1"} {"reqId":"zZkHhJpXue7R7tu2WU7F","level":0,"time":"2021-05-06T21:19:46+01:00","remoteAddr":"192.168.6.24","user":"steve","app":"contacts","method":"HEAD","url":"/remote.php/webdav/Photos/2021/05/20210506_205020.jpg","message":"/appinfo/app.php is deprecated, use \\OCP\\AppFramework\\Bootstrap\\IBootstrap on the application class instead.","userAgent":"Mozilla/5.0 (Android) Nextcloud-android/3.15.1","version":"20.0.7.1"} {"reqId":"zZkHhJpXue7R7tu2WU7F","level":0,"time":"2021-05-06T21:19:46+01:00","remoteAddr":"192.168.6.24","user":"steve","app":"files_ sharing","method":"HEAD","url":"/remote.php/webdav/Photos/2021/05/20210506_205020.jpg","message":"/appinfo/app.php is deprecated, us \\OCP\\AppFramework\\Bootstrap\\IBootstrap on the application class instead.","userAgent":"Mozilla/5.0 (Android) Nextcloud-android/3.15.1","version":"20.0.7.1"} {"reqId":"zZkHhJpXue7R7tu2WU7F","level":1,"time":"2021-05-06T21:19:46+01:00","remoteAddr":"192.168.6.24","user":"steve","app":"no app in context","method":"HEAD","url":"/remote.php/webdav/Photos/2021/05/20210506_205020.jpg","message":"Deprecated event type for {\"[object] (OCP\\SabrePluginEvent)\":{\"*statusCode\":200,\"*message\":\"\",\"*server\":{\"[object] (OCA\\DAV\\Connector\\Sabre\\Server)\":{\"tree\":\"[object] (OCA\\DAV\\Connector\\Sabre\\ObjectTree)\",\"*baseUri\":\"/remote.php/webdav/\",\"httpResponse\":\"[object] (Sabre\\HTTP\\Response)\",\"httpRequest\":\"[object] (Sabre\\HTTP\\Request)\",\"sapi\":\"[object] (Sabre\\HTTP\\Sapi)\",\"*plugins\":[],\"transactionType\":null,\"protectedProperties\":{\"...\":\"Over 20 items, aborting normalization\"},\"debugExceptions\":false,\"resourceTypeMapping\":[],\"enablePropfindDepthInfinity\":true,\"xml\":\"[object] (Sabre\\DAV\\Xml\\Service)\",\"*listeners\":{\"...\":\"Over 20 items, aborting normalization\"},\"*wildcardListeners\":[],\"*listenerIndex\":[],\"*logger\":null}},\"Symfony\\Contracts\\EventDispatcher\\EventpropagationStopped\":false}}: null","userAgent":"Mozilla/5.0 (Android) Nextcloud-android/3.15.1","version":"20.0.7.1"} {"reqId":"zZkHhJpXue7R7tu2WU7F","level":1,"time":"2021-05-06T21:19:46+01:00","remoteAddr":"192.168.6.24","user":"steve","app":"no app in context","method":"HEAD","url":"/remote.php/webdav/Photos/2021/05/20210506_205020.jpg","message":"Deprecated event type for {\"[object] (OCP\\SabrePluginEvent)\":{\"*statusCode\":200,\"*message\":\"\",\"*server\":{\"[object] (OCA\\DAV\\Connector\\Sabre\\Server)\":{\"tree\":\"[object] (OCA\\DAV\\Connector\\Sabre\\ObjectTree)\",\"*baseUri\":\"/remote.php/webdav/\",\"httpResponse\":\"[object] (Sabre\\HTTP\\Response)\",\"httpRequest\":\"[object] (Sabre\\HTTP\\Request)\",\"sapi\":\"[object] (Sabre\\HTTP\\Sapi)\",\"*plugins\":{\"...\":\"Over 20 items, aborting normalization\"},\"transactionType\":\"head\",\"protectedProperties\":{\"...\":\"Over 20 items, aborting normalization\"},\"debugExceptions\":false,\"resourceTypeMapping\":[],\"enablePropfindDepthInfinity\":true,\"xml\":\"[object] (Sabre\\DAV\\Xml\\Service)\",\"*listeners\":{\"...\":\"Over 20 items, aborting normalization\"},\"*wildcardListeners\":[],\"*listenerIndex\":[],\"*logger\":null}},\"Symfony\\Contracts\\EventDispatcher\\EventpropagationStopped\":false}}: null","userAgent":"Mozilla/5.0 (Android) Nextcloud-android/3.15.1","version":"20.0.7.1"}

I see something in there that looks like the photo can't be found... yet it (eventually) synchronised successfully (and conflicted...).

Hope that there's some useful information in there! :)

[github-actions]

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

[InfamousUser]

Just close it, I cba with these reports anymore, so much time wasted arguining with bots and opening closed issues, if nobody wants to fix these issues for years then forget it.

[WarmChocolateCake]

It's still an issue for me, so I'd prefer to keep it open.
Sometimes it works fine, sometimes it uploads some photos and then stops...

I see loads of "depreciated" errors in my log above and something about "over 20 items"... I'm sure I had 1 photo to upload...

[theing]

I have the same behavior.
My server is on an embedded device in my home for my personal use, with WI-FI and without any SSL protection but this is not a problem.
The auto-upload service stopped to work a couple of months ago, that means that when the device is connects to the wi-fi the upload service notification did not appear and nothing is uploaded, while when I try to share a file manually it is correctly updated.
Logging th OwnCloud library with a logcat I see something like an error:
6-14 19:37:14.591 20366 2433 E ReadFolderRemoteOperation: at com.owncloud.android.lib.common.OwnCloudClient.executeMethod(OwnCloudClient.java:219)
I do not know if this is the cause of the problem but everything else works correctly and if I'm not wrong, when I share something manually, no folder are read locally, but the file is streamed, directly to the remote server, while when the upload service starts it has to read some folder to check if new files were added.
I do not know exactly when, but I'm sure that recently my Android phone was update by Samsung to Android 11 and I know that Google changed several things in the external memory management, I tried to delete the application data and cache to check for folder mismatching, but nothing changed.
Thank, you.

[InfamousUser]

For me it did not work correctly for like 3-4 major Android versions, don't think it matters which one.

[WarmChocolateCake]

Just wondering whether @AndyScherzinger can comment on this issue?

[AndyScherzinger]

@WarmChocolateCake sure thing, while I can't add much value with a comment at the moment due to personal time constraints regarding spending time on this matter. So here we go:

• wrongly shown/detected conflicts (as in false positive) have been reported numerous times. Since I haven't worked on that area I can't guess what might go wrong here, but due to the number of reports there is very likely something wrong with the actual implementation.
• Auto Upload for media files on sd card are known to be a volatile thing. This is due to the way is has been implemented. The "standard" auto upload (as in folders shown in the auto upload screen, deteced by the app) are based on querying Android's media index which as it turned out is flaky at best for sd card data. So we only "see" files Android itself detects and puts into its index. Using custom folders in auto upload instead of the suggested auto detected folder might work (can't say). This is a tricky area since most (or all?) devs I know contributing to the3 app are using devices that don't have an sd card (and thus don't have/see such problems). Reboot as mentioned do help, since that might trigger Androids media indexing and also reboots/restarts the auto upload background job (which isn't a solution but the reason you might see a "positive effect")
• Any connectivity issue should be "ignored for now" since that has been a general issue for certain server http requests and has been fixed afaik and should ship with the next feature release.

So due to time constraints. If anybody having the problem you all described and could work on a fix/PR than we would definitely support you in any way possible. Not a satisfying answer I am afraid but the best I can do (personally) at this moment.

[theing]

Last week something happened.
As many routers my router has two different entries , one for the 5Ghz and one for the old protocol 2.4Ghz. Obviously the cloud is reachable on both channels. Due to a range problem in order to reach my network from the garage, I changed the connection of my mobile phone from the 5Ghz band entry to the 2.4GHz band entry and Nexcloud started to sync again. I exclude it was a range problem before, because I tested it at a couple of meters, from the same router, and the cloud was always reachable, but before the switch It was not able to auto-upload anything, I don't know if it is a casual instance, but the Nexcloud auto-upload runs properly now. Hope this helps.

[thenickname]

@WarmChocolateCake sure thing, while I can't add much value with a comment at the moment due to personal time constraints regarding spending time on this matter. So here we go:

* wrongly shown/detected conflicts (as in false positive) have been reported numerous times. Since I haven't worked on that area I can't guess what might go wrong here, but due to the number of reports there is very likely something wrong with the actual implementation.

* Auto Upload for media files on sd card are known to be a volatile thing. This is due to the way is has been implemented. The "standard" auto upload (as in folders shown in the auto upload screen, deteced by the app) are based on querying Android's media index which as it turned out is flaky at best for sd card data. So we only "see" files Android itself detects and puts into its index. Using custom folders in auto upload instead of the suggested auto detected folder might work (can't say). This is a tricky area since most (or all?) devs I know contributing to the3 app are using devices that don't have an sd card (and thus don't have/see such problems). Reboot as mentioned do help, since that might trigger Androids media indexing and also reboots/restarts the auto upload background job (which isn't a solution but the reason you might see a "positive effect")

* Any connectivity issue should be "ignored for now" since that has been a general issue for certain server http requests and has been fixed afaik and should ship with the next feature release.

So due to time constraints. If anybody having the problem you all described and could work on a fix/PR than we would definitely support you in any way possible. Not a satisfying answer I am afraid but the best I can do (personally) at this moment.

I would like to add that this is not exclusive to SD cards. My experience is, sooner or later auto upload will break and then never work with the same folder again. Only workaround is to create a new folder with different name and enable it for auto upload. After a few weeks auto upload will break again and stop detecting files or uploading them.

[WarmChocolateCake]

For me, I autoupload photos mostly, if I had your problem @thenickname, that would mean I would need to keep changing the camera app to save photos to each new folder. I don't have to do that.
But yes, my photos are on an SD card.

To add, my SD card is formatted as "Portable" (FAT/unencrypted), rather than "Internal" / "Adoptable" (encrypted)

[InfamousUser]

I'm sure it isn't a problem for everyone. But it doesn't work for everyone either.

[shr3k]

Same issue, client (both latest and dev) shows nothing to upload, photos are uploaded randomly. Using Mi 10/MIUI 12.2.7/Android 11. Source is on /storage/emulated/0/DCIM/Camera.

[moaxey]

My photos auto-upload fine, but I set up an additional auto upload folder for audio recordings, and it will never work.

The only remotely relevant log message I can find is:

"reqId":"J03XONxSzGVrBXb8z7tB","level":0,"time":"2021-07-18T03:46:43+00:00","remoteAddr":"192.168.2.1","user":"who","app":"files_sharing","method":"PROPFIND","url":"/remote.php/webdav/Recordings/Auto-uploads/","message":"/appinfo/app.php is deprecated, use \OCP\AppFramework\Bootstrap\IBootstrap on the application class instead.","userAgent":"Mozilla/5.0 (Android) Nextcloud-android/3.16.1","version":"20.0.10.1"}
{"reqId":"J03XONxSzGVrBXb8z7tB","level":0,"time":"2021-07-18T03:46:43+00:00","remoteAddr":"192.168.2.1","user":"who","app":"maps","method":"PROPFIND","url":"/remote.php/webdav/Recordings/Auto-uploads/","message":"/appinfo/app.php is deprecated, use \OCP\AppFramework\Bootstrap\IBootstrap on the application class instead.","userAgent":"Mozilla/5.0 (Android) Nextcloud-android/3.16.1","version":"20.0.10.1"}
{"reqId":"J03XONxSzGVrBXb8z7tB","level":1,"time":"2021-07-18T03:46:43+00:00","remoteAddr":"192.168.2.1","user":"who","app":"no app in context","method":"PROPFIND","url":"/remote.php/webdav/Recordings/Auto-uploads/","message":"Deprecated event type for {"[object] (OCP\SabrePluginEvent)":{"*statusCode":200,"*message":"","*server":{"[object] (OCA\DAV\Connector\Sabre\Server)":{"tree":"[object] (OCA\DAV\Connector\Sabre\ObjectTree)","*baseUri":"/remote.php/webdav/","httpResponse":"[object] (Sabre\HTTP\Response)","httpRequest":"[object] (Sabre\HTTP\Request)","sapi":"[object] (Sabre\HTTP\Sapi)","*plugins":[],"transactionType":null,"protectedProperties":{"...":"Over 20 items, aborting normalization"},"debugExceptions":false,"resourceTypeMapping":[],"enablePropfindDepthInfinity":true,"xml":"[object] (Sabre\DAV\Xml\Service)","*listeners":{"...":"Over 20 items, aborting normalization"},"*wildcardListeners":[],"*listenerIndex":[],"*logger":null}},"Symfony\Contracts\EventDispatcher\EventpropagationStopped":false}}: null","userAgent":"Mozilla/5.0 (Android) Nextcloud-android/3.16.1","version":"20.0
.10.1"}

[klundry]

For some reason my DCIM/Camera/ folder, for photos, the auto-upload continues to work and hasn't broken. The identical auto-upload folder but for videos has been broken for a long time and never uploads anything. This is an extremely common problem it seems and one of the key features that makes using the Nextcloud app attractive and one of the 6 main features touted in the app description on f-droid. It's a bummer that this is so unreliable that it's pretty much not worth using anymore.

So some questions. Is there any hope of this ever being fixed? With numerous significant updates to the app in the at least year+(maybe multiple years) of this being an issue, why has this not ever been worked on?

PS. I apologize if this comes across as complaining. I'm thankful for the hard work the app developers do. It would, however, be nice to have some sort of explanation about the current and future state of this very large bug so we can evaluate whether or not we want to spend anymore time fighting with it. If there is little chance of it ever getting fixed then I'll just move on to a different solution.

[InfamousUser]

Unfortunately autoupload has never worked correctly for me for the past 3-4 years that I've been using Nextcloud. I have opened numerous issues regarding various things about it, most have gotten closed by the bot which means developers don't want issues to be unsolves for too long so they get closed, others have remained unsolved. I have given up on trying to help it get fixed as it was taking an inordinate amount of effort/result ratio.

[klundry]

Yep, still broken.

[jabdoa2]

Two LineageOS MotoX4's had the same issue. Phones are both running an older LineageOS (Android 10), Magisk, MicroG. Running NextCloud itself in docker with Nginx in front, no signs of trouble there. Granting the permissions the app never asked for previously (calendar/contacts) didn't fix it. Changing all to "deny", force stopping, opening app and hitting "OK" on the permissions dialog and granting storage permission fixed the issue (at least for now).

There's certainly a bug here somewhere, given that the issue started on both phones around the same time this issue was opened. If there's logging somewhere I can provide I'm happy to, but for now I'll take it just working again. Glad I don't deal with phone apps, the fragmentation on the Android side has to make issues like this really difficult to nail down.

Thanks for that! This fixed it for me as well. Super weird. Also on LineageOS.

Guess there is some breakage in permission logic in the app? It worked for a long time and stopped to work during April this year. Does that correspond to a certain app update?

[InfamousUser]

Guys, you are commenting on a separate issue to this one. The issue was posted in April last year, and it has been going on since much earlier.

[mxsrm]

Still not fixed...

[Pravi21]

Auto upload permanently stopped working! Please consider this issue and fix it.

[InfamousUser]

Nobody's at the helm of this app...

[prasannjeet]

Facing the same issue. Latest samsung and android version.

[prasannjeet]

Anyone facing this issue, please look at this thread for some plausible solutions: #9320

[elementum]

Geez, this is ridicuolous the feature that is the main driver of installing this app does not work. Changing permissions didn't make it work either.

[elementum]

I did my own investigation. It all started at 3.11 when sync existing files feature was introduced, however it had a bug. If you enabled syncing for a folder with a lot of files it would hang the app. Sometimes you wouldn't be able to open the app again, only reinstallation would help. The problem was that it proccessed (insert a record into db, so it seems) files in foreground thread which caused the app to hang.

So they decided to move it to background PR. But it doesn't seem to fix the issue, but rather hide it from user, and it seemingly fails in background. Since then syncronization stops working, enabling/disabling, syncing existing or new, nothing works anymore. The only way to make it work again is to reinstall the app.

So I suggest avoiding syncing folders with a lot of files, but rather copy existing files over the wire and enable only new files syncing.

[regs01]

For me autoupload in stable doesn't work at all. Nextcloud dev does. And I started off dev because I couldn't find stable, as it doesn't have an icon in F-Droid. So when I found it, I deleted dev, then installed stable. And nothing. All autoupload settings are setup. Added an exception to battery settings. Rebooted the phone. Still nothing. Autoupload does not react on any folder, whatever there are large number of files or just a few of files.

[regs01]

After turning off autoupload for a folder with 7000 photos autoupload is working for other folders. So looks like it was fixed in dev, but yet not in stable?

[regs01]

Reinstalled back dev version. Autoupload is working, but it hogs the battery permanently at a very high rate.

[metinc]

After turning off autoupload for a folder with 7000 photos autoupload is working for other folders. So looks like it was fixed in dev, but yet not in stable?

I can confirm this. I have a folder with 8000 photos. Nothing is being uploaded. When I disable auto upload for that folder other folders start uploading.

[InfamousUser]

Will someome fix this already? Why is development effort being wasted on this app if people cannot use it?

[OfficialMuffin]

Having similar issues here even without autoupload on Android 13 and NC app version 3.24.1. I queued a list of 80 video files to upload, when device goes to sleep, shortly after it stops. I have to manually swipe away (close app) and reopen it for the NC app to start the uploads again

[afluegel9]

I have 3.24.2 on Android 6.0.1. Photo upload works, but i have the impression i have to run the app regularly and open the upload menu to trigger it, otherwise it ceases to function. Video upload never starts. It was working about 2 years ago the last time. I have a 29 MB video, what i do not consider really big. I even copied the file to give it a newer timestamp. Does not get uploaded. Switching the videos section in the configuration on and off or slightly modifying it does not help. Battery optimization is switched off. For me it is really a pity, that this stopped to work.

[CaixaNegraPT]

Same on my side... worse is that I have literally thousands of photos as I us Nextcloud auto-upload as a way of backing up every since image/video I send/received in any app on my Android phone. Plus, I have other Android phones for other accounts doing the same...

Worse is that I enable all the uploads again but nothing starts uploading, I use "uploading existing files" with "skip uploading" if file exists... looks like the Android client is slowly parsing every single file, one by one... maybe in 2-3 days it will finish and start uploading...

[NicolasGoeddel]

@CaixaNegraPT wrote:

Same on my side... worse is that I have literally thousands of photos as I us Nextcloud auto-upload as a way of backing up every since image/video I send/received in any app on my Android phone. Plus, I have other Android phones for other accounts doing the same...

Worse is that I enable all the uploads again but nothing starts uploading, I use "uploading existing files" with "skip uploading" if file exists... looks like the Android client is slowly parsing every single file, one by one... maybe in 2-3 days it will finish and start uploading...

That's exactly how I use it too.

[regs01]

Some of Nextcloud dev version explicitly switched off auto upload for all folders. Now renabling doesn't do anything again. So stable version doesn't work and dev version doesn't work.

This is Top 1 feature for entire Nextcloud Hub solution. Why not to completely suspend all other developments and concentrate on this bug?

[InfamousUser]

Precisely... the exact thing I am wondering.

[NicolasGoeddel]

They seem to have solved it for RC2 and the final version: #11641 (comment)

[InfamousUser]

Unlikely, as they have "solved" it several times already, but it hasn't been working for multiple years; but I will still install the update.

[InfamousUser]

And, also, it is not in the changelog.

[joshtrichards]

@InfamousUser

05-14 18:45:55.764 4102 4152 E WM-WorkerWrapper: Work [ id=bbc41e32-4d61-44a2-a615-356a5955e499, tags={ com.nextcloud.client.jobs.FilesSyncWork, *, timestamp:1652546693037, name:immediate_files_sync } ] failed because it threw an exception/error

05-14 18:45:55.764 4102 4152 E WM-WorkerWrapper: at com.nextcloud.client.jobs.FilesSyncWork.doWork(FilesSyncWork.kt:98)

05-14 18:45:55.766 4102 4152 I WM-WorkerWrapper: Worker result FAILURE for Work [ id=bbc41e32-4d61-44a2-a615-356a5955e499, tags={ com.nextcloud.client.jobs.FilesSyncWork, *, timestamp:1652546693037, name:immediate_files_sync } ]

1. Is there more to the stack trace? (that second line). i.e. I would expect it to look more like the one in java.lang.NullPointerException in OfflineSyncWork.checkEtagChanged line 140 #11342
2. Can you post your actual auto-upload settings? (I don't see them in your reproduction steps)
3. Are you using a custom folder or an auto-detected folder? (ditto)
4. Do all of your auto-upload tests have a space (" ") in the remote folder name?

[InfamousUser]

I will retest this but I will need to update the server and dependencies first as they are outdated and configure them. A bit busy at the moment, will report back once I've managed to retest. This has been going on for years so I've stopped expecting solutions.

[InfamousUser]

Updated the server finally. Updated the OP with your points 2, 3. AFAIR all autoupload remote folders have a space since my phone name has a space.

Don't have that original error any longer I don't think.
It just started uploading stuff after about a day now. I set it up yesterday night and it only started uploading now while I was checking logs. Weird. If it takes a day to start working, it might as well not be working, ain't nobody got time for that... Now if readd autoupload to make a change, I can't wait until tomorrow to see if it works. I already removed one autoupload because it wasn't working, it uploaded a couple of files and then stopped. Is there a reason there would be such huge delays for everything? Server is reasonably fast and phone is top end...

[regs01]

Was ist das?

Updated to 3.28 and this has been up for many hours now. And not moving.