This is still an issue.

Folders for auto upload? I have Camera twice (/storage/emulated/0/DCIM/Camera; once for pictures, the other for videos), OpenCamera (/storage/emulated/0/DCIM/OpenCamera) and Screenshots (/storage/emulated/0/DCIM/Screenshots).

(I only tried OpenCamera briefly, recently, and have since uninstalled it. The issue at hand was present already back when I first got this phone and installed Nextcloud on it, last July.)

I’ve always had auto upload enabled until now, so can’t say whether it’s dependent on that. I could try disabling it next time the issue re-emerges; as dictated by Murphy’s law, I was unable to trigger it just now that I intentionally tried to.

Oh, and I am running Beta (so currently 3.11.0 RC4) of the Nextcloud app. Can’t remember when I enrolled in.

Here’s output from logcat:

03-19 16:33:47.099 20119 20119 E AndroidRuntime: FATAL EXCEPTION: main
03-19 16:33:47.099 20119 20119 E AndroidRuntime: Process: android.process.media, PID: 20119
03-19 16:33:47.099 20119 20119 E AndroidRuntime: java.lang.RuntimeException: Unable to start receiver com.android.providers.media.MediaScannerReceiver: java.lang.StringIndexOutOfBoundsException: length=1; index=-3
03-19 16:33:47.099 20119 20119 E AndroidRuntime:        at android.app.ActivityThread.handleReceiver(ActivityThread.java:3619)
03-19 16:33:47.099 20119 20119 E AndroidRuntime:        at android.app.ActivityThread.access$1300(ActivityThread.java:237)
03-19 16:33:47.099 20119 20119 E AndroidRuntime:        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1803)
03-19 16:33:47.099 20119 20119 E AndroidRuntime:        at android.os.Handler.dispatchMessage(Handler.java:106)
03-19 16:33:47.099 20119 20119 E AndroidRuntime:        at android.os.Looper.loop(Looper.java:214)
03-19 16:33:47.099 20119 20119 E AndroidRuntime:        at android.app.ActivityThread.main(ActivityThread.java:7078)
03-19 16:33:47.099 20119 20119 E AndroidRuntime:        at java.lang.reflect.Method.invoke(Native Method)
03-19 16:33:47.099 20119 20119 E AndroidRuntime:        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:494)
03-19 16:33:47.099 20119 20119 E AndroidRuntime:        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:964)
03-19 16:33:47.099 20119 20119 E AndroidRuntime: Caused by: java.lang.StringIndexOutOfBoundsException: length=1; index=-3
03-19 16:33:47.099 20119 20119 E AndroidRuntime:        at java.lang.String.substring(String.java:1995)
03-19 16:33:47.099 20119 20119 E AndroidRuntime:        at com.android.providers.media.utils.MPLogger.log(MPLogger.java:118)
03-19 16:33:47.099 20119 20119 E AndroidRuntime:        at com.android.providers.media.MediaProvider.call(MediaProvider.java:5073)
03-19 16:33:47.099 20119 20119 E AndroidRuntime:        at android.content.ContentProvider$Transport.call(ContentProvider.java:403)
03-19 16:33:47.099 20119 20119 E AndroidRuntime:        at android.content.ContentResolver.call(ContentResolver.java:1763)
03-19 16:33:47.099 20119 20119 E AndroidRuntime:        at com.android.providers.media.MediaScannerReceiver.logToDb(MediaScannerReceiver.java:139)
03-19 16:33:47.099 20119 20119 E AndroidRuntime:        at com.android.providers.media.MediaScannerReceiver.onReceive(MediaScannerReceiver.java:77)
03-19 16:33:47.099 20119 20119 E AndroidRuntime:        at android.app.ActivityThread.handleReceiver(ActivityThread.java:3610)
03-19 16:33:47.099 20119 20119 E AndroidRuntime:        ... 8 more

The upload process (I think) then dies:

03-19 16:33:47.164  2044 13653 I ActivityManager: Killing 20133:com.nextcloud.client/u0a0 (adj 100): depends on provider com.android.providers.media/.MediaProvider in dying proc android.process.media (adj 100)

I have the same issue on my Samsung Galaxy A9 phone, with ”android.process.media has stopped” appearing for virtually every photo taken (though the uploads seem to still go through). My Samsung Galaxy Tab S5e does not have the same issue, nor do I recall seeing this on any other Android devices (from other manufacturers).

I don’t use alarmapp (to my knowledge, though I’m not sure which app that is).

@juliushaertl Is backporting for docs also done as per the manual? It seems pretty straightforward, so I think I can produce those pull requests too, if needed.

Fix indefinite article before Nextcloud (an->a)

Sorry for necromancing, but because Google seems to like this thread, I just thought I’d add a mention that a check_data_directory_permissions option for config.php has since been implemented (and backported down to NC12), and it allows the admin to turn off the automatic permissions reset (by assigning it false).

This is discouraged however, and ACLs or other means of managing access are still the better option where available.

Fix typo: ”parameters and are” -> ”parameters are” in Using the occ command.

@skjnldsv The points you raise are about SEO, and (from what I linked to above) I believe those issues are already being worked on. In case I was unclear, I’m not arguing for my idea to supplant the SEO work currently in progress, but to augment it.

Obviously, if #915 gets implemented as requested, my issue becomes moot, but from reading the comments there I understand it’s not so cut and dried that it will be.

As discussed in #915 and #517, Google seems to prefer old versions’ documentation at the expense of newer ones for some reason. The issue was partly mitigated by the fix for #958, which added prominent links to the latest version on top of old pages.

But these links currently point to the manual root. Ideally, I’d like these links to point directly to the latest version of the specific manual page I’m viewing, if available.

For instance, a search for nextcloud occ (for me at least) currently yields the manual page for version 9 as the top result. The ”latest version” link at the top then takes me to the server manual introduction. This means it’s still easier for me to navigate to the latest version of the ”Using the occ command” page by manually replacing the version number in the current URL with ’stable’ (or the latest release number) than to follow the ”latest version” link and try to find the page there.

Producing specific links is probably more laborious than the generic top-level-pointing link. For instance, there may no longer be a corresponding page in the stable version. Detecting such cases should be automatable I think, but there may be other issues that aren’t.

This will be much less of an issue once the SEO issue is resolved, but I think direct links would still remain useful, as people can still come up with search terms that search engines think correspond to old documentation better than the latest.