All right, thanks for responding anyway!
All right, thanks for responding anyway!
All right, thanks for responding anyway!
I’m getting a "title":"Please Wait... | Cloudflare"
and "description":"Please enable cookies."
from Resident Advisor’s podcast episode pages.
curl -sL 'https://api.microlink.io/?url=https%3A%2F%2Fra.co%2Fpodcast%2F821'
Not sure what the description should be, but og:title
is ”RA.821 Sunju Hargun ⟋ RA Podcast”, so I’d expect that for the title.
{
"status":"success",
"data":{
"title":"Please Wait... | Cloudflare",
"description":"Please enable cookies.",
"lang":"en",
"author":null,
"publisher":"Amazon",
"image":{
"url":"https://ra.co/cdn-cgi/images/trace/managed/js/transparent.gif?ray=6e6278b6dae58c30",
"type":"gif",
"duration":0.1,
"size":42,
"height":1,
"width":1,
"duration_pretty":"100ms",
"size_pretty":"42 B"
},
"date":"2022-03-03T12:45:50.000Z",
"url":"https://ra.co/podcast/821",
"logo":null
},
"statusCode":403,
"headers":{
"date":"Thu, 03 Mar 2022 12:45:50 GMT",
"content-type":"text/html; charset=UTF-8",
"cf-chl-bypass":"1",
"permissions-policy":"accelerometer=(),autoplay=(),camera=(),clipboard-read=(),clipboard-write=(),fullscreen=(),geolocation=(),gyroscope=(),hid=(),interest-cohort=(),magnetometer=(),microphone=(),payment=(),publickey-credentials-get=(),screen-wake-lock=(),serial=(),sync-xhr=(),usb=()",
"cache-control":"private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0",
"expires":"Thu, 01 Jan 1970 00:00:01 GMT",
"x-frame-options":"SAMEORIGIN",
"expect-ct":"max-age=604800, report-uri=\"https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct\"",
"set-cookie":"__cf_bm=5KE3AuPAXjTbtqg1orpJUhrCEm74SBvBFamivvHlWzk-1646311550-0-ATV5QxpiBmqa/YdWk1PqMtqR3dvdRyhnoC1vmjBc6/Vx+nDJU9je3vRWZ4TawNbqXf994S1qOAZ9v5WWtlWPCbbjskKZYXuIEV8+aaohm1vE; path=/; expires=Thu, 03-Mar-22 13:15:50 GMT; domain=.ra.co; HttpOnly; Secure; SameSite=None",
"vary":"Accept-Encoding",
"server":"cloudflare",
"cf-ray":"6e6278b6dae58c30-EWR",
"content-encoding":"gzip"
}
}
Prior to discovering microlink.io I’ve used ad hoc hacks to fetch the titles, and had similar problems with the site then; they’re probably doing stupid things at their end, so I don’t know if this is fixable.
(Also, sorry if this wasn’t the right issue tracker, as I couldn’t figure out the canonical place for issues with just using the API from the command line.)
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 $?
For a non-zero exit status to be printed.
The exit status is 0.
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).
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”).
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 ..
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 ..
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 ..
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
# /usr/bin/sudo -u mattermost /usr/local/bin/mmctl --quiet auth login https://example.com --name example --access-token 123456890abcdefghijklmnopq
#
# /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
#
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.
JSON files can be added to cards as attachments, but they are empty when downloaded from a card.
example.json
.example.json
.For the downloaded file contents to match the uploaded file.
The file is empty.
Nothing in either the browser console nor snap logs when the issue is triggered.
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).
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.
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