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 assume you’ve tried basic elimination, by testing with different parts & peripherals removed?

It’s a hassle of course, especially after you’ve already settled in to using the system, not to mention how tedious it is to run memtest for days on end just to achieve sufficient confidence that you’ve proved a negative.

I’m not as hardcore about this as Jeff Atwood, but I’ve learned not to discount anything as potentially being the cause or at least a trigger for all kinds of issues. Besides obvious things like RAM modules, OTOH I’ve had at least one internal memory card reader, one USB bluetooth dongle and one (SATA) SSD turn out to be the troublemaker; usually something much easier to replace than motherboard+almost everything. (And unfortunately it’s usually been easier to just replace or just get rid of the triggering component rather than hope for a software fix, even if the issue ultimately was with software.)

The cold lockups or the case being touch-sensitive don’t sound like one of those easily solvable ones, but since there’s a plethora of symptoms, perhaps some still might be, and are just hard to see from the mix.

Seems to be fixed in VLC 3.0.9.2-1 (Ubuntu 20.04); at least I haven’t been able to reproduce it anymore.

Same ”double free or corruption (!prev)” reproducible here too (VLC 3.0.9.2-1, Ubuntu 20.04), even more easily: the position doesn’t matter, and the first attempt to screenshot is already enough to trigger the issue.

I came across this when trying to screenshot a Superman cartoon I downloaded from Internet Archive [1].

* [1] https://archive.org/download/dom-6746superman-episode7-theundergroundworld512kb/dom-6746superman-episode7-theundergroundworld512kb.mp4

Männyn oksa kadun toiselta puolelta kasvanut niin pitkäksi, että tämä katuvalo valaisee lähinnä sen oksan kärkeä.

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

Täältä puuttuu hyllypaikkatieto, joka on tavallisin käyttötarkoitukseni Foodielle. Muutenkin tämä vaikuttaa niin vahvasti ruoan verkkokauppa edellä tehdyltä, että muut käyttötarkoitukset ovat sen takia turhan hankalia, jolleivät mahdottomia.

Malliesimerkiksi tästä ”nelikulmaista palikkaa pyöreään reikään” -vaikeudesta käy tämä yhteydenottolomake, joka ei edes tarjoa yleistä käytettävyyttä palautetyyppimuotona, vaan (Verkkokaupan palvelut, tilaukset ja tuotteet -aiheen alta) löytyy vain ”Kerääminen ja Laatu”, ”Tilaaminen” ja ”Toimitus”. En yritä enkä edes halua tehdä mitään näistä, vaan löytää vain tietoa tuotteista.

Jopa niissä perustiedoissakin näyttää olevan puutteita, josta esimerkkinä Rainbow-salaattijuustopala, jonka tuotesivulta puuttuu ravintosisältö.

Ei Foodiekaan täydellinen ole, ja ymmärrän, että tämä S-kaupat-palvelu on vielä kehitteillä, mutta nyt Foodie on alkanut tyrkyttää joka sivulatauksella popup-läpyskää, jossa mainostetaan tätä sivustoa, vaikka tämä ei vielä läheskään kykene täyttämään samoja käyttötarkoituksia.

Ja näköjään tämän lomakkeen Yhteydenottotapa-osioon on pakko vastata jotain, vaikka tyhjäksi jätetyn sähköpostikentän virheilmoitus sanoo ”Tarkista ja korjaa sähköpostiosoite tai anna palaute ilman yhteystietojasi.”

Note that when called without arguments, this yields the value of $0, which may not be what’s intended.

Summary

I’m running debsums -c daily, hoping to catch file corruption and/or other abnormalities early. (The Debian package even provides a pre-made cronjob for this task.)

debsums -c gitlab-ce reports .gitlab_kas_secret as deviating from the provided md5sum.

Steps to reproduce

1. apt install gitlab-ce
2. vi /etc/gitlab/gitlab.rb # set external URL
3. gitlab-ctl reconfigure
4. debsums -c gitlab-ce

What is the current bug behavior?

# debsums -c gitlab-ce
/opt/gitlab/embedded/service/gitlab-rails/.gitlab_kas_secret

What is the expected correct behavior?

# debsums -c gitlab-ce
#

Details of package version

ii  gitlab-ce      14.5.1-ce.0  amd64        GitLab Community Edition (including NGINX, Postgres, Redis)

Environment details

• Operating System: Ubuntu 20.04
• Installation Target, remove incorrect values:
  • VM
• Installation Type, remove incorrect values:
  • New Installation
• Is there any other software running on the machine: plenty
• Is this a single or multiple node installation? single

Configuration details

external_url 'http://localhost'

Related issues

#2635 is basically the same, but I’ve never seen debsums complain about schema.rb.

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