@agnivade Oh I see, so it’s a result of conflicting indicators (”away” vs. being active) from the user. I’m trying to recalibrate my expectation based on this, but it’s difficult.

My immediate thought is perhaps (in the problematic case) sending the notification, but then clearing it only once I start typing (typing appears to have an event associated with it, at least based on the logs) would be better than the immediately clearing ghost notification, but you’re right, this is more complicated than immediately apparent.

Some UI/UX design wizardry would probably be needed to eliminate the possibility of mixed user signals, if at all possible. I don’t have a good solution for now, so feel free to close the issue if you deem it appropriate.

Yup, your description of the issue is exactly right @agnivade, and thanks for looking into this!

I set up the two users in parallel windows. Sending a normal message as userB this way does not trigger the issue (I do get a notification on userA’s phone, but it doesn’t go away by itself), but that’s because userA’s window is (obviously) not active, since I’m typing in userB’s window. The notification is only cleared once I activate userA’s window.

But I can trigger the issue by using (for instance) /echo 'hello A' 4 instead (as userB), then hopping on to activate userA’s window during the 4-second delay, so that userA’s window is active when receiving the message. That’s the crucial bit: the receiver’s window is active when receiving the message. If his status is ’Online’, there’s no push notification (as expected), but if it’s ’Away’, that’s when I get the ghost notification.

Here’s server log and MPNS log during one minute where (as userB) I first send a normal message, then (at about 30 seconds) using /echo.

Yes, this is still reproducible here with the current server (v5.29.1).

Here’s the server log and MPNS log during which

1. I switch log level from error to debug
2. I send one ”hello” message to a bot (from the web UI)
3. the bot responds with one message
4. I switch log level from debug back to error

• VSCode Version: 1.53.0
• OS Version: Ubuntu Linux 20.04

Steps to Reproduce:

1. install .deb package
2. run debsums -s

Does this issue occur when all extensions are disabled?: Yes

I’d like to resurrect #37762: the checksums for .desktop files included in the .deb archive fail to pass post-install.

$ debsums -s code
debsums: changed file /usr/share/applications/code.desktop (from code package)
debsums: changed file /usr/share/applications/code-url-handler.desktop (from code package)

This happens because the postinst script calls desktop-file-install for the .desktop files, which adds an X-Desktop-File-Install-Version entry to them, and hence the checksums change.

I don’t know why the desktop-file-install call is there, as including the .desktop files in the deb archive is sufficient to have them installed (in their proper place under /usr/share/applications/), with the checksum intact.

I built the package with just those desktop-file-install calls removed (see below), after which the checksums pass post-install (with no other changes that I can see).

diff --git a/resources/linux/debian/postinst.template b/resources/linux/debian/postinst.template
index c72fe5f9f5..dcc147de93 100755
--- a/resources/linux/debian/postinst.template
+++ b/resources/linux/debian/postinst.template
@@ -12,12 +12,6 @@ ln -s /usr/share/@@NAME@@/bin/@@NAME@@ /usr/bin/@@NAME@@
 # developers would prefer a terminal editor as the default.
 update-alternatives --install /usr/bin/editor editor /usr/bin/@@NAME@@ 0
 
-# Install the desktop entry
-if hash desktop-file-install 2>/dev/null; then
-       desktop-file-install /usr/share/applications/@@NAME@@.desktop
-       desktop-file-install /usr/share/applications/@@NAME@@-url-handler.desktop
-fi
-
 # Update mimetype database to pickup workspace mimetype
 if hash update-mime-database 2>/dev/null; then
        update-mime-database /usr/share/mime

All right, looks like this is VSCode issue #37762 (and MD5 usage is #99760).

$ md5sum --quiet -c /var/lib/dpkg/info/codium.md5sums
usr/share/applications/codium-url-handler.desktop: FAILED
usr/share/applications/codium.desktop: FAILED
md5sum: WARNING: 2 computed checksums did NOT match

$ apt-cache policy codium
codium:
  Installed: 1.51.1-1605141118
  Candidate: 1.51.1-1605141118
  Version table:
 *** 1.51.1-1605141118 500
        500 https://paulcarroty.gitlab.io/vscodium-deb-rpm-repo/debs vscodium/main amd64 Packages
        100 /var/lib/dpkg/status

Sorry, tried to link this with LP #1723881 but failed, because LP #1334

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"}