Upload the whole camera roll

[tobiasKaminsky]

Steps to reproduce

1. have thousands of images
2. enable auto upload
3. enable "upload the whole camera roll"

Expected behaviour

• upload happens in background:
• upload can be resumed: if app is closed and re-opened upload process continues

Actual behaviour

See blocking info which tells me to keep app running until every image is uploaded.

[marinofaggiana]

A large number of Upload in background is NOT recommended, can block the process entirely, and in background mode don't works the Chunked

[tobiasKaminsky]

Would it be possible to store the pending uploads and once the user re-opens the app the user is asked to continue the upload in foreground?
So that after some time the user could upload all their thousands images?

[ne20002]

The automatic 'background' upload has always been an issue on iOS due to iOS suspending apps in 'background' very quickly (compared to e.g. Android).
It's also always misleading wordings of what is meant with 'background'.

As a user I expect to have the files in upload queue to be uploaded in 'background' which means, I don't expect to be 'asked if it should continue' when the app is in foreground. Users don't understand foreground/background the same way developers do.

For me as a user, I expect:

• files for upload will be detected and added to the upload queue (as far as I see, this is working mostly well)
• I then expect the files to be uploaded without having to do something or be asked for something. This is what a user understands when saying 'background'.

So what I (with a bit more IT knowledge) expect is:
1)

• the app get a) processing time from the OS, mainly when the app is in foreground (shown on the screen)
• the app gets b) sometimes, even when in background / not shown in foreground some processing times by event triggers or somethin similar.

when the app has processing time, it loops

• looks for new files that should be added to the queue and
• tries to upload the next element in the queue.
• if the element in the queue is large, it just uploads the next chunk
  After each loop iteration, if the app has still processing time, it does the next iteration of the loop, uploading the next element in queue or the next chunk of the element in the queue.

If the OS suspends the processing, the next time the app get processing time, it continues ... until all element in the queue are uploaded.
It may be an idea to prioritize smaller elements to keep the upload queue length smaller (easier to handle).
If the OS suspends the app, the current upload just dies. The next time the app gets processing time it simply continues with the first element in the queue (which probably is the element/chunk that died before). When the upload is successful, it is removed from the queue.

But as a user I don't want

• to be 'asked' if this process shall continue (it should)
• to see an error message stating that I need to keep the app in foreground (the chunk uploads shall also work when the app is not in foreground on the screen)

Also: afaik there is a trigger since iOS 13 that is meant for 'background' upload of bigger amounts of data when the device is on power cord and connected to internet. I would expect to use this (in addition to other events/triggers) for uploading the elements in the queue.

[ne20002]

Would it be possible to store the pending uploads and once the user re-opens the app the user is asked to continue the upload in foreground? So that after some time the user could upload all their thousands images?

As far as I see, this is already the case. Bringing the app in foreground leads to continuing the uploads.

For me there is mainly two things missing:

• chunk uploads shall also work in 'background' as with single complete files
• uploads shall be forced in 'background' when device has internet and is plugged

[dennore]

For my 10.000 photos it worked fine… but took long to start ( building index) also resume worked after restarting the app

But that after upload was complete and i turned off the upload all photos option. The local ios database/cache did not seem to purge… even after i clicked clear cache it still kept 1gb data on the phone…

i removed the account(reset app) and installed again, now its fine

[dvalter]

The issue persists through Nextcloud 4.8.0.5 (both iOS 15.x and 16.x).
App won't upload in background (without or with charging), but it will resume when it goes foreground.
From what I can see, app manages to finish uploading the current files in background, but won't stat uploading any more files, thus stalling the process.
I've looked through logs and network traffic, and from the former this looks suspicious <BGProcessingTaskRequest: com.nextcloud.processingTask, earliestBeginDate: <...>, requiresExternalPower=0, requiresNetworkConnectivity=0>, as it implies that nextcloud don't need network for the background task, and from the latter, TCP connection gets reset by client (or iOS kernel?) ~0.5s after the end of the file upload.

If it's impossible (as #2225 may suggest) to consistently upload files in background, a possible workaround may be to add an explicit screen-on foreground mode for the initial upload with screen locking inhibted. Then it would be also nice to make it single-color to protect OLED screens from burning out.

[dennore]

Just use ios "guided access" to prevent it go sleep and leave the iphone over night running to get all your photos synced

[dvalter]

Wow, nice hack. I haven't even noticed it has an option to force screen on. And for those who are concerned about OLEDs, the solution is to upload and open a pure black image in the app

[dennore]

Haha nice one with the black image :-)

[bardo]

It's nice, but it's still a hack, so it's not acceptable for end users. I think agree with @ne20002 on the expected behavior.