Steps to reproduce

Note the literal use of example.com here; don’t replace it with an actual, working MM instance URL.

# /usr/bin/sudo -u mattermost /usr/local/bin/mmctl  auth login http://example.com --name example --access-token 123456890abcdefghijklmnopq`
# echo $?

What I expect happen

For a non-zero exit status to be printed.

What happens instead

The exit status is 0.

Issue

When a custom configuration file is supplied via --config to auth login, and reading credentials from the given file doesn’t succeed, an attempt is made to create the supplied directory path. This path is constructed by stripping a fixed ”config” (without a directory separator) from the user-supplied path.

When the custom configuration file doesn’t exist, this results in an unnecessary mkdir when the given filename ends with the hardcoded value of ”config” (case 1 below), or that plus a ”is a directory” failure when it doesn’t (case 2).

If the custom configuration file does exist, the useless mkdir is still triggered when the given filename ends with the hardcoded value of ”config” (case 3), or a ”not a directory” failure when it doesn’t (case 4).

Cause

The problematic mkdir call is issued here. I have no experience in Go, but instead of the TrimSuffix() call nested on that line, I think there should be a Go equivalent of a dirname instead, using the user-supplied path as parameter, and without referencing the value of configFileName (the source of the hardcoded ”config”).

Steps to reproduce

Case 1

A useless, empty mmctl_ directory gets created:

# rm -rf /tmp/mmctl_test/
# sudo -u mattermost mkdir /tmp/mmctl_test/
# /usr/bin/sudo -u mattermost /usr/local/bin/mmctl auth --quiet login https://example.com --name example --access-token 123456890abcdefghijklmnopq --config /tmp/mmctl_test/mmctl_config

  credentials for "example": "Personal Access Token@https://example.com" stored

# ls -lRa /tmp/mmctl_test/
/tmp/mmctl_test/:
yhteensä 24
drwxrwxr-x  3 mattermost mattermost  4096 tammi  30 15:27 .
drwxrwxrwt 23 root       root       12288 tammi  30 15:27 ..
drwx------  2 mattermost mattermost  4096 tammi  30 15:27 mmctl_
-rw-------  1 mattermost mattermost   244 tammi  30 15:27 mmctl_config

/tmp/mmctl_test/mmctl_:
yhteensä 8
drwx------ 2 mattermost mattermost 4096 tammi  30 15:27 .
drwxrwxr-x 3 mattermost mattermost 4096 tammi  30 15:27 ..

Case 2

Saving the credentials fails:

# rm -rf /tmp/mmctl_test/
# sudo -u mattermost mkdir /tmp/mmctl_test/
# /usr/bin/sudo -u mattermost /usr/local/bin/mmctl auth --quiet login https://example.com--name example --access-token 123456890abcdefghijklmnopq --config /tmp/mmctl_test/test
Error: cannot save the credentials: open /tmp/mmctl_test/test: is a directory
# ls -lRa /tmp/mmctl_test/
/tmp/mmctl_test/:
yhteensä 20
drwxrwxr-x  3 mattermost mattermost  4096 tammi  30 15:31 .
drwxrwxrwt 23 root       root       12288 tammi  30 15:31 ..
drwx------  2 mattermost mattermost  4096 tammi  30 15:31 test

/tmp/mmctl_test/test:
yhteensä 8
drwx------ 2 mattermost mattermost 4096 tammi  30 15:31 .
drwxrwxr-x 3 mattermost mattermost 4096 tammi  30 15:31 ..

Case 3

A useless, empty test_ directory is created:

# rm -rf /tmp/mmctl_test/
# sudo -u mattermost mkdir /tmp/mmctl_test/
# sudo -u mattermost touch /tmp/mmctl_test/test_config
# /usr/bin/sudo -u mattermost /usr/local/bin/mmctl auth login https://example.com --name example --access-token 123456890abcdefghijklmnopq --config /tmp/mmctl_test/test_config

  credentials for "example": "Personal Access Token@https://example.com" stored

