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

Taskilan puoleinen jalankulkuvaloboksi naksuttaa punaisen valon (hitaampaa) tahtia vaikka valot ovat vihreät. (Keskipylvään boksi ja Toppilan puoleinen boksi naksuttavat oikein.)

Ollut käytössä lähes päivittäin ostamisesta lähtien (tähän mennessä kolmisen viikkoa), ja hyvin on toiminut, eikä kulumisen merkkejä ainakaan vielä havaittavissa. Vältän tietysti pohjan raapimista metallivälineillä, ja pesen ja kuivaan pannun joka käytön jälkeen. Paistan pääasiassa kasviksia, ja lisään pohjalle paistamista varten pikkuisen öljyä, vaikka tuskin tarttuisi ilmankaan.

Tämän takia on aina kynsileikkuri avainnipussa.

Ootte ihania! (*^‿^*)

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.

Emme ole rengasvastaisia, vaan *rengaskriittisiä*.

Okay, I can appreciate avoiding extra trouble for others, and it’s certainly easier for me to add the workaround translation for just this one case. I’ve now done that (with your suggestion, which was probably as good as this can be).

%{month_name} %{year} would work better for Finnish, as that would allow the month name to be inflected apart from the year (which is how the current accepted translation of this string was intended to work). OTOH, the Finnish way a ”month name + year number” combination in inflected in most, if not all (relevant) cases is like that: add a suffix to the month name, leave the year number as-is. Without workarounds, %{month_year} generally only works for the nominative case.

”Monthly Supporter since December 2018” would be ”Kuukausittainen tukija joulukuusta 2018 lähtien”, where ”joulukuu” is the month name (and the current translation for that string doesn’t correctly account for the inflection either). Finnish has 6 different locational cases alone, so yeah, Finnish inflection can be a pain :)

I’ve only come across this title string (%{taxon} from %{place} in %{month} by %{user}) on an observation page where the date is obscured to month, whereas the (more usual case of) title for non-obscured observations has already been translated to work around the inflection. Although the latter makes for varyingly clunky Finnish, at least it’s technically not incorrect, and hence that’s how the problem is usually worked around in Finnish software translations. I can figure out a similar workaround translation for this string too (that is, take your option b).

I’m still confused by the source string here using %{month}, which then gets turned into %{month_year}, requiring translators to pay attention to the explainer text in the reference, instead of just using %{month_year} in the source directly.