Still present in Nextcloud 3.21.2. My device is a Samsung A9 running Android 10.

Uusimman päivityksen myötä 1 tähti. Käytän sovellusta lähes päivittäin, mutta QR-koodia en ikinä missään, ja nyt tämä tyrkyttää sitä QR-koodinlukijaa oletuksena. Eikä ainakaan aiemmin tänään S-ryhmän päätteessä toiminut Bluetooth-maksaminen enää ollenkaan, eli ei edes sitten kun olin tuon QR-turhakkeen pyyhkäissyt pois tieltä (ei Androidilla eikä Iphonella). Laadunvalvonta on tekijällä pettänyt nyt lyhyen ajan sisällä jo kahdesti, eikä siellä vissiin UX-asiantuntijoitakaan paljon kuunnella.

Yes, they’re dismissible. They can even be brought back on after that (with another tap), and then they do disappear on their own.

I’ve updated Android on the tablet since reporting this, it’s now running Android 11 with One UI 3.1, with no change in the behavior as reported.

I’ve also tested landscape, portrait and autorotate modes, all with the same result.

Firstly, a big thank you @MSe1969 for keeping my old Moto G (falcon) secure!

My question is about a specific feature: for some reason, Motorola has apparently disabled charging the device when the camera (flash) LED is on (I’ve found at least one Reddit thread confirming this). Do you happen to know if this is a hardware-level limitation, or if there’s any way to override it in the OS/kernel?

I’ve been testing the phone as a security camera, and while it’s otherwise working, in practical use not having the flash LED means having to have a separate light source, adding its own complications (timers and so on).

Android 7.1.2 (LineageOS 14.1) is affected.

Nextcloud is somehow different from other apps in this regard, as no other light (white) apps on the same device have this issue. For instance, here’s Play Store on my affected device (running Android 6.0.1):

Also, I seem to recall this only having started to affect Nextcloud quite recently, perhaps sometime in the past month or so.

Switching to dark mode is a workaround on my device at least (there the Android buttons are light-on-black). I can also confirm that the issue doesn’t affect my newer devices with newer Android.

Checklist

•  I am using the latest version – v0.22.1
•  I checked, but didn’t find any duplicates (open OR closed) of this issue in the repo.
•  I have read the contribution guidelines
•  This issue contains only one bug. I will open one issue for every bug report I want to file.

Steps to reproduce the bug

0. Disable ”Start main player in fullscreen” in NewPipe settings
1. Have a somewhat slow-to-load video (for whatever reason)
2. Open the video in Newpipe
3. Before video details (such as duration) have loaded, tap to switch to fullscreen

Actual behaviour

The playback controls remain on screen while the video plays, I have to tap once more to make them go away.

Expected behavior

The playback controls should disappear like they do when switching to fullscreen after the video details have loaded (and playback has begun).

Screenshots/Screen recordings

Device info

• Android version/Custom ROM version: Android 10 with OneUI 2.5
• Device model: Samsung Galaxy Tab S5e

I went back in time using F-droid’s dev archive, testing all the way to around when 3.9.2 was released (2019-12-07), and the issue persisted, so this is indeed some weird interaction with the latest server version(s) and particularly the conflicts detection thereof.

Version 20191206 (2019-12-07) exhibited the issue a bit differently, though probably just due to how handling of conflicts on the client end has changed between then and now: one file that did go through got renamed with ”(1)” added to it, even though there was no previously existing copy on the server. A previous attempt to upload the same file (using another client version) had failed, so that’s one possible explanation for why the server thought that a previous copy did exist.

Another file got seeminly stuck in the (client upload) queue, and watching the server log revealed that it was incrementing the added number continuously, always coming up with the same ”could not be located” exception from Sabre\DAV as above. It had run up to 80 when I cancelled the upload from the client, and would have perhaps run indefinitely if I didn’t.