# ls -lRa /tmp/mmctl_test/
/tmp/mmctl_test/:
yhteensä 24
drwxrwxr-x  3 mattermost mattermost  4096 tammi  30 15:58 .
drwxrwxrwt 22 root       root       12288 tammi  30 15:58 ..
drwx------  2 mattermost mattermost  4096 tammi  30 15:58 test_
-rw-rw-r--  1 mattermost mattermost   244 tammi  30 15:58 test_config

/tmp/mmctl_test/test_:
yhteensä 8
drwx------ 2 mattermost mattermost 4096 tammi  30 15:58 .
drwxrwxr-x 3 mattermost mattermost 4096 tammi  30 15:58 ..

Case 4

Saving the credentials again fails:

# rm -rf /tmp/mmctl_test/
# sudo -u mattermost mkdir /tmp/mmctl_test/
# sudo -u mattermost touch /tmp/mmctl_test/test
# /usr/bin/sudo -u mattermost /usr/local/bin/mmctl auth login https://example.com --name example --access-token 123456890abcdefghijklmnopq --config /tmp/mmctl_test/test
Error: mkdir /tmp/mmctl_test/test: not a directory
# ls -lRa /tmp/mmctl_test/
/tmp/mmctl_test/:
yhteensä 16
drwxrwxr-x  2 mattermost mattermost  4096 tammi  30 16:00 .
drwxrwxrwt 22 root       root       12288 tammi  30 16:00 ..
-rw-rw-r--  1 mattermost mattermost     0 tammi  30 16:00 test

Steps to reproduce

1. Log in using mmctl.

What I expect to happen

# /usr/bin/sudo -u mattermost /usr/local/bin/mmctl --quiet auth login https://example.com --name example --access-token 123456890abcdefghijklmnopq
# 

What happens instead

# /usr/bin/sudo -u mattermost /usr/local/bin/mmctl --quiet auth login https://example.com --name example --access-token 123456890abcdefghijklmnopq

  credentials for "example": "Personal Access Token@https://example.com" stored

# 

Potential cause

From looking at the code, output and --quiet are implemented in Printer, but auth and a few other places appear to use fmt.Printf() directly instead.

Issue

JSON files can be added to cards as attachments, but they are empty when downloaded from a card.

Server Setup Information

• Did you test in newest Wekan?: 5.90
• Did you configure root-url correctly so Wekan cards open correctly? yes
• Operating System: Ubuntu 20.04
• Deployment Method: snap
• Http frontend if any: Apache
• What webbrowser version are you using? Firefox (reproducible in Brave too)

Problem description

Reproduction Steps

1. Have a JSON file, such as the example from Wikipedia. Name it example.json.
2. Open a card in Wekan.
3. Select + from the Attachments section.
4. Select ”Computer” from the popup.
5. Select example.json.
6. With the JSON file now attached to the card, select to ”Download” it.
7. Open the downloaded JSON file.

What I expect to happen

For the downloaded file contents to match the uploaded file.

What happens instead

The file is empty.

Logs

Nothing in either the browser console nor snap logs when the issue is triggered.

Other info

• Deleting the attachment seems to work.
• The issue can be worked around by renaming the JSON file prior to uploading to have a .txt extension instead of (or in addition to) .json.

Also: #19974

I think my HA is also affected by this. I haven’t done any firewall snooping and I’m not using pFsense, but I also have a timer based on Kodi’s ”turn_off” event, and the symptom of repeated ”turn_off” events match. The workaround from @ChopperRob above also seems to work.

(Probably unrelated, but I’ve also noticed that my ”turn display on when Kodi becomes idle” stops working when my LAN/WLAN gets very congested (such as when doing backups over the network). I’m using ”idle” because the log never shows a ”turn_on” event from Kodi; just ”idle”, ”playing” and the intermittently incessant ”turn_off” events.)

