iOS app: HTTP 500 after uploading ~ 44'000 photos
Nobody has claimed this yet.
- Dominant language
- Swift
- Stars
- 2.5k
- Forks
- 1k
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 13
Description
Steps to reproduce
-
Provide an iPhone with approx. 44,000 photos in the iCloud/camera memory.
-
Connect the NC app via user login to a NC instance (in the LAN) with sufficient storage space.
-
Configure the iOS device to not lock the screen at all.
-
Configure this in the settings:
- automatic upload
- separate folder (not default "Photos")
- ... of pictures (only via WLAN)
- ... of videos (only via WLAN)
- !! upload complete camera memory !!!
- Use subfolders
- Subfolder granularity: monthly
- Filename mask: YYYY-MM-DDThh.mm.ss_
Expected behaviour
After a reasonable transfer and processing time all photos are uploaded to the NC instance AND all uploaded photos are removed from the iOS device.
Actual behaviour
- After a reasonable transfer and processing time (~ 36h) all photos are uploaded to the NC instance.
- The Count indicator at the apps ui left bottom shows a small number of files to upload (once 3, once 1, once 8).
- A red banner at the apps ui top saying "file upload: 500: internal server error" shows up cyclically. It seems to be coupled with the "upload file counter". The app tries to upload the files and repeatedly ends up in HTTP 500.
- NO photo got removed from the ios device
- The server reports HTTP 500 for files which are obviously uploaded
AND all uploaded photos are removed from the iOS device.
fetching for existing / missing files along HTTP 500
for f in $(grep 'HTTP/1.1" 500' syslog daemon.log |
sed -e 's# HTTP/1.1.*$##' |
sed -s 's#^.* - testuser ##' |
sed -e 's#^.*PUT /remote.php/dav/files/testuser/##' | sort -u);
do [ -e "/srv/nextcloud/data/testuser/files/$f" ] &&
(echo -n "file exists: "; ls -lih "/srv/nextcloud/data/nisse/files/$f" ) || "file missing: $f";
done
Screenshots
If applicable, add a screenshot showing the issue.
Logs
iPad logs of the whole upload are attached.
If applicable, you can post the iOS app or server logs (removing any sensitive information).
```
### Reasoning or why should it be changed/implemented?
Moving the whole camera storage seems to fail on larger amounts of media files.
Maybe i'm not the only person with a larger set of photos.
A staggered upload, e.g. in stacks of e.g. 5000 files (adjustable?) could be of help.
### Environment data
apache docker container with PHP Memory Limit of 640MByte. I'd extend the memory limit from 512 to 640Mbyte as the first upload experiments ended up with some of these messages: "PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 4005144 bytes) in /var/www/html/custom_apps/maps/lib/Helper/ExifGeoData.php on line 120"
**iOS version:** e.g. iOS 14.4.1
iPhone SE (2) iOS 16.5.1
iPad Pro 10.5" iOS 16.5.1
**Nextcloud iOS app version:** see More > Settings
Nextcloud Liquid for iOS 4.8.5.1
[ipad-communication2-1.log](https://github.com/nextcloud/ios/files/12011605/ipad-communication2-1.log)
[ipad-communication2-2.log](https://github.com/nextcloud/ios/files/12011606/ipad-communication2-2.log)
[ipad-communication2-3.log](https://github.com/nextcloud/ios/files/12011607/ipad-communication2-3.log)
**Server operating system:**
Linux nextbox 5.10.103-v8+ #1529 SMP PREEMPT Tue Mar 8 12:26:46 GMT 2022 aarch64 GNU/Linux
**Web server:** Apache, nginx
Server version: Apache/2.4.56 (Debian)
Server built: 2023-04-02T03:06:01
**Database:**
MariaDB
Server version: 10.5.9-MariaDB-1:10.5.9+maria~focal mariadb.org binary distribution
**PHP version:**
HP 8.2.7 (cli) (built: Jun 13 2023 23:22:26) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.7, Copyright (c) Zend Technologies
with Zend OPcache v8.2.7, Copyright (c), by Zend Technologies
**Nextcloud version:** see Nextcloud admin page
26.0.3
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with ipad-communication2-1.log, ipad-communication2-2.log, and ipad-communication2-3.log, correlating recurring HTTP 500 PUTs with the server logs and the upload counter. Reproduce the reported large-library upload and verify whether failed requests target files that already exist. Done means the upload completes without recurring HTTP 500 errors and successfully uploaded photos are removed from the device.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- swift
- Domain
- api, mobile
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 32/100