{"reqId":"SmCGdnw4BzFQ5P25wMGV","level":0,"time":"2020-11-20T17:40:54+02:00","remoteAddr":"REDACTED","user":"testituutti","app":"webdav","method":"HEAD","url":"/varasto/remote.php/webdav/Testidataa/DSC_0003%20(75).JPG","message":{"Exception":"Sabre\\DAV\\Exception\\NotFound","Message":"File with name Testidataa/DSC_0003 (75).JPG could not be located","Code":0,"Trace":[{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/CorePlugin.php","line":81,"function":"getNodeForPath","class":"OCA\\DAV\\Connector\\Sabre\\ObjectTree","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"httpGet","class":"Sabre\\DAV\\CorePlugin","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":474,"function":"emit","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/CorePlugin.php","line":262,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"httpHead","class":"Sabre\\DAV\\CorePlugin","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":474,"function":"emit","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":251,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":319,"function":"start","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/apps/dav/appinfo/v1/webdav.php","line":84,"function":"exec","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/remote.php","line":167,"args":["REDACTED/www/varasto/apps/dav/appinfo/v1/webdav.php"],"function":"require_once"}],"File":"REDACTED/www/varasto/apps/dav/lib/Connector/Sabre/ObjectTree.php","Line":173,"CustomMessage":"--"},"userAgent":"Mozilla/5.0 (Android) Nextcloud-android/20191207","version":"20.0.1.1"}
{"reqId":"M3RTK4KRuOH3N0xGrp2Q","level":0,"time":"2020-11-20T17:41:00+02:00","remoteAddr":"REDACTED","user":"testituutti","app":"webdav","method":"HEAD","url":"/varasto/remote.php/webdav/Testidataa/DSC_0003%20(76).JPG","message":{"Exception":"Sabre\\DAV\\Exception\\NotFound","Message":"File with name Testidataa/DSC_0003 (76).JPG could not be located","Code":0,"Trace":[{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/CorePlugin.php","line":81,"function":"getNodeForPath","class":"OCA\\DAV\\Connector\\Sabre\\ObjectTree","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"httpGet","class":"Sabre\\DAV\\CorePlugin","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":474,"function":"emit","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/CorePlugin.php","line":262,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"httpHead","class":"Sabre\\DAV\\CorePlugin","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":474,"function":"emit","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":251,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/3rdparty/sabre/dav/lib/DAV/Server.php","line":319,"function":"start","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/apps/dav/appinfo/v1/webdav.php","line":84,"function":"exec","class":"Sabre\\DAV\\Server","type":"->"},{"file":"REDACTED/www/varasto/remote.php","line":167,"args":["REDACTED/www/varasto/apps/dav/appinfo/v1/webdav.php"],"function":"require_once"}],"File":"REDACTED/www/varasto/apps/dav/lib/Connector/Sabre/ObjectTree.php","Line":173,"CustomMessage":"--"},"userAgent":"Mozilla/5.0 (Android) Nextcloud-android/20191207","version":"20.0.1.1"}

1.37.0 fails to build in my build environment (Ubuntu 18.04 in LXC) with this error:

ubuntu@mattermost-mobile:~/mattermost-mobile$ npm run build:android

> mattermost-mobile@1.37.0 build:android /home/ubuntu/mattermost-mobile
> ./scripts/build.sh apk

./scripts/build.sh: 3: ./scripts/build.sh: Syntax error: "(" unexpected
npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! mattermost-mobile@1.37.0 build:android: `./scripts/build.sh apk`
npm ERR! Exit status 2
npm ERR! 
npm ERR! Failed at the mattermost-mobile@1.37.0 build:android script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/ubuntu/.npm/_logs/2020-11-14T11_47_00_288Z-debug.log

The top of that file, build.sh, refers to /bin/sh, but on Ubuntu and Debian, /bin/sh has been Dash for quite a while, whereas build.sh seems to written for Bash (where function is a valid keyword):

ubuntu@mattermost-mobile:~/mattermost-mobile$ head scripts/build.sh 
#!/bin/sh

function execute() {
    cd fastlane && NODE_ENV=production bundle exec fastlane $1 $2
}

I suggest switching the shebang to #/bin/bash, or better yet, #!/usr/bin/env bash (for path-agnosticity). In my environment, using either one fixes the build.

@tobiasKaminsky Yup, tried it and the issue remains. Also found a device with 3.13.1, and it too is affected now, so this now seems more server-related, though it is weird that the desktop client hasn’t been affected at any point. I would have assumed both clients employ the same webdav commands (and thus fail or succeed just the same).

Syncing a folder in Android app’s ”all files” view also still works (i.e. downloading changes causes no issues).

I have another server instance on another host, and there uploading from Android still works. This (working) instance is unencrypted, while the non-working instance has server-side encryption enabled.