Avainsanana Nextcloud

This is still an issue.

28. huhtikuuta 2020 klo 16.49
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Nextcloud

This is still an issue.

Vastaa viestiin sen kontekstissa (Github)

For auto upload? I have Camera, OpenCamera and Screenshots

26. maaliskuuta 2020 klo 13.29
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Nextcloud

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.

Vastaa viestiin sen kontekstissa (Github)

Here’s output from logcat:

19. maaliskuuta 2020 klo 16.41
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Nextcloud

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)

Vastaa viestiin sen kontekstissa (Github)

I have the same ”android.process.media has stopped” issue on my Samsung phone

19. maaliskuuta 2020 klo 16.28
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Android, Nextcloud, Samsung

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).

Vastaa viestiin sen kontekstissa (Github)

I think can produce backports too

10. tammikuuta 2019 klo 18.22
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Github, Nextcloud

@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.

Vastaa viestiin sen kontekstissa (Github)

Fix indefinite article before Nextcloud (an->a)

10. tammikuuta 2019 klo 17.50
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: kieli, Nextcloud

Fix indefinite article before Nextcloud (an->a)

Vastaa viestiin sen kontekstissa (Github)

check_data_directory_permissions allows the admin to turn off the automatic permissions reset

10. tammikuuta 2019 klo 13.48
Sijainti: Keskustelupalstat: Nextcloud
Avainsanat: Google, Nextcloud, turvallisuus

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.

Vastaa viestiin sen kontekstissa (Nextcloud)

Fix typo: ”parameters and are” -> ”parameters are”

1. tammikuuta 2019 klo 13.51
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Nextcloud

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

Vastaa viestiin sen kontekstissa (Github)

I believe those issues are already being worked on

31. joulukuuta 2018 klo 18.37
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Google, Nextcloud

@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.

Vastaa viestiin sen kontekstissa (Github)

Point ”latest version” links to specific page

31. joulukuuta 2018 klo 13.40
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Google, Nextcloud

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.

Vastaa viestiin sen kontekstissa (Github)

Vanhempia »