Viestit paikassa Github

Also: #19974

16. tammikuuta 2022 klo 20.03
Sijainti: Vianhallintajärjestelmät: Nextcloud

Also: #19974

Vastaa viestiin sen kontekstissa (Nextcloud)

I think my HA is also affected by this

16. tammikuuta 2022 klo 14.45
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Home Assistant, Kodi

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

Vastaa viestiin sen kontekstissa (Github)

I can confirm that the patch fixes the issue

19. joulukuuta 2021 klo 17.48
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Motion

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

Vastaa viestiin sen kontekstissa (Github)

4.4.0: snapshots broken when netcam_high_url used with recommended width and height values

3. joulukuuta 2021 klo 16.45
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Motion, Ubuntu

  1. Reviewed guide and contributing documents? Yes
  2. version 4.4.0
  3. installed as a package or compiled from sources: deb
  4. standalone or part of third party: standalone
  5. video stream source: net cam
  6. hardware: x86 (amd64)
  7. 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.


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://"                                        
netcam_high_url "rtsp://"

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://"
netcam_high_url "rtsp://"

netcam_params rtsp_transport=tcp
netcam_high_params rtsp_transport=tcp

width 640
height 360

snapshot_interval 10

Vastaa viestiin sen kontekstissa (Github)

New releases not published on Github

26. lokakuuta 2021 klo 11.18
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Github, Mattermost


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.

Vastaa viestiin sen kontekstissa (Github)

This is apparently caused by the static build of ffmpeg

24. syyskuuta 2021 klo 20.26
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: ffmpeg, Ubuntu

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.

Vastaa viestiin sen kontekstissa (Github)

7-hour long program not downloaded completely

21. syyskuuta 2021 klo 12.25
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: ffmpeg, Gnome, Ubuntu, Yle Areena

Trying to download this 7-hour long program only downloads (about) the first 6 hours and 40 minutes (~ 11 GB), after which the process just stops, and leaves Gnome terminal screwed up (typed characters are invisible until I run reset). In the web player the video seems to play past that point just fine.

This is on Ubuntu 20.04 with ffmpeg version N-58594-g715f63232f-static (static build from git master on 20210908).

jani@saegusa:Työpöytä$ /usr/local/bin/yle-dl ''
yle-dl 20210808: Download media files from Yle Areena and Elävä Arkisto
Copyright (C) 2009-2021 Antti Ajanki <>, license: GPLv3

Unsupported codec with id 98313 for input stream 2
Unsupported codec with id 98313 for input stream 5
Unsupported codec with id 98313 for input stream 8
Unsupported codec with id 98313 for input stream 11
Unsupported codec with id 98313 for input stream 14
Unsupported codec with id 98313 for input stream 17
Unsupported codec with id 98313 for input stream 20
Unsupported codec with id 98313 for input stream 23
Unsupported codec with id 98313 for input stream 26
Unsupported codec with id 98313 for input stream 29
Output file: YleX Esittää: Yle 95 - synttäribileet Linkkitornista: 2021-09-18T00:00.mkv
jani@saegusa:Työpöytä$  size=10814976kB time=06:39:40.68 bitrate=3694.5kbits/s speed=  44x

Note the prompt appearing on top of ffmpeg output on the last line. Typing echo $? reveals that the process exited with code 1.

Here’s the output when run with --verbose.

I’ve only tested this over the past couple of days so I don’t know if it’s a temporary error. Since the portion of the stream that I actually care about is all prior to the 6-hour mark, and the partial download is playable, I’m not too bothered to have the rest download. Reporting this just in case it’s a useful test of a corner case.

Vastaa viestiin sen kontekstissa (Github)

user_s_id translation missing, and redundant in update email template

18. heinäkuuta 2021 klo 15.53
Sijainti: Vianhallintajärjestelmät: iNaturalist
Avainsanat: Brave, Gmail, saavutettavuus

Describe the bug
The email with updates from the last 24 hours lists identifications, and mentions the name of the user having made the ID. The name is apparently supposed to be listed three times (!), but the middle occurrence is ”untranslated”, resulting in it being rendered as ”User S” for all identifications listed in the email.

Screenshot from 2021-07-18 14-58-03 (copy)

Tooltip text for the ”User S” string says ”translation missing: fi.user_s_id”, as I’m using the fi locale, but user_s_id is nowhere to be found in Crowdin, nor in current en.yml, so I suspect this is independent of the locale. The reference to user_s_id is in _update_email_activity.html.

I don’t know if this is doable, but after fixing this broken reference, I’d remove the first (header) mention of the identifier from the email altogether, since it’s followed by a listing of all the new identifiers anyway, so mentioning just the last identifier’s name in the header is redundant and confusing.

Also, rather than fixing/adding the currently broken ”User S” reference in the source, I’d remove it too, since the identifier’s name is already listed (for the third time!) right after the ID.

To Reproduce

  1. Subscibe to email updates.
  2. Have your observations identified in the last 24 hours.
  3. View the email update listing the identifications.

Observed behavior
Screenshot from 2021-07-18 15-21-05

Expected behavior
(A mockup of how the simplified view I’d prefer to receive. Sorry I didn’t have the email in English to base this on.)

Screenshot from 2021-07-18 15-21-05 (copy)

I’m using Gmail with Brave if that’s relevant.

Vastaa viestiin sen kontekstissa (iNaturalist)

I’ve now rebased and pushed the changes, hope this works for you

2. kesäkuuta 2021 klo 22.13
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: Github

@FlexW I’ve now rebased and pushed the changes, hope this works for you. I don’t see a way for me to merge this myself here, ”Only those with write access to this repository can merge pull requests.”

Vastaa viestiin sen kontekstissa (Github)

The terse explanation still seems pretty meaningless

28. toukokuuta 2021 klo 13.13
Sijainti: Vianhallintajärjestelmät: Nextcloud
Avainsanat: Ubuntu

I can add that to options.rst, but the terse explanation still seems pretty meaningless; at least for me there’s no visible difference when I run nextcloud with --background compared to running without.

This could be due to #2333 though, if running without --background is supposed to open the main dialog (which has never worked on Focal). If so, I’d mention this too, something like: ”Launch the application in the background (without opening the main dialog).”

Vastaa viestiin sen kontekstissa (Nextcloud)

« Uudempia - Vanhempia »