I applied the patch on top of current head, built a deb, installed it (replacing the 4.4.0 release), and can confirm that the patch fixes the issue: the snapshots produced are now in the correct resolution (1920×1080) and look as they should (no glitching).

0. Reviewed guide and contributing documents? Yes
1. version 4.4.0
2. installed as a package or compiled from sources: deb
3. standalone or part of third party: standalone
4. video stream source: net cam
5. hardware: x86 (amd64)
6. operating system: Ubuntu 20.04

Short description

In Motion 4.4.0, using recommended values of width and height results in broken snapshots, when netcam_high_url is used. Either the warning about using a different resolution is incorrect, or the creation of snapshots breaks when width and height are set so as to not cause a warning on startup.

Background

I have a 1080p camera (a TP-Link Tapo C100) with a 360p substream, so I’ve specied both URLs as follows:

netcam_url "rtsp://192.168.1.206/stream2"                                        
netcam_high_url "rtsp://192.168.1.206/stream1"

I’ve set up snapshots to occur with snapshot_interval = 60.

If I set width and height based on the main stream (1920×1080), Motion starts up with a warning:

netcam_rtsp_ntc: The network camera is sending pictures in a different
netcam_rtsp_ntc: size than specified in the configuration file.
netcam_rtsp_ntc: The picture is being transcoded into the size 
netcam_rtsp_ntc: requested in the configuration.  If possible change
netcam_rtsp_ntc: netcam or configuration to indicate the same size
netcam_rtsp_ntc: to possibly lower CPU usage.
netcam_rtsp_ntc: Netcam: 640 x 360 => Config: 1920 x 1080

This implies I should set width and height based on the lower resolution stream, so I’ve done that, and the warning goes away.

With Motion 4.3.2, the snapshots were saved as I would expect, albeit of course now in the lower resolution (360p), whereas I’d prefer them in the full 1080p.

After upgrading to 4.4.0, the snapshots are still 360p, but now their content is garbled and green:

I haven’t looked at the code, but what this looks like to me is as if Motion is now using the high resolution URL for the image data, but the lower resolution dimensions, and the resulting file is a (broken) crop of the full resolution image. Indeed, if I set width and height based on the full stream (i.e. back to 1920×1080), the snapshots now appear the full resolution and without corruption.

Pictures from detected motion (picture_output) do not appear to be affected, i.e. they are saved in the correct 1080p resolution and look fine, regardless of the values of width and height. Video output likewise appears in the higher resolution, as I would expect.

Here’s a minimal configuration that reproduces this issue for me, minus netcam_userpass.

log_level 8

target_dir "/home/jani/tmp"

netcam_url "rtsp://192.168.1.206/stream2"
netcam_high_url "rtsp://192.168.1.206/stream1"

netcam_params rtsp_transport=tcp
netcam_high_params rtsp_transport=tcp

width 640
height 360

snapshot_interval 10

Summary

Release v1.47.2 was mentioned in another issue’s comments, and Play Store version has indeed been updated, but that release is missing from Github releases.

Steps to reproduce

Open Github releases page for the project.

Expected behavior

Find release v.1.47.2 (or later).

Observed behavior (that appears unintentional)

The current latest release on Github is 1.47.0.

Possible fixes

I don’t know if it’s related, but v.1.47.0 has been tagged ”changeme” instead of the usual vX.Y.Z pattern.

All right, I got curious enough try again, and found that this is apparently caused by the static build of ffmpeg that I’m using: I used yle-dl --verbose again, then interrupted the download immediately, ran the ffmpeg command (as reported by yle-dl) directly, and this resulted in a segmentation fault.

I then tried the same command in a VM with ffmpeg from Ubuntu repositories, and there the download finished successfully.

So the only remaining issue with yle-dl in this is the terminal being broken: that did not occur with directly-run ffmpeg despite the segfault.

I’m closing this issue though, so that it remains as documentation for the problem (and cause) as originally reported.