gstreamer // ffmpeg

I'm using a Jetson Nano and I read that I need to use GStreamer for hardware offloading. But I cannot get the recordings to work.
The documentation states "As of now the gstreamer integration uses FFmpeg to create recordings when an object is detected and FFprobe to read stream information. Therefore, if you make changes to the recorder config you should keep in mind that it is in FFmpeg syntax."
I don't understand what I actually need to do for the recordings to work with GStreamer.
It is also not mentioned in the example config on the top of the page.
Thanks!

Sorry thought i replied to this but must've missed to publish.
You should not have to change anything in order for it to work.
The documentation is there just to hint that if you need to set some output filters on the recordings, it has to be FFmpeg commands and not GStreamer commands.
Are you having any issues or do you need to set parameters on the recording?

Well, I have trouble setting up on my Jetson Nano.
This is my docker-compose.yaml:
services:   viseron:     image: roflcoopter/jetson-nano-viseron:latest     restart: always     container_name: viseron     volumes:       - ./storage/recordings:/recordings       - ./storage/config:/config       - /etc/localtime:/etc/localtime:ro       - /tmp/argus_socket:/tmp/argus_socket     ports:       - 80:8888     runtime: nvidia     privileged: true
This is my configuration:
`gstreamer:
camera:
patscam:
name: patscam Reolink
host: <IP_ADDRESS>
port: 554
path: /Preview_01_main
username: admin
password: somepassword
recorder:
idle_timeout: 5
mog2:
motion_detector:
cameras:
patscam:
fps: 10
trigger_recorder: true
nvr:
patscam:And this is the log output:viseron  | [s6-init] making user provided files available at /var/run/s6/etc...exited 0.
viseron  | [s6-init] ensuring user provided files have correct perms...exited 0.
viseron  | [fix-attrs.d] applying ownership & permissions fixes...
viseron  | [fix-attrs.d] done.
viseron  | [cont-init.d] executing container initialization scripts...
viseron  | [cont-init.d] 10-adduser: executing...
viseron  | ************************ UID/GID *************************
viseron  | User uid:    0
viseron  | User gid:    0
viseron  | ************************** Done **************************
viseron  | [cont-init.d] 10-adduser: exited 0.
viseron  | [cont-init.d] 20-gid-video-device: executing...
viseron  | [cont-init.d] 20-gid-video-device: exited 0.
viseron  | [cont-init.d] 30-edgetpu-permission: executing...
viseron  | ************** Setting EdgeTPU permissions ***************
viseron  | Coral Vendor IDs:
viseron  | "1a6e"
viseron  | "18d1"
viseron  | No EdgeTPU USB device was found
viseron  | No EdgeTPU PCI device was found
viseron  | ************************** Done **************************
viseron  | [cont-init.d] 30-edgetpu-permission: exited 0.
viseron  | [cont-init.d] 40-set-env-vars: executing...
viseron  | ****** Checking for hardware acceleration platforms ******
viseron  | OpenCL cannot be used
viseron  | VA-API cannot be used
viseron  | CUDA is available!
viseron  | *********************** Done *****************************
viseron  | [cont-init.d] 40-set-env-vars: exited 0.
viseron  | [cont-init.d] 50-check-if-rpi: executing...
viseron  | ********** Checking if we are running on an RPi **********
viseron  | Not running on any supported RPi
viseron  | *********************** Done *****************************
viseron  | [cont-init.d] 50-check-if-rpi: exited 0.
viseron  | [cont-init.d] 55-check-if-jetson: executing...
viseron  | ****** Checking if we are running on a Jetson Board ******
viseron  | Running on a Jetson Nano
viseron  | *********************** Done *****************************
viseron  | [cont-init.d] 55-check-if-jetson: exited 0.
viseron  | [cont-init.d] 60-ffmpeg-path: executing...
viseron  | ****************** Getting FFmpeg path *******************
viseron  | FFmpeg path: /usr/bin/ffmpeg
viseron  | *********************** Done *****************************
viseron  | [cont-init.d] 60-ffmpeg-path: exited 0.
viseron  | [cont-init.d] 70-gstreamer-path: executing...
viseron  | ***************** Getting GStreamer path *****************
viseron  | GStreamer path: /usr/bin/gst-launch-1.0
viseron  | *********************** Done *****************************
viseron  | [cont-init.d] 70-gstreamer-path: exited 0.
viseron  | [cont-init.d] done.
viseron  | [services.d] starting services
viseron  | [services.d] done.
viseron  | [2024-05-07 20:35:25] [INFO    ] [viseron.core] - -------------------------------------------
viseron  | [2024-05-07 20:35:25] [INFO    ] [viseron.core] - Initializing Viseron
viseron  | [2024-05-07 20:35:25] [INFO    ] [viseron.components] - Setting up component data_stream
viseron  | [2024-05-07 20:35:25] [INFO    ] [viseron.components] - Setup of component data_stream took 0.0 seconds
viseron  | [2024-05-07 20:35:25] [INFO    ] [viseron.components] - Setting up component webserver
viseron  | [2024-05-07 20:35:25] [INFO    ] [viseron.components] - Setup of component webserver took 0.0 seconds
viseron  | [2024-05-07 20:35:25] [INFO    ] [viseron.components] - Setting up component gstreamer
viseron  | [2024-05-07 20:35:25] [INFO    ] [viseron.components] - Setting up component mog2
viseron  | [2024-05-07 20:35:25] [INFO    ] [viseron.components] - Setting up component nvr
viseron  | [2024-05-07 20:35:25] [INFO    ] [viseron.components] - Setup of component nvr took 0.0 seconds
viseron  | [2024-05-07 20:35:25] [INFO    ] [viseron.components] - Setup of component mog2 took 0.0 seconds
viseron  | [2024-05-07 20:35:25] [INFO    ] [viseron.components] - Setup of component gstreamer took 0.0 seconds
viseron  | [2024-05-07 20:35:26] [INFO    ] [viseron.components] - Setting up domain camera for component gstreamer with identifier patscam
viseron  | [2024-05-07 20:35:26] [INFO    ] [viseron.components] - Setting up domain motion_detector for component mog2 with identifier patscam
viseron  | [2024-05-07 20:35:26] [INFO    ] [viseron.components] - Setting up domain nvr for component nvr with identifier patscam
viseron  | [2024-05-07 20:35:29] [INFO    ] [viseron.components] - Setup of domain camera for component gstreamer with identifier patscam took 3.1 seconds
viseron  | [2024-05-07 20:35:29] [INFO    ] [viseron.components] - Setup of domain motion_detector for component mog2 with identifier patscam took 0.0 seconds
viseron  | [2024-05-07 20:35:29] [INFO    ] [viseron.components.nvr.nvr.patscam] - Object detector is disabled
viseron  | [2024-05-07 20:35:29] [INFO    ] [viseron.components.nvr.nvr.patscam] - NVR for camera patscam Reolink initialized
viseron  | [2024-05-07 20:35:29] [INFO    ] [viseron.components] - Setup of domain nvr for component nvr with identifier patscam took 0.0 seconds
viseron  | [2024-05-07 20:35:29] [INFO    ] [viseron.core] - Viseron initialized in 3.9 seconds
viseron  | Opening in BLOCKING MODE
viseron  | NvMMLiteOpen : Block : BlockType = 261
viseron  | NVMEDIA: Reading vendor.tegra.display-size : status: 6
viseron  | NvMMLiteBlockCreate : Block : BlockType = 261
viseron  | Stream format not found, dropping the frame
viseron  | Stream format not found, dropping the frame
viseron  | [2024-05-07 20:35:32] [INFO    ] [viseron.components.gstreamer.recorder.patscam] - Starting recorder
viseron  | [2024-05-07 20:35:33] [INFO    ] [viseron.components.nvr.nvr.patscam] - Stopping recording in: 4
viseron  | [2024-05-07 20:36:40] [ERROR   ] [viseron.components.gstreamer.camera.patscam] - Timeout waiting for frame
viseron  | [2024-05-07 20:36:50] [INFO    ] [viseron.components.gstreamer.recorder.patscam] - Stopping recorder
viseron  | [2024-05-07 20:36:55] [ERROR   ] [viseron.watchdog.thread_watchdog] - Failed to stop thread. Make sure poll_target ends the thread
viseron  | [2024-05-07 20:36:55] [ERROR   ] [viseron.watchdog.thread_watchdog] - Thread viseron.camera.patscam is dead, restarting
viseron  | [2024-05-07 20:37:02] [ERROR   ] [viseron.components.gstreamer.recorder.patscam] - Could not get duration for: /segments/patscam/20240507203531.mp4. Error: [mov,mp4,m4a,3gp,3g2,mj2 @ 0x5591c80bf0] moov atom not found
viseron  | /segments/patscam/20240507203531.mp4: Invalid data found when processing input
viseron  |
viseron  | [2024-05-07 20:37:02] [ERROR   ] [viseron.components.gstreamer.recorder.patscam] - No segments were found`

@roflcoopter is there any debug logging I could do to get this solved? Thanks

A quick google didnt yield any good results sadly.
You can enable debug logs this way:
logger:
  default_level: debug

The GStreamer command might have to be tweaked a little to work with that camera, just have to figure out what!

Ok thanks, I now have debug logging:
viseron  | [s6-init] making user provided files available at /var/run/s6/etc...exited 0.
viseron  | [s6-init] ensuring user provided files have correct perms...exited 0.
viseron  | [fix-attrs.d] applying ownership & permissions fixes...
viseron  | [fix-attrs.d] done.
viseron  | [cont-init.d] executing container initialization scripts...
viseron  | [cont-init.d] 10-adduser: executing...
viseron  | ************************ UID/GID *************************
viseron  | User uid:    0
viseron  | User gid:    0
viseron  | ************************** Done **************************
viseron  | [cont-init.d] 10-adduser: exited 0.
viseron  | [cont-init.d] 20-gid-video-device: executing...
viseron  | [cont-init.d] 20-gid-video-device: exited 0.
viseron  | [cont-init.d] 30-edgetpu-permission: executing...
viseron  | ************** Setting EdgeTPU permissions ***************
viseron  | Coral Vendor IDs:
viseron  | "1a6e"
viseron  | "18d1"
viseron  | No EdgeTPU USB device was found
viseron  | No EdgeTPU PCI device was found
viseron  | ************************** Done **************************
viseron  | [cont-init.d] 30-edgetpu-permission: exited 0.
viseron  | [cont-init.d] 40-set-env-vars: executing...
viseron  | ****** Checking for hardware acceleration platforms ******
viseron  | OpenCL cannot be used
viseron  | VA-API cannot be used
viseron  | CUDA is available!
viseron  | *********************** Done *****************************
viseron  | [cont-init.d] 40-set-env-vars: exited 0.
viseron  | [cont-init.d] 50-check-if-rpi: executing...
viseron  | ********** Checking if we are running on an RPi **********
viseron  | Not running on any supported RPi
viseron  | *********************** Done *****************************
viseron  | [cont-init.d] 50-check-if-rpi: exited 0.
viseron  | [cont-init.d] 55-check-if-jetson: executing...
viseron  | ****** Checking if we are running on a Jetson Board ******
viseron  | Running on a Jetson Nano
viseron  | *********************** Done *****************************
viseron  | [cont-init.d] 55-check-if-jetson: exited 0.
viseron  | [cont-init.d] 60-ffmpeg-path: executing...
viseron  | ****************** Getting FFmpeg path *******************
viseron  | FFmpeg path: /usr/bin/ffmpeg
viseron  | *********************** Done *****************************
viseron  | [cont-init.d] 60-ffmpeg-path: exited 0.
viseron  | [cont-init.d] 70-gstreamer-path: executing...
viseron  | ***************** Getting GStreamer path *****************
viseron  | GStreamer path: /usr/bin/gst-launch-1.0
viseron  | *********************** Done *****************************
viseron  | [cont-init.d] 70-gstreamer-path: exited 0.
viseron  | [cont-init.d] done.
viseron  | [services.d] starting services
viseron  | [services.d] done.
viseron  | [2024-05-13 13:08:08] [INFO    ] [viseron.core] - -------------------------------------------
viseron  | [2024-05-13 13:08:08] [INFO    ] [viseron.core] - Initializing Viseron
viseron  | [2024-05-13 13:08:08] [INFO    ] [viseron.components] - Setting up component logger
viseron  | [2024-05-13 13:08:08] [INFO    ] [viseron.components] - Setup of component logger took 0.0 seconds
viseron  | [2024-05-13 13:08:08] [INFO    ] [viseron.components] - Setting up component data_stream
viseron  | [2024-05-13 13:08:08] [DEBUG   ] [viseron.components.data_stream] - ulimit -u output: unlimited
viseron  | [2024-05-13 13:08:08] [DEBUG   ] [viseron.components.data_stream] - Max threads: 999999
viseron  | [2024-05-13 13:08:08] [DEBUG   ] [viseron.watchdog] - Registering <RestartableThread(data_stream, initial daemon)> in the watchdog
viseron  | [2024-05-13 13:08:08] [INFO    ] [viseron.components] - Setup of component data_stream took 0.0 seconds
viseron  | [2024-05-13 13:08:08] [INFO    ] [viseron.components] - Setting up component webserver
viseron  | [2024-05-13 13:08:08] [DEBUG   ] [asyncio] - Using selector: EpollSelector
viseron  | [2024-05-13 13:08:08] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic event/domain/registered/camera, <bound method Webserver.camera_registered of <Webserver(Tornado Webserver, initial daemon)>>
viseron  | [2024-05-13 13:08:08] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic event/domain/setup/domain_failed/camera/*, <bound method Webserver.camera_registered of <Webserver(Tornado Webserver, initial daemon)>>
viseron  | [2024-05-13 13:08:08] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic viseron/signal/shutdown, <bound method Webserver.stop of <Webserver(Tornado Webserver, initial daemon)>>
viseron  | [2024-05-13 13:08:08] [INFO    ] [viseron.components] - Setup of component webserver took 0.0 seconds
viseron  | [2024-05-13 13:08:08] [INFO    ] [viseron.components] - Setting up component mog2
viseron  | [2024-05-13 13:08:08] [INFO    ] [viseron.components] - Setting up component gstreamer
viseron  | [2024-05-13 13:08:08] [INFO    ] [viseron.components] - Setting up component nvr
viseron  | [2024-05-13 13:08:08] [INFO    ] [viseron.components] - Setup of component nvr took 0.0 seconds
viseron  | [2024-05-13 13:08:08] [INFO    ] [viseron.components] - Setup of component mog2 took 0.0 seconds
viseron  | [2024-05-13 13:08:08] [INFO    ] [viseron.components] - Setup of component gstreamer took 0.0 seconds
viseron  | [2024-05-13 13:08:09] [INFO    ] [viseron.components] - Setting up domain camera for component gstreamer with identifier patscam
viseron  | [2024-05-13 13:08:09] [INFO    ] [viseron.components] - Setting up domain motion_detector for component mog2 with identifier patscam
viseron  | [2024-05-13 13:08:09] [INFO    ] [viseron.components] - Setting up domain nvr for component nvr with identifier patscam
viseron  | [2024-05-13 13:08:09] [DEBUG   ] [viseron.components] - Domain nvr for component nvr with identifier patscam will wait for dependencies ['domain: camera, identifier: patscam']
viseron  | [2024-05-13 13:08:09] [DEBUG   ] [viseron.components] - Domain nvr for component nvr with identifier patscam will wait for optional dependencies ['domain: motion_detector, identifier: patscam']
viseron  | [2024-05-13 13:08:09] [DEBUG   ] [viseron.components] - Domain motion_detector for component mog2 with identifier patscam will wait for dependencies ['domain: camera, identifier: patscam']
viseron  | [2024-05-13 13:08:09] [DEBUG   ] [viseron.components.gstreamer.stream.patscam] - Getting stream information for rtsp://*****:*****@<IP_ADDRESS>:554/Preview_01_main
viseron  | [2024-05-13 13:08:09] [DEBUG   ] [viseron.components.ffmpeg.stream.patscam] - FFprobe command: ffprobe -hide_banner -loglevel error -print_format json -show_error -show_entries stream=codec_type,codec_name,width,height,avg_frame_rate rtsp://*****:*****@<IP_ADDRESS>:554/Preview_01_main
viseron  | [2024-05-13 13:08:09] [DEBUG   ] [viseron.components.webserver.websocket_api] - WebSocket opened
viseron  | [2024-05-13 13:08:10] [DEBUG   ] [viseron.components.webserver.websocket_api] - Received {"type":"subscribe_event","event":"domain/registered/camera","command_id":1}
viseron  | [2024-05-13 13:08:10] [DEBUG   ] [viseron.components.webserver.websocket_api] - Received {"type":"subscribe_event","event":"*/recorder/complete","command_id":2}
viseron  | [2024-05-13 13:08:10] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic event/domain/registered/camera, <function subscribe_event.<locals>.forward_event at 0x7f8ce990d0>
viseron  | [2024-05-13 13:08:10] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic event/*/recorder/complete, <function subscribe_event.<locals>.forward_event at 0x7f8ce99160>
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.gstreamer.stream.patscam] - Stream information from FFprobe: Width: 2560 Height: 1920 FPS: 20 Video Codec: h264 Audio Codec: aac
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.states] - Adding entity patscam Reolink Connected from component gstreamer
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic event/patscam/camera/status, <bound method ConnectionStatusBinarySensor.handle_event of <viseron.domains.camera.entity.binary_sensor.ConnectionStatusBinarySensor object at 0x7f8cdba100>>
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.states] - Setting state of binary_sensor.patscam_connected to state: off, attributes {'name': 'patscam Reolink Connected', 'domain': 'binary_sensor'}
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.states] - Adding entity patscam Reolink Connection from component gstreamer
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic event/patscam/camera/start, <bound method CameraConnectionToggle.handle_start_event of <viseron.domains.camera.entity.toggle.CameraConnectionToggle object at 0x7f8cdba310>>
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic event/patscam/camera/stop, <bound method CameraConnectionToggle.handle_stop_event of <viseron.domains.camera.entity.toggle.CameraConnectionToggle object at 0x7f8cdba310>>
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic event/patscam/camera/started, <bound method CameraConnectionToggle.handle_started_stopped_event of <viseron.domains.camera.entity.toggle.CameraConnectionToggle object at 0x7f8cdba310>>
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic event/patscam/camera/stopped, <bound method CameraConnectionToggle.handle_started_stopped_event of <viseron.domains.camera.entity.toggle.CameraConnectionToggle object at 0x7f8cdba310>>
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.states] - Setting state of toggle.patscam_connection to state: off, attributes {'name': 'patscam Reolink Connection', 'domain': 'toggle'}
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.states] - Adding entity patscam Reolink Access Token from component gstreamer
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.states] - Setting state of sensor.patscam_access_token to state: 66e1643fed003b96d63532aa44ff3c0c4722bb32cd4d60e03d867dfea4b4b279a83e977767e53a7a8d655ae7ba2773a973713cd0c8eca039ad99cd93fea01c46, attributes {'name': 'patscam Reolink Access Token', 'domain': 'sensor'}
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.states] - Setting state of sensor.patscam_access_token to state: 49fbfd9161255d6a418cf66e86416f5d2b25e39f9ddb6ca05560ee95f95a7cb2a2b0880d0ee97536628f768182caec5da61c956a95441a17b50605e9f5e35714, attributes {'name': 'patscam Reolink Access Token', 'domain': 'sensor'}
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.helpers] - Creating folder /recordings/patscam
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.gstreamer.recorder.patscam] - Running cleanup
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.states] - Adding entity patscam Reolink Recorder from component gstreamer
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic event/patscam/recorder/start, <bound method RecorderBinarySensor.handle_start_event of <viseron.domains.camera.entity.binary_sensor.RecorderBinarySensor object at 0x7f8cd51400>>
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic event/patscam/recorder/stop, <bound method RecorderBinarySensor.handle_stop_event of <viseron.domains.camera.entity.binary_sensor.RecorderBinarySensor object at 0x7f8cd51400>>
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.states] - Setting state of binary_sensor.patscam_recorder to state: off, attributes {'name': 'patscam Reolink Recorder', 'domain': 'binary_sensor'}
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.states] - Adding entity patscam Reolink Latest Thumbnail from component gstreamer
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic event/patscam/recorder/start, <bound method ThumbnailImage.handle_event of <viseron.domains.camera.entity.image.ThumbnailImage object at 0x7f8cd51730>>
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.states] - Setting state of image.patscam_latest_thumbnail to state: unknown, attributes {'name': 'patscam Reolink Latest Thumbnail', 'domain': 'image', 'start_time': None, 'path': None, 'thumbnail_path': None}
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.gstreamer.recorder.patscam] - Initializing gstreamer recorder
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.helpers] - Creating folder /segments/patscam
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic viseron/signal/shutdown, <bound method SegmentCleanup.shutdown of <viseron.components.ffmpeg.segments.SegmentCleanup object at 0x7f8cd51490>>
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.gstreamer.camera.patscam] - Initializing camera patscam Reolink
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.gstreamer.camera.patscam] - Resolution: 2560x1920 @ 20 FPS
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.gstreamer.camera.patscam] - Camera patscam Reolink initialized
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.core] - Registering domain camera with identifier patscam
viseron  | [2024-05-13 13:08:12] [INFO    ] [viseron.components] - Setup of domain camera for component gstreamer with identifier patscam took 3.2 seconds
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.states] - Adding entity patscam Reolink Motion Detected from component mog2
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic event/patscam/motion_detected, <bound method MotionDetectionBinarySensor.handle_event of <viseron.domains.motion_detector.binary_sensor.MotionDetectionBinarySensor object at 0x7f8cd51670>>
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.states] - Setting state of binary_sensor.patscam_motion_detected to state: off, attributes {'name': 'patscam Reolink Motion Detected', 'domain': 'binary_sensor'}
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.watchdog] - Registering <RestartableThread(patscam.motion_detection, initial daemon)> in the watchdog
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic motion_detector/patscam/scan, <queue.Queue object at 0x7f8cd59310>
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic event/patscam/nvr/motion_detector/scan, <bound method AbstractMotionDetectorScanner.handle_stop_scan of <viseron.components.mog2.motion_detector.MotionDetector object at 0x7f8cd514f0>>
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic viseron/signal/shutdown, <bound method AbstractMotionDetectorScanner.stop of <viseron.components.mog2.motion_detector.MotionDetector object at 0x7f8cd514f0>>
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.core] - Registering domain motion_detector with identifier patscam
viseron  | [2024-05-13 13:08:12] [INFO    ] [viseron.components] - Setup of domain motion_detector for component mog2 with identifier patscam took 0.0 seconds
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.nvr.nvr.patscam] - Initializing NVR for camera patscam Reolink
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic motion_detector/patscam/result, <queue.Queue object at 0x7f2bb81f40>
viseron  | [2024-05-13 13:08:12] [INFO    ] [viseron.components.nvr.nvr.patscam] - Object detector is disabled
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic patscam/camera/frame_bytes, <queue.Queue object at 0x7f8ce6be50>
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.watchdog] - Registering <RestartableThread(<viseron.components.nvr.nvr.NVR object at 0x7f5b6bcf10>, initial)> in the watchdog
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.nvr.nvr.patscam] - Waiting for first frame
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.states] - Adding entity patscam Reolink Operation State from component nvr
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic event/patscam/nvr/operation_state, <bound method OperationStateSensor.handle_event of <viseron.components.nvr.sensor.OperationStateSensor object at 0x7f8cd59b20>>
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.states] - Setting state of sensor.patscam_operation_state to state: unknown, attributes {'name': 'patscam Reolink Operation State', 'domain': 'sensor'}
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic viseron/signal/shutdown, <bound method NVR.stop of <viseron.components.nvr.nvr.NVR object at 0x7f5b6bcf10>>
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.gstreamer.camera.patscam] - Starting capture thread
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.watchdog] - Registering <RestartableThread(viseron.camera.patscam, initial daemon)> in the watchdog
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.components.gstreamer.stream.patscam] - GStreamer decoder command: rtspsrc location=rtsp://*****:*****@<IP_ADDRESS>:554/Preview_01_main name=input_stream do-timestamp=true latency=0 protocols=tcp ! rtpjitterbuffer ! rtph264depay ! tee name=depayed_stream ! queue ! nvv4l2decoder enable-max-performance=true drop-frame-interval=2 !  nvvidconv ! video/x-raw,format=(string)NV12 ! appsink sync=true max-buffers=1 drop=true name=sink emit-signals=true depayed_stream. ! queue ! h264parse ! splitmuxsink async-finalize=true send-keyframe-requests=true max-size-bytes=0 name=mux muxer=mp4mux max-size-time=5000000000 location=/segments/patscam/%01d.mp4 input_stream. ! queue ! decodebin ! audioconvert ! queue ! voaacenc ! mux.audio_0
viseron  | [2024-05-13 13:08:12] [INFO    ] [viseron.components.nvr.nvr.patscam] - NVR for camera patscam Reolink initialized
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.states] - Setting state of toggle.patscam_connection to state: on, attributes {'name': 'patscam Reolink Connection', 'domain': 'toggle'}
viseron  | [2024-05-13 13:08:12] [INFO    ] [viseron.components] - Setup of domain nvr for component nvr with identifier patscam took 0.0 seconds
viseron  | [2024-05-13 13:08:12] [INFO    ] [viseron.core] - Viseron initialized in 4.0 seconds
viseron  | [2024-05-13 13:08:12] [DEBUG   ] [viseron.watchdog] - Registering <viseron.watchdog.process_watchdog.RestartableProcess object at 0x7f8cd59d00> in the watchdog
viseron  | [2024-05-13 13:08:13] [DEBUG   ] [viseron.states] - Setting state of sensor.patscam_operation_state to state: scanning_for_motion, attributes {'name': 'patscam Reolink Operation State', 'domain': 'sensor'}
viseron  | Opening in BLOCKING MODE
viseron  | NvMMLiteOpen : Block : BlockType = 261
viseron  | NVMEDIA: Reading vendor.tegra.display-size : status: 6
viseron  | NvMMLiteBlockCreate : Block : BlockType = 261
viseron  | Stream format not found, dropping the frame
viseron  | Stream format not found, dropping the frame
viseron  | [2024-05-13 13:08:15] [DEBUG   ] [viseron.states] - Setting state of binary_sensor.patscam_connected to state: on, attributes {'name': 'patscam Reolink Connected', 'domain': 'binary_sensor'}
viseron  | [2024-05-13 13:08:15] [DEBUG   ] [viseron.components.nvr.nvr.patscam] - First frame received
viseron  | [2024-05-13 13:08:15] [DEBUG   ] [viseron.components.mog2.motion_detector.patscam] - Max motion area: 0.99334
viseron  | [2024-05-13 13:08:15] [DEBUG   ] [viseron.components.mog2.motion_detector.patscam] - Motion detected
viseron  | [2024-05-13 13:08:15] [DEBUG   ] [viseron.states] - Setting state of binary_sensor.patscam_motion_detected to state: on, attributes {'name': 'patscam Reolink Motion Detected', 'domain': 'binary_sensor'}
viseron  | [2024-05-13 13:08:15] [INFO    ] [viseron.components.gstreamer.recorder.patscam] - Starting recorder
viseron  | [2024-05-13 13:08:15] [DEBUG   ] [viseron.helpers] - Creating folder /recordings/patscam/2024-05-13
viseron  | [2024-05-13 13:08:15] [DEBUG   ] [viseron.helpers] - Creating folder /recordings/thumbnails/patscam Reolink
viseron  | [2024-05-13 13:08:15] [DEBUG   ] [viseron.components.gstreamer.recorder.patscam] - Saving thumbnail in /recordings/thumbnails/patscam Reolink
viseron  | [2024-05-13 13:08:16] [DEBUG   ] [viseron.components.gstreamer.recorder.patscam] - Pausing segment cleanup
viseron  | [2024-05-13 13:08:16] [DEBUG   ] [viseron.states] - Setting state of binary_sensor.patscam_recorder to state: on, attributes {'name': 'patscam Reolink Recorder', 'domain': 'binary_sensor', 'start_time': datetime.datetime(2024, 5, 13, 13, 8, 16, 19946), 'start_timestamp':<PHONE_NUMBER>.019946, 'end_time': None, 'end_timestamp': None, 'date': '2024-05-13', 'path': '/recordings/patscam/2024-05-13/13:08:15.mp4', 'filename': '13:08:15.mp4', 'thumbnail_path': '/recordings/patscam/2024-05-13/13:08:15.jpg', 'objects': []}
viseron  | [2024-05-13 13:08:16] [DEBUG   ] [viseron.states] - Setting state of image.patscam_latest_thumbnail to state: unknown, attributes {'name': 'patscam Reolink Latest Thumbnail', 'domain': 'image', 'start_time': '2024-05-13T13:08:16.019946', 'path': '/recordings/patscam/2024-05-13/13:08:15.mp4', 'thumbnail_path': '/recordings/patscam/2024-05-13/13:08:15.jpg'}
viseron  | [2024-05-13 13:08:16] [DEBUG   ] [viseron.states] - Setting state of sensor.patscam_operation_state to state: recording, attributes {'name': 'patscam Reolink Operation State', 'domain': 'sensor'}
viseron  | [2024-05-13 13:08:16] [DEBUG   ] [viseron.components.mog2.motion_detector.patscam] - Max motion area: 0
viseron  | [2024-05-13 13:08:16] [DEBUG   ] [viseron.components.mog2.motion_detector.patscam] - Motion stopped
viseron  | [2024-05-13 13:08:16] [DEBUG   ] [viseron.states] - Setting state of binary_sensor.patscam_motion_detected to state: off, attributes {'name': 'patscam Reolink Motion Detected', 'domain': 'binary_sensor'}
viseron  | [2024-05-13 13:08:16] [DEBUG   ] [viseron.components.mog2.motion_detector.patscam] - Max motion area: 0
viseron  | [2024-05-13 13:08:40] [DEBUG   ] [viseron.components.webserver.websocket_api] - Received {"type":"ping","command_id":3}
viseron  | [2024-05-13 13:09:10] [DEBUG   ] [viseron.components.webserver.websocket_api] - Received {"type":"ping","command_id":4}
viseron  | [2024-05-13 13:09:23] [DEBUG   ] [viseron.watchdog.thread_watchdog] - Thread viseron.camera.patscam is stuck
viseron  | [2024-05-13 13:09:23] [ERROR   ] [viseron.components.gstreamer.camera.patscam] - Timeout waiting for frame
viseron  | [2024-05-13 13:09:23] [DEBUG   ] [viseron.components.gstreamer.camera.patscam] - Stopping capture thread
viseron  | [2024-05-13 13:09:23] [DEBUG   ] [viseron.watchdog.thread_watchdog] - Stopping thread viseron.camera.patscam
viseron  | [2024-05-13 13:09:23] [DEBUG   ] [viseron.watchdog] - Removing <RestartableThread(viseron.camera.patscam, started daemon<PHONE_NUMBER>24)> from the watchdog
viseron  | [2024-05-13 13:09:28] [DEBUG   ] [viseron.components.gstreamer.camera.patscam] - Timed out trying to stop camera. Killing pipe
viseron  | [2024-05-13 13:09:28] [DEBUG   ] [viseron.components.gstreamer.stream.patscam] - Sending exit event to gstreamer_patscam
viseron  | [2024-05-13 13:09:33] [DEBUG   ] [viseron.watchdog] - Removing <viseron.watchdog.process_watchdog.RestartableProcess [2024-05-13 13:09:33] [DEBUG   ] [viseron.watchdog] - Removing <viseron.watchdog.process_watchdog.RestartableProcess object at 0x7f8cd59d00> from the watchdog, message repeated 2 times
viseron  | [2024-05-13 13:09:33] [DEBUG   ] [viseron.components.gstreamer.stream.patscam] - gstreamer_patscam exited
viseron  | [2024-05-13 13:09:33] [INFO    ] [viseron.components.gstreamer.recorder.patscam] - Stopping recorder
viseron  | [2024-05-13 13:09:33] [DEBUG   ] [viseron.states] - Setting state of toggle.patscam_connection to state: on, attributes {'name': 'patscam Reolink Connection', 'domain': 'toggle'}
viseron  | [2024-05-13 13:09:33] [DEBUG   ] [viseron.components.gstreamer.recorder.patscam] - Pausing segment cleanup
viseron  | [2024-05-13 13:09:33] [DEBUG   ] [viseron.states] - Setting state of binary_sensor.patscam_recorder to state: off, attributes {'name': 'patscam Reolink Recorder', 'domain': 'binary_sensor', 'start_time': datetime.datetime(2024, 5, 13, 13, 8, 16, 19946), 'start_timestamp':<PHONE_NUMBER>.019946, 'end_time': datetime.datetime(2024, 5, 13, 13, 9, 33, 715397), 'end_timestamp':<PHONE_NUMBER>.715397, 'date': '2024-05-13', 'path': '/recordings/patscam/2024-05-13/13:08:15.mp4', 'filename': '13:08:15.mp4', 'thumbnail_path': '/recordings/patscam/2024-05-13/13:08:15.jpg', 'objects': []}
viseron  | [2024-05-13 13:09:33] [DEBUG   ] [viseron.components.gstreamer.recorder.patscam] - Concatenating segments
viseron  | [2024-05-13 13:09:33] [DEBUG   ] [viseron.components.gstreamer.recorder.patscam] - /segments/patscam/20240513130814.mp4 is locked. Trying again in 1 second
viseron  | [2024-05-13 13:09:34] [DEBUG   ] [viseron.states] - Setting state of sensor.patscam_operation_state to state: scanning_for_motion, attributes {'name': 'patscam Reolink Operation State', 'domain': 'sensor'}
viseron  | [2024-05-13 13:09:34] [DEBUG   ] [viseron.components.gstreamer.recorder.patscam] - /segments/patscam/20240513130814.m[2024-05-13 13:09:35] [DEBUG   ] [viseron.components.gstreamer.recorder.patscam] - /segments/patscam/20240513130814.mp4 is locke[2024-05-13 13:09:36] [DEBUG   ] [viseron.components.gstreamer.recorder.patscam] - /segments/patscam/20240513130814.mp4 is locke[2024-05-13 13:09:37] [DEBUG   ] [viseron.components.gstreamer.recorder.patscam] - /segments/patscam/20240513130814.mp4 is locked. Trying again in 1 second, message repeated 4 times
viseron  | [2024-05-13 13:09:38] [ERROR   ] [viseron.watchdog.thread_watchdog] - Failed to stop thread. Make sure poll_target ends the thread
viseron  | [2024-05-13 13:09:38] [ERROR   ] [viseron.watchdog.thread_watchdog] - Thread viseron.camera.patscam is dead, restarting
viseron  | [2024-05-13 13:09:38] [DEBUG   ] [viseron.components.gstreamer.camera.patscam] - Starting capture thread
viseron  | [2024-05-13 13:09:38] [DEBUG   ] [viseron.components.gstreamer.recorder.patscam] - /segments/patscam/20240513130814.m[2024-05-13 13:09:40] [DEBUG   ] [viseron.components.gstreamer.recorder.patscam] - /segments/patscam/20240513130814.mp4 is locke[2024-05-13 13:09:41] [DEBUG   ] [viseron.components.gstreamer.recorder.patscam] - /segments/patscam/20240513130814.mp4 is locked. Trying again in 1 second, message repeated 3 times
viseron  | [2024-05-13 13:09:41] [DEBUG   ] [viseron.components.webserver.websocket_api] - Received {"type":"ping","command_id":5}
viseron  | [2024-05-13 13:09:42] [DEBUG   ] [viseron.components.gstreamer.recorder.patscam] - /segments/patscam/20240513130814.m[2024-05-13 13:09:43] [DEBUG   ] [viseron.components.gstreamer.recorder.patscam] - /segments/patscam/20240513130814.mp4 is locke[2024-05-13 13:09:44] [DEBUG   ] [viseron.components.gstreamer.recorder.patscam] - /segments/patscam/20240513130814.mp4 is locked. Trying again in 1 second, message repeated 3 times
viseron  | [2024-05-13 13:09:45] [ERROR   ] [viseron.components.gstreamer.recorder.patscam] - Could not get duration for: /segments/patscam/20240513130814.mp4. Error: [mov,mp4,m4a,3gp,3g2,mj2 @ 0x5589ee1bf0] moov atom not found
viseron  | /segments/patscam/20240513130814.mp4: Invalid data found when processing input
viseron  |
viseron  | [2024-05-13 13:09:45] [DEBUG   ] [viseron.components.gstreamer.recorder.patscam] - Segment information: {}
viseron  | [2024-05-13 13:09:45] [ERROR   ] [viseron.components.gstreamer.recorder.patscam] - No segments were found
viseron  | [2024-05-13 13:09:45] [DEBUG   ] [viseron.components.gstreamer.recorder.patscam] - Resuming segment cleanup
viseron  | [2024-05-13 13:10:11] [DEBUG   ] [viseron.components.webserver.websocket_api] - Received {"type":"ping","command_id":6}
viseron  | [2024-05-13 13:10:42] [DEBUG   ] [viseron.components.webserver.websocket_api] - Received {"type":"ping","command_id":7}
viseron  | [2024-05-13 13:11:12] [DEBUG   ] [viseron.components.webserver.websocket_api] - Received {"type":"ping","command_id":8}
viseron  | [2024-05-13 13:11:42] [DEBUG   ] [viseron.components.webserver.websocket_api] - Received {"type":"ping","command_id":9}
viseron  | [2024-05-13 13:11:59] [DEBUG   ] [viseron.components.webserver.websocket_api] - Received {"type":"subscribe_event","event":"domain/registered/camera","command_id":10}
viseron  | [2024-05-13 13:11:59] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic event/domain/registered/camera, <function subscribe_event.<locals>.forward_event at 0x7f8cd56e50>
viseron  | [2024-05-13 13:11:59] [DEBUG   ] [viseron.components.webserver.websocket_api] - Received {"type":"subscribe_event","event":"domain/setup/domain_failed/camera/*","command_id":11}
viseron  | [2024-05-13 13:11:59] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic event/domain/setup/domain_failed/camera/*, <function subscribe_event.<locals>.forward_event at 0x7f5c74d430>
viseron  | [2024-05-13 13:11:59] [DEBUG   ] [viseron.components.webserver.api.handlers] - Routing to CamerasAPIHandler.get_cameras(*args=[], **kwargs={}, request_arguments={})
viseron  | [2024-05-13 13:11:59] [DEBUG   ] [viseron.components.webserver.websocket_api] - Received {"type":"subscribe_event","event":"domain/setup/domain_loaded/camera/*","command_id":12}
viseron  | [2024-05-13 13:11:59] [DEBUG   ] [viseron.components.webserver.api.handlers] - Routing to CamerasAPIHandler.get_failed_cameras(*args=[], **kwargs={}, request_arguments={})
viseron  | [2024-05-13 13:11:59] [DEBUG   ] [viseron.components.data_stream] - Subscribing to data topic event/domain/setup/domain_loaded/camera/*, <function subscribe_event.<locals>.forward_event at 0x7f8cd09160>
viseron  | [2024-05-13 13:12:00] [DEBUG   ] [viseron.components.webserver.api.handlers] - Routing to CameraAPIHandler.get_camera(*args=[], **kwargs={'camera_identifier': 'patscam'}, request_arguments={'failed': False})
viseron  | [2024-05-13 13:12:00] [DEBUG   ] [viseron.components.webserver.api.handlers] - Routing to CameraAPIHandler.get_snapshot(*args=[], **kwargs={'camera_identifier': 'patscam'}, request_arguments={'rand': 'bkxmw', 'width': 643, 'height': None, 'access_token': *****})
viseron  | [2024-05-13 13:12:12] [DEBUG   ] [viseron.components.webserver.api.handlers] - Routing to CameraAPIHandler.get_snapshot(*args=[], **kwargs={'camera_identifier': 'patscam'}, request_arguments={'rand': 'lpmbv', 'width': 643, 'height': None, 'access_token': *****})
viseron  | [2024-05-13 13:12:12] [DEBUG   ] [viseron.components.webserver.websocket_api] - Received {"type":"ping","command_id":13}
viseron  | [2024-05-13 13:12:44] [DEBUG   ] [viseron.components.webserver.websocket_api] - Received {"type":"ping","command_id":14}
viseron  | [2024-05-13 13:13:12] [DEBUG   ] [viseron.states] - Setting state of sensor.patscam_access_token to state: 46d25cc969c2051b5fdc8abc7051d353a8093b3cdb3adc3fa3a16cd7917dfea1ccf425560c8f0d1f524b5d876754408df8d9164e128c963b0b6ba5cd967481d2, attributes {'name': 'patscam Reolink Access Token', 'domain': 'sensor'}
viseron  | [2024-05-13 13:13:14] [DEBUG   ] [viseron.components.webserver.websocket_api] - Received {"type":"ping","command_id":15}
viseron  | [2024-05-13 13:13:45] [DEBUG   ] [viseron.components.webserver.websocket_api] - Received {"type":"ping","command_id":16}
viseron  | [2024-05-13 13:14:15] [DEBUG   ] [viseron.components.webserver.websocket_api] - Received {"type":"ping","command_id":17}
viseron  | [2024-05-13 13:14:47] [DEBUG   ] [viseron.components.webserver.websocket_api] - Received {"type":"ping","command_id":18}
viseron  | [2024-05-13 13:15:17] [DEBUG   ] [viseron.components.webserver.websocket_api] - Received {"type":"ping","command_id":19}
viseron  | [2024-05-13 13:15:48] [DEBUG   ] [viseron.components.webserver.websocket_api] - Received {"type":"ping","command_id":20}
viseron  | [2024-05-13 13:16:18] [DEBUG   ] [viseron.components.webserver.websocket_api] - Received {"type":"ping","command_id":21}
viseron  | [2024-05-13 13:16:34] [DEBUG   ] [viseron.components.webserver.api.handlers] - Routing to CameraAPIHandler.get_snapshot(*args=[], **kwargs={'camera_identifier': 'patscam'}, request_arguments={'rand': 'fdtcq', 'width': 643, 'height': None, 'access_token': *****})

Nothing at all. This is a clean install. So the directory is completely empty.
$ docker exec -it viseron ls -la /segments/patscam
total 8
drwxr-xr-x 2 root root 4096 May 14 11:00 .
drwxr-xr-x 1 root root 4096 May 13 13:08 ..

Strange, you would need to play around with the raw_command and figure out a pipeline that works for your particular camera i am afraid.
Issues like these are near impossible for me to assist with since i dont have access to the same hardware

I don't have any streamer experiences. Can you please give me a starting point? Such like what is the current command now for example.....

Sure!
 Opening in BLOCKING MODE  Pipeline is live and does not need PREROLL ... Progress: (open) Opening Stream Progress: (connect) Connecting to rtsp://*****:*****@<IP_ADDRESS>:554/Preview_01_main Progress: (open) Retrieving server options Progress: (open) Retrieving media info Progress: (request) SETUP stream 0 Progress: (request) SETUP stream 1 Progress: (open) Opened Stream Setting pipeline to PLAYING ... New clock: GstSystemClock Progress: (request) Sending PLAY request Progress: (request) Sending PLAY request Progress: (request) Sent PLAY request NvMMLiteOpen : Block : BlockType = 261  NVMEDIA: Reading vendor.tegra.display-size : status: 6  NvMMLiteBlockCreate : Block : BlockType = 261  Stream format not found, dropping the frame Stream format not found, dropping the frame ERROR: from element /GstPipeline:pipeline0/GstSplitMuxSink:mux/GstMP4Mux:mp4mux0: Could not multiplex stream. Additional debug info: gstqtmux.c(4561): gst_qt_mux_add_buffer (): /GstPipeline:pipeline0/GstSplitMuxSink:mux/GstMP4Mux:mp4mux0: Buffer has no PTS. Execution ended after 0:00:03.066785194 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... root@e44be2521a09:/src#

Hmm strange. What audio and video codecs is your camera sending?
Could you try updating to 3.0.0b5 and see if that has any effect?

Input #0, rtsp, from<EMAIL_ADDRESS>  Metadata:
    title           : Session streamed by "preview"
  Duration: N/A, start: 0.000438, bitrate: N/A
    Stream #0:0: Video: h264 (High), yuv420p(progressive), 2560x1920, 20 fps, 20 tbr, 90k tbn, 40 tbc
    Stream #0:1: Audio: aac (LC), 16000 Hz, mono, fltp

Still no go. Even with 3.0.0b5.
I've attached the container log file.
3.0.0b5 viseron log.txt

Nothing obvious still :(
Can you try without audio?
Set audio_codec: null for the camera config

Tried it. Still no video in the live view, nor is it recording any events. And the message
"[ERROR   ] [viseron.watchdog.thread_watchdog] - Thread viseron.camera.patscam is dead, restarting"
I can arrange remote access using teamviewer or so.

By the way I'm running this image: https://github.com/Qengineering/Jetson-Nano-Ubuntu-20-image
Not the Nvidia Jetson image since it was an older Ubuntu version.

Hmm that could possibly be the reason why.
The container runs the official image which has 18.04, might be a conflict with some library.
Is it possible for you to backup your SD card, flash the official Jetson Nano image and try again?
If it still doesn't work we can rule that out at least
And hey, thanks for the coffees! 🎉

Sure, will try that! I'll let you know how it goes.

Too bad... Apart from the old docker version (had to use docker-dash-compose again. felt like a time traveller)
But in the end I didn't see any difference and still get [viseron.watchdog.thread_watchdog] - Thread viseron.camera.patscam is dead, restarting
Is it possible use the same gstreamer configuration in a regular vm on my ESXi host (as a test, because as performance)?

OK, I've did a test with a vm on ESXi running Centos stream 9.
And it gave me the exact same results. No video image, no recordings, the 'is dead' message and so on.
docker-compose:
services:
  viseron:
    image: roflcoopter/viseron:latest
    restart: always
    container_name: viseron
    volumes:
      - ./storage/recordings:/recordings
      - ./storage/config:/config
      - /etc/localtime:/etc/localtime:ro
    ports:
      - 80:8888
    devices:
      - /dev/dri:/dev/dri

config.yaml:
gstreamer:
  camera:
    patscam:
      name: patscam Reolink
      host: <IP_ADDRESS>
      port: 554
      path: /Preview_01_main
      username: username
      password: password
      fps: 20
      width: 2560
      height: 1920
      codec: hevc
      #audio_codec: aac
      audio_codec: null
      recorder:
        idle_timeout: 5

mog2:
  motion_detector:
    cameras:
      patscam:
        fps: 10
        trigger_recorder: true

nvr:
  patscam:

logger:
  default_level: debug

Interesting, i suspect the camera is doing something funky that GStreamer cant handle.
If you switch gstreamer with ffmpeg, does that work?

What Reolink model do you have?

It's the Reolink Doorbell PoE version. But I think I found something. Somewhere along the line I've set the codec to hevc instead of h264.
Not sure when that happened. Now doing some testing and next step will be switch to ubuntu 20 again for security patches and so.

By the way I found it when I was trying to put in a test stream of https://rtsp.stream/ . This site seems to offer nice free test streams. I couldn't find any other working rtsp streams..

OK, I've ordered a Google Coral. We can close this one.

So this was caused by some misconfiguration between your camera and Viseron?

So this was caused by some misconfiguration between your camera and Viseron?

Not really. I still couldn't get it to work. Only thing is somewhere along the line while trying and testing I messed up the codec setting. Will continue testing, but now with the Coral TPU. Thanks for the help so far!


Check for vulnerable WPAD configuration?

By default, Windows machines perform automatic proxy discovery. This makes some man-in-the-middle attacks easier, see for example: https://dirkjanm.io/worst-of-both-worlds-ntlm-relaying-and-kerberos-delegation/
The reason is because they download the settings from wpad.corp.local and other hosts without any sort of verification.
Sure, there are many other ways to get a MitM position, and if every service was properly hardened (i.e. validate certs, enforce SMB signing, etc), it wouldn't matter much. But many Windows protocols by default are vulnerable. So if I wanted to harden a Windows default installation and didn't really, really need automatic proxy discovery, I'd want to disable it.
I'd like Invoke-PrivescCheck to report default WPAD settings, either as VULN LOW or INFO. What do you think? Should I submit a PR?

The original purpose of PrivescCheck was to find weaknesses that could lead to local privilege escalation. Over the time, I extended it a bit to report some configuration issues that could be leveraged for post-exploitation as well (such as dumping LSASS).
However, I don't want to transform it into an auditing tool. One could argue that you could use any poisoning attack (such as with WPAD) to coerce the machine account to authenticate to your machine and then relay it to LDAP for local privilege escalation, but that's a bit far-fetched as the actual vulnerability exploited in this scenario would be the lack of LDAP signing enforcement.
So, to answer your question. I don't think that adding such configuration check to PrivescCheck would make sense. FOr your information, when I assess the hardening level of a Windows machine, I use a script specifically made for that purpose (see https://github.com/scipag/HardeningKitty for instance).

That makes sense. I can live with simply using HardeningKitty. I'll give it a shot, thanks for the hint!


"Permission denied, wrong credentials"

I have just created a new account and I tried to use the API directly in the HTTP browser as a test but I am getting this error message:
{"errors":["Permission denied, wrong credentials"],"message":"error"}
URL used:
<EMAIL_ADDRESS>api_user = username to log into the account
api_key = password to log into the account
Should I be using different credentials for api_user & api_key?

Hello @vintrix9935,
We're sorry you're having this issue! Since this is not a docs-related issue, please contact our Support team directly and they can help you out. It also looks like you're using the older version of our API. We recommend using our v3 API instead. You can access support contact options by logging into https://support.sendgrid.com.
SendGrid Docs Team


[Fonts] Icon request: route

This icon will enhance the UX  by logically connecting route creation in routing/navigation apps.

Hi @just1dias, this icon is already available on stable. See https://api.flutter.dev/flutter/material/Icons/route-constant.html
Closing as the icon already exists.


canReuse is ignored, view always destroyed on transition

Vue.js & vue-router.js version
1.0.17, 0.7.11
Reproduction Link
https://jsfiddle.net/avgp/bfe4tc92/
Steps to reproduce

Go to one of the routes (say "/foo")
Transition to another route (say "/bar")
Go back to the first route

What is Expected?
The following things should happen upon transition between routes:

canReuse should be called on the transition.from component
deactivate should be called on the transition.from component
destroy should not be called on the component, if canReuse returned true

What is actually happening?

canReuse is not called
deactivate is called
destroy is called, no matter what

This might be somewhat related to #403

Nevermind, re-reading the docs carefully shows I'm wrong about how canReuse works, sorry!

Where you able to use ? I'm trying to figure out how I can make specific routes keep-alive and others not.

Your issue in #403 is not resolved, I can't get some routes to keep-alive vs. others to not keep-alive, because there's nothing to hook into... so your last comment with toggling the router behaviour seems the way to go.

Ye it's definitely not though... lol Totally broke everything.
Here's how I achieved it:
		'/map': {
			component: require( './routes/map/map-comp.vue' ),
			name: 'map.index',
			map: true
		},

		'/contacts-index': {
			component: require( './routes/contacts/contacts/contacts.vue' ),
			name: 'contacts.index'
		},

		'/activities': {
			component: require( './routes/activities/activities-comp.vue' ),
			name: 'activities.index'
		},

		'/static': {
			component: require( './routes/static/static-comp.vue' ),
			subRoutes: {

				'/public': {
					component: require( './routes/public/public-comp.vue' ),
					subRoutes: {
						'/login': {
							component: require( './routes/public/login/login.vue' ),
							name: 'public.login'
						},
						'/about': {
							component: require( './routes/public/about/about.vue' ),
							name: 'public.about'
						},
						'/register': {
							component: require( './routes/public/register/register.vue' ),
							name: 'public.register'
						},
						'/recovery': {
							component: require( './routes/public/recovery/recovery.vue' ),
							name: 'public.recovery'
						}
					}
				},

The root router-view has keep-alive and the static-comp.vue does not.


Add std.experimental.allocator files to win32.mak.

Re-creating the PR because I got latest, found typed.d was removed, fixed win32.mak, and subsequently messed up the merge of the PR.

This has my stuff too. What I think you need to do is run git rebase -i HEAD~100 and then delete everything that's not your particular commit. Then commit and push to your branch. Thanks!

Got latest and rebased the PR.  Also updated the commit for the recent module reorg (e.g. building_blocks in 2295fbee).

thx!


If t0 is down, the show route command will panic.

If the specified t0 is down, a panic occurs.
Should display appropriate message, not panic.
$ nsxctl show routes T0-A
panic: interface conversion: interface {} is nil, not []interface {}

goroutine 1 [running]:
github.com/hichtakk/nsxctl/client.(*NsxtClient).GetRoutingTable(0x7a13fd8?, {0x7ffeefbffc13?, 0x1d00f18?})
	/Users/myoichi/Desktop/nsxctl/client/gateway.go:175 +0x28d
github.com/hichtakk/nsxctl/cmd.NewCmdShowRoutingTable.func1(0xc0001bdb80?, {0xc00005fb50, 0x1, 0x1?})
	/Users/myoichi/Desktop/nsxctl/cmd/nsxt-gateway.go:108 +0xa5
github.com/spf13/cobra.(*Command).execute(0xc0001bdb80, {0xc00005fb30, 0x1, 0x1})
	/Users/myoichi/go/pkg/mod/github.com/spf13/cobra@v1.2.1/command.go:860 +0x663
github.com/spf13/cobra.(*Command).ExecuteC(0xc000137680)
	/Users/myoichi/go/pkg/mod/github.com/spf13/cobra@v1.2.1/command.go:974 +0x3b4
github.com/spf13/cobra.(*Command).Execute(...)
	/Users/myoichi/go/pkg/mod/github.com/spf13/cobra@v1.2.1/command.go:902
main.main()
	/Users/myoichi/Desktop/nsxctl/main.go:9 +0x25
$

This was my mistake.
It panics when specifying an invalid Tier-0 name, not when Tier-0 is stopped.
This can occur even when auto-completion is used because the tier-0 name and Id do not match if the tier-0 name is changed after the tier-0 is created.


Document force_draw must be called from main thread

Closes #79190

Is documentation enough to solve #79190, which is a crash? Can we add some thread guards like we have in Node methods, or there's no access to that info from servers? CC @RandomShaper

I believe we should add a thread guard, should I add it to this pr or make another one ?

I think adding a thread guard in this PR too would make sense.
I see examples of it being done this way outside of Nodes (which have their own ERR_MAIN_THREAD_GUARD):
modules/navigation/godot_navigation_server_2d.cpp
186:    ERR_FAIL_COND_MSG(!Thread::is_main_thread(), "The SceneTree can only be parsed on the main thread. Call this function from the main thread or use call_deferred().");

Adding an error message like this would also make sense here, it could be something like:
ERR_FAIL_COND_MSG(!Thread::is_main_thread(), "Manually triggering the draw step from the RenderingServer can only be done on the main thread. Call this function from the main thread or use call_deferred().");

I agree with @akien-mga's remarks, but I'd still need clarity on something. Is the compatibility renderer able to run on a thread (rendering/driver/threads/thread_model == RENDER_SEPARATE_THREAD (2))? In that case, it'd still be possible to call any function on any thread. In that case, I'd rather put the thread guards at the Rasterizer*GLES3 level. (For RenderingDevice renderers, the location would be in each RenderingDevice* implementation's function. After the split to RD-RDD happens, threading will be improved with guards, among other things, and I think my points here align with that plan.)

If the situation is more complex than it seemed initially, and this might partially be overridden by the RenderingDeviceDriver work, we might want to stick to just adding a note in the docs as done here for 4.2.

Well, then let's just follow @akien-mga's idea, until everything can be addressed better.

Just in case there's a performance impact, I'm deferring this to merge after the 4.2 release, and we can cherry-pick for 4.2.x if we confirm it's a safe approach.

Cherry-picked for 4.2.2.


Update API Priority and Fairness doc for graduation to beta

Update the doc page to mention the v1beta1 API group in addition to, and in preference to, the v1alpha.  Update the example to use the v1beta1 API group.

@lavalamp
@deads2k
@yue9944882
@adtac
@tkashem
@ahg-g
@MikeSpreitzer

/milestone 1.20
/assign @reylejano-rxm
/sig api-machinery
/hold for k/k PR 90541 and k/k PR 91389
/cc @annajung

This is not dependent on k/k PRs 90541 and 91389

@reylejano-rxm : This is not dependent on k/k PRs 90541 and 91389

I updated the related k/k PR dependency

/lgtm cancel

@MikeSpreitzer , since this feature is graduating to beta, does it need to be updated in the Feature Gates list

Ah, yes, the FeatureGates list needs to be updated too.

/lgtm

/assign @sftim
PTAL, thanks!

Maybe Tim might have other feedback, but this /lgtm

still waiting on k/k pr before approving

/lgtm

looks like correct k/k pr for this is https://github.com/kubernetes/kubernetes/pull/96527

Oh yes, we had to switch to a different k/k PR because the original author is sleeping now.

Note:
Exception filed (pending approval)

@sftim : I took your suggestion, and naturally lost your LGTM for my trouble.
The PR for which we are holding has still not landed yet but it is very close and we have filed for an exception.  I expect it to merge today or tomorrow.

/lgtm
Markdown makes sense, technical changes here are minor.
Only minor changes since https://github.com/kubernetes/website/pull/24975#pullrequestreview-529839994
BTW - this repo does preserve LGTM through squashes

/label tide/method-merge-squash

/label tide/merge-method-squash

/approve

/hold cancel


Add ISM to 2.3.0

Signed-off-by: Sayali Gaikawad<EMAIL_ADDRESS>Description
Add ISM to 2.3.0 both front and back end
Issues Resolved
List any issues this PR will resolve, e.g. Closes [...].
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #2594 (96304fa) into main (dbe41c2) will increase coverage by 5.58%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##               main     #2594      +/-   ##
=============================================
+ Coverage     94.41%   100.00%   +5.58%
=============================================
  Files           219         6     -213
  Lines          4462       105    -4357
  Branches         29        19      -10
=============================================
- Hits           4213       105    -4108
+ Misses          243         0     -243
+ Partials          6         0       -6

Impacted Files
Coverage Δ

...workflow/integ_test/integ_test_start_properties.py

src/paths/script_finder.py

src/system/process.py

...ests/jenkins/jobs/AssembleManifest_tar_Jenkinsfile

...est_workflow/perf_test/perf_single_node_cluster.py

src/test_workflow/integ_test/integ_test_suite.py

src/run_checkout.py

tests/jenkins/jobs/PromoteYumRepos_Jenkinsfile

src/ci_workflow/ci_check_manifest_component.py

src/manifests/manifest.py

... and 203 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Unbreak webhook config

Self-approving as this is pretty straightforward.
/lgtm

Or not, as the case may be :)
/assign @tashimi

/assign @srampal

/lgtm
/approve


Container does not start as expected (HTTP ERROR 404)

Describe the bug
I expected a web UI after the container start.
To Reproduce
Steps to reproduce the behavior:

docker pull xetusoss/archiva
docker run --name archiva -p 8080:8080 xetusoss/archiva
See error in browser:

HTTP ERROR 404
Problem accessing /auth/. Reason:
Not Found
Powered by Jetty://
Environment Details
Docker Version: 19.03.8
Host OS: Ubuntu 20.04.1 LTS

:wave: @Krysztokowski
From the error you included, it seems you're trying to reach an invalid path /auth. The fact that you're getting a 404 error indicates that the container is started, so I don't think there is any problem here.
Why don't you try to load http://localhost:8080 and see what happens.

Got it - well.. I tried to load  with chrome but I got a redirect to . I tried it in incognito mode again and it worked. Looks like my browser cache creates trouble (had an keycloak instance on port 8080 before). Now it works fine, thanks! (=


@see {Class.prototype.member}

Make sure these boxes are checked before submitting your issue - thank you!
(If your issue is neither a both bug nor a request, please write in a free style)

[x] https://esdoc.org/manual/usage/feature.html
[x] https://esdoc.org/manual/configuration/config.html
[x] https://esdoc.org/manual/usage/tags.html
[x] https://esdoc.org/manual/advanced/api.html
[x] https://esdoc.org/manual/faq/faq.html

Short summary of your issue
ESDoc @see tag currently accepts URL values only.
I would like ESDoc @see tags to also support an additional alternative value that generates links between documented class properties and methods, including those on other pages. Take this hypothetical case for for example:
/**
 * @class {Receiver}
 * @see {Sender}
 */
class Receiver {
    /**
     * @param {Sender} sender
     * @constructor
     * @see {Receiver.prototype.registerSender}
     */
    constructor (sender) {
        this.setSender(sender)
    }

    /**
     * @param {Sender} sender
     * @return {void}
     * @throws {SenderAlreadyRegisteredException}
     * @see {Sender.prototype.registerReceiver}
     */
    registerSender (sender) {
        // impl
    }
}

/**
 * @class {Sender}
 * @see {Receiver}
 */
class Sender {

    /**
     * Set this Senders Receiver.
     *
     * @param {Receiver} receiver
     * @return {void}
     * @throws {ReceiverAlreadyRegisteredException}
     * @see {Receiver.prototype.registerSender}
     */
    registerReceiver (receiver) {
        // impl
    }
}

If this alternative @see syntax was supported, or something similar, then it would be possible to click between class fields and methods in the documentation which would also quickly communicate class and member relationships between pages of documentation.
In the above hypothetical example, ESDoc would output documentation pages which would include inline hyperlinks to the Sender class documentation page (from the Reciever class documentation page), the Receiver class documentation page (from the Sender documentation page), as well as hyperlinks from the Sender registerReceiver method from the Receiver registerSender section , and the Receiver registerSender method from the documentation for Sender registerReciever.
I did note that it is possible to create ESDoc plugins and am considering investigating this after my current project finishes up in a few weeks, but I would suggest that an official standard supported by ESDoc would be very beneficial.
I did attempt providing # tag references to @see tags to point links to alternative parts of the documentation (e.g. @see #instance-method-METHODNAME) but this broke the linking system currently in place.
I propose an @see syntax such as this to start:
@see QUALIFIED_MEMBER_PATH where QUALFIED_MEMBER_PATH could be in the form of @see Class.prototype.member which would cause ESDoc to generate a link pointing to a prototypal member, or @see Class.member would cause ESDoc to generate a link pointing to a static member as listed on the same page, or on a related page in the documentation.
If this proposal were accepted, then it could perhaps later support an advanced syntax which would throw errors if the member pointed to by the @see tag does not exist, or is documented incorrectly.
For example, using the hypothetical Sender and Receiver classes above, if one were to omit the documented parameter type listed in a documented method, ESDoc would throw an error and point this out accurately.
For example, this incorrectly formatted @see tag documents a method as accepting a NotASender type as opposed to a Sender type.
    class Sender {
        //...

        /**
         * @see Sender.prototype.registerSender(NotASender):void
         */
        registerReceiver (receiver) {

        }
    }

ESDoc would throw an error and point out the mistake and their location. In the above hypothetical example, the implemented registerSender method is documented as having @param {Sender} which is in contradiction to @see tag documented by Reciever: NotASender
But that aside... simple first.
@see {Class.prototype.member} or @see {Class.member}, with or without curly brackets would be very helpful and provide a lot of benefits as far as I can see it from my point of view at present.
Input data for reproducing
Configuration
// write into here

Codes
// write into here

Output data
Log
error: could not process the following code.
PATH/CompositePlugin.js
10|     /**
11|      * @todo document
12|      * @param {Array<Plugin>}
13|      * @constructor
14|      * @see CompositePlugin.prototype.registerPlugin(Plugin):void
15|      */
16|     constructor (plugins = []) {

Screen shot of documentation
// attach a image into here
Exception output (if possible)
Log
// write into here

Screen shot of documentation
// attach a image into here
Your environment

OS type and version: macOS 10.12
Node.js version: 7.4.0
ESDoc version: 0.5.2

After posting, I noticed that this is more or less a duplicate of #367
The only difference between this request and that is that the subject of what qualifies as namepath may perhaps be a bit different here. However, using an existing standard such as JSDoc @link tags is probably the best approach IMO.

And one more time... perhaps I was using an outdated version earlier, but this now works:
@see @link{Class#method}
!


Don't build or include Cesium Viewer as part of release.

Fixes #3127
@pjcozzi, since you're doing the release, it's up to you if you want to take this or wait for next release.  It doesn't change the release process or anything.  Zip shrinks by ~4 megs.

Looks good, thanks.


Remove job to build rh-che6 branch

In rh-che repo we have merged rh-che6 branch in master: https://github.com/redhat-developer/rh-che/pull/676.
Along with this PR we should manually delete the job too: https://ci.centos.org/view/Devtools/job/devtools-rh-che-build-che-credentials-rh-che6

[test]


Issue 1826

@shroffk Updates to the two failing tests that make them pass.
I'm not sure if simply "accepting a wider range of results" is the correct solution though.

This is definitely not the right solution: the ErrorHandlingTest.exceptionInFunction test is still failing sometimes.

This is a temporary patch:
I did not have any luck reproducing the failure on windows or debian machines.
Need to appropriately fix these tests

Leaving this pull request open for the correct fixes for Issue 1826


Dialogs Crash iOS with OOM (Memory Leak)

Describe the bug
Since 1.6.10x, dialogs with lots of content will recompose and leak memory causing out of memory crashes on iOS.
iOS will throw didReceiveMemoryWarning then crash:

More diagnostics to follow once got a sample project for you.
Affected platforms

iOS

Versions

Libraries:

Compose Multiplatform version: 1.6.10 (or RC's)
Decompose: 3.0

Kotlin version: 1.9.23
Device (model or simulator for iOS issues): Physical iPhone (Simulators do no crash) iOS 17.4

To Reproduce
More to follow, but full screen dialogs will recompose unconditionally and crash (will try and create a reproduction project for you)
Steps to reproduce the behavior:

Open Dialog with scrollable content
Scroll Content very slowly, app will crash after it runs out of memory drawing

Expected behavior
Don't OOM and crash on iOS
Screenshots

Additional context
I thought it was related to Kotlin 2.x but downgraded and still an issue, downgraded CMP to 1.6.1 and now not crashing.
Link to trace from Profling iOS App, looks like a Skia Canvas draw leak in 1.6.10. If you stop moving it will dealloc the objects, but scrolling slowly will not release quick enough.
https://drive.google.com/drive/folders/1UUPOyAWaeg7uTKaXc5EMCp-03jSy4hrk?usp=sharing

Hello!
I'll notify the team about that, however, a small reproducible example would really help.

Yeah we're working on deploying a hot fix to users once that's done I'll create a sample for y'all

Added Trace, easy to reproduce, any dialog with scrollable content, scroll SLOWLY and you'll eventually run out of memory

Unfortunately, I wasn't able to successfully reproduce this crash. Memory usage on a small project from template was about 70 mb and didn't increase no matter how I scrolled.
Could you please make a reproducible example?

Unfortunately, I wasn't able to successfully reproduce this crash. Memory usage on a small project from template was about 70 mb and didn't increase no matter how I scrolled. Could you please make a reproducible example?

Dang, OK, will try and create a sample project. Sorry about that

Unfortunately, I wasn't able to successfully reproduce this crash. Memory usage on a small project from template was about 70 mb and didn't increase no matter how I scrolled. Could you please make a reproducible example?

Oh just checking this ONLY happens on a physical device, simulators are fine (faster/more ram from host machine)

As requested:
DialogCrash.zip
I should have noted it was BasicAlertDialogs from the m3 lib

Nvm mind, I tested on the foundation Dialog and the same thing, guessing it's an underlying skia issue from what I can tell.

@chrisjenx many thanks!
I haven't reproduced the crash, but the memory warning was received many times, and memory consumption is very weird. We'll look at it

Oh good, maybe a placebo, but 1.6.10 doesn't feel as smooth as 1.6.0 potentially related if it's over drawing, leaking, etc

@mazunin-v-jb I will give 1.6.11 ago, I'm wondering if this was the cause of the OOM https://github.com/JetBrains/compose-multiplatform-core/pull/1355

Tested 1.6.11, still crashing for me. Looks like it's something else :(

Initial testing, looks like https://github.com/JetBrains/compose-multiplatform-core/pull/1390 fixed it, just running profiling now.

So far looks like peak memory usage is 90mb on the demo project, no more OOM crashes, still churning memory but at least not exploding.
Will test on my main project then close if doesn't crash there.

Looks like this is resolved

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


Increase timeout configuration for Cassandra in the CI

In the following PR, the CI failed several times with the timeout error in the step of waiting for Cassandra starts.
https://github.com/scalar-labs/helm-charts/pull/142
I re-run it several times and finally it succeeded, but I think it is better to increase the timeout configuration.
So, I updated the timeout configuration from 60s to 120s.
Please take a look!

In the CI of this PR, it succeeded the first time. The timeout error didn't occur.


Wrap all tokio::io::AsyncWrite types to a specific type which is implemented AsyncFileWriter

In current, parquet defines all AsyncWrite implement AsyncFileWriter:
impl<T: AsyncWrite + Unpin + Send> AsyncFileWriter for T {
    ... ...
}

which would in conflict with:
impl<T: AsyncFileWriter + ?Sized + Unpin + Send> AsyncFileWriter for &mut T {
    ... ...
}

this definition is not included right now, however, it should be helpful in more general cases, numerous of similar cases choose to implement this, such as:

tokio::io::AsyncWrite
futures::io::AsyncWrite

Describe the solution you'd like
Wrap all tokio::io::AsyncWrite into a proxy struct, then we can define &mut AsyncFileWriter implements AsyncFileWriter:
pub struct TokioFileWriter<F: AsyncWrite> {
    file: F,
}

impl<F: AsyncWrite> From<F> for TokioFileWriter {
    ... ...
}

impl<F: AsyncWrite + Unpin + Send> for TokioFileWriter {
    ... ...
}

Describe alternatives you've considered
I don't think there is an alternatives.
Additional context
This is a breaking change, but it values to be considered.

Hi, could you share the use case for &mut AsyncFileWriter?

But AsyncArrowWriter is created from AsyncFileWriter, creating an AsyncArrowWriter from &mut AsyncFileWriter is exactly what I want.
struct CustomFile {
    // ...
}

impl AsyncFileWriter for CustomFile {
    fn write(
        &mut self,
        bs: bytes::Bytes,
    ) -> futures::future::BoxFuture<'_, parquet::errors::Result<()>> {
        todo!()
    }

    fn complete(&mut self) -> futures::future::BoxFuture<'_, parquet::errors::Result<()>> {
        todo!()
    }
}

fn test() {
    let mut file = CustomFile {};
    {
        let mut writer =
            AsyncArrowWriter::try_new(&mut file, SchemaRef::from(Schema::empty()), None).unwrap();
        // write record batch
        writer.close()
    }
    // do something with file after writes
}

Also it is helpful to make boxed AsyncFileWriter general, compare with impl AsyncFileWriter for Box<dyn AsyncFileWriter> currently:
impl<T: AsyncFileWriter + ?Sized + Unpin + Send> AsyncFileWriter for Box<T> {
    fn write(&mut self, bs: Bytes) -> BoxFuture<'_, Result<()>> {
        self.as_mut().write(bs)
    }

    fn complete(&mut self) -> BoxFuture<'_, Result<()>> {
        self.as_mut().complete()
    }
}

// do something with file after writes

From my current understanding, you should not do anything to this file after closing it. Can you provide a detailed list of actions you plan to take?

It is my mistake, actually I just want to flush the AsyncArrowWriter, then seek and read this file as native file rather than a AsyncFileWriter, I have fixed the example code.

Understood. I believe you need AsyncArrowWriter::into_inner.

First of all, allowing users to manipulate the writer after AsyncArrowWriter has written the header and data could be error-prone.
Additionally, it doesn't make sense given our context could involve S3, Azure Blob, or GCS storage services. In these contexts, the file doesn't exist before close has been called, so you can't perform seek/read or other actions.
If you simply want to use this API in the local filesystem context, would you consider using try_clone instead?

Additionally, it doesn't make sense given our context could involve S3, Azure Blob, or GCS storage services.

It does make sense in local filesystems, which allows to implements AsyncFileWriter.

First of all, allowing users to manipulate the writer after AsyncArrowWriter has written the header and data could be error-prone

However, &mut tokio::io::AsyncWriter is a valid AsyncFileWriter in the current, if you think parquet should not allow &mut AsyncFileWriter be an AsyncFileWriter, then I think &mut tokio::io::AsyncWriter should be fixed. What ever happends, the behavior of tokio::io::AsyncWriter and non-AsyncWriter should be aligned.

It does make sense in local filesystems, which allows to be a AsyncFileWriter, don't give up eating for fear of choking.

I agree with you that it useful in the local fs context. Therefore, I propose a new API called AsyncArrowWriter::into_inner. I believe this can address your needs in a compatible manner.

Understood. I believe you need AsyncArrowWriter::into_inner.

I think into_inner has different behaviors and takes different overheads, it would move the AsyncFileWriter but &mut AsyncFileWriter is in-placed. But I think it should be nice to have AsyncArrowWriter::into_inner method.


fixes #26 scrollbar disappearing in IE after closing lightbox

@neptunian after thinking about this for a while, I wonder if we need to kill overflow at all. Do you care if the user scrolls the body behind the gallery?

Nope, the ability to scroll does not seem to detract from the user experience.

We'll find a better solution for this in the future. I'm not comfortable leaving styles in the consumer's DOM once our component has unmounted

@jossmac  good point...


OpenMP seems to be fine but ncorr doesn't recognize that

Although I have installed PCT toolbox and openmp configurations seems to be fine, as I run handles_ncorr = ncorr, I get this error:
Files compiled, but it was determined that OpenMP
is not actually supported. Please reinstall Ncorr in
single threaded mode or use a compiler which
supports OpenMP

Please see that all commands are successful.
>> mex -c standard_datatypes.cpp
Building with 'Microsoft Visual C++ 2013'.
MEX completed successfully.
>> mex -c ncorr_datatypes.cpp
Building with 'Microsoft Visual C++ 2013'.
MEX completed successfully.
>> mex -c ncorr_lib.cpp
Building with 'Microsoft Visual C++ 2013'.
MEX completed successfully.
>> mex ncorr_alg_formmask.cpp standard_datatypes.obj ncorr_datatypes.obj ncorr_lib.obj
Building with 'Microsoft Visual C++ 2013'.
MEX completed successfully.
>> mex ncorr_alg_formregions.cpp standard_datatypes.obj ncorr_datatypes.obj ncorr_lib.obj
Building with 'Microsoft Visual C++ 2013'.
MEX completed successfully.
>> mex ncorr_alg_formboundary.cpp standard_datatypes.obj ncorr_datatypes.obj ncorr_lib.obj
Building with 'Microsoft Visual C++ 2013'.
MEX completed successfully.
>> mex ncorr_alg_formthreaddiagram.cpp standard_datatypes.obj ncorr_datatypes.obj ncorr_lib.obj
Building with 'Microsoft Visual C++ 2013'.
MEX completed successfully.
>> mex ncorr_alg_formunion.cpp standard_datatypes.obj ncorr_datatypes.obj ncorr_lib.obj
Building with 'Microsoft Visual C++ 2013'.
MEX completed successfully.
>> mex ncorr_alg_extrapdata.cpp standard_datatypes.obj ncorr_datatypes.obj ncorr_lib.obj
Building with 'Microsoft Visual C++ 2013'.
MEX completed successfully.
>> mex ncorr_alg_adddisp.cpp standard_datatypes.obj ncorr_datatypes.obj ncorr_lib.obj
Building with 'Microsoft Visual C++ 2013'.
MEX completed successfully.
>> mex ncorr_alg_convert.cpp standard_datatypes.obj ncorr_datatypes.obj ncorr_lib.obj
Building with 'Microsoft Visual C++ 2013'.
MEX completed successfully.
>> mex ncorr_alg_dispgrad.cpp standard_datatypes.obj ncorr_datatypes.obj ncorr_lib.obj
Building with 'Microsoft Visual C++ 2013'.
MEX completed successfully.
>> mex ncorr_alg_testopenmp.cpp standard_datatypes.obj ncorr_datatypes.obj ncorr_lib.obj
Building with 'Microsoft Visual C++ 2013'.
MEX completed successfully.
>> mex ncorr_alg_calcseeds.cpp standard_datatypes.obj ncorr_datatypes.obj ncorr_lib.obj
Building with 'Microsoft Visual C++ 2013'.
MEX completed successfully.
>> mex ncorr_alg_rgdic.cpp standard_datatypes.obj ncorr_datatypes.obj ncorr_lib.obj
Building with 'Microsoft Visual C++ 2013'.
MEX completed successfully.
>> mex ncorr_alg_testopenmp.cpp standard_datatypes.obj ncorr_datatypes.obj ncorr_lib.obj COMFLAGS="$COMFLAGS /openmp /DNCORR_OPENMP"
Building with 'Microsoft Visual C++ 2013'.
MEX completed successfully.
>> mex ncorr_alg_calcseeds.cpp standard_datatypes.obj ncorr_datatypes.obj ncorr_lib.obj COMFLAGS="$COMFLAGS /openmp /DNCORR_OPENMP"
Building with 'Microsoft Visual C++ 2013'.
MEX completed successfully.
>> mex ncorr_alg_testopenmp.cpp standard_datatypes.obj ncorr_datatypes.obj ncorr_lib.obj COMFLAGS="$COMFLAGS /openmp /DNCORR_OPENMP"
Building with 'Microsoft Visual C++ 2013'.
MEX completed successfully.
>> type('ncorr_installinfo.txt')

1,4

lake of "#define NCORR_OPENMP",  add this to "ncorr_lib.h"


Kochi City confused with Kochi Prefecture

We found a small bug in the Japanese data. Somehow Kochi City was being provided, despite us looking only at prefectures. Was the city and prefecture confused in the data set? Noticed this about Sept 14.

Which file does Kochi City appear in as a prefecture?


closing on close

sorry for the tiny change D:
i'm not sure if this is a typo or on purpose to try to reconnect after a close message is received from twitch in the polling thread?

This won't be an issue with the latest git version, I added a measure that should of been there from the beginning, where it won't even attempt to do any of the twitch eventsub stuff if there are no twitch event specific subscriptions being subscribed too.
I also added a comment to that line you changed, because you are right, it is so it can attempt to reconnect in a later loop.


fix typo in comments

I was reading the source code, and found 1 typo(?)

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


fix #1995 to provide info of lock file owner

The key change is simply

Lock and LockAsync take operationName arg.  This will store as lock owner info along with acquired time.
Improve tracing.  When lock can't be acquired to perform operation, one will see below in kudu trace.

<step title="Lock 'C:\Kudu-Test-Files\KuduApps\TestRunnerSiteSUWATCHASUS011\site\locks\deployments.lock' is currently held by 'Set Setting' operation started at 2016-05-25T02:20:21.1647455Z." date="2016-05-25T02:20:28.986" /><!-- duration: 6ms -->

End user will also see this in 409 content.

{"Message":"The 'Set Setting' operation conflicts with the pending 'Git Receive Pack' operation started at 2016-05-25T02:18:50.0905464Z."}

Mostly small things and grammar fixes :)

merged


Implement support for TOPK.ADD (topk command)

Implement support for command TOPK.ADD in topk_mixin.py.
Increases the count of one or more items by increment.
Here is the Official documentation

Hey, I would like to work on this


Coccinelle updates of unsigned variable assignments

Here is a Coccinelle script that adds a 'U' to unsigned variable assignments according to MISRA-C rule 7.2. and issue #9895. The script can report where a 'U' is missing and also propose a patch. The report part can be run by each developer and could also be added to CI. Looking at the analysis tool, 777 instances have now shrunk down to 47, which need to be investigated still.
Patches for each directory except ./ext are attached.

Patch is awesome ! Just a comment, don't you think is better having only one commit for code changes in this case ? I mean since everything was changed using the same script, I rather prefer having one commit with the changes so if we find a problem is easier to revert.

how else would we reach 30k commit by end of the year? :-)

Patch is awesome ! Just a comment, don't you think is better having only one commit for code changes in this case ? I mean since everything was changed using the same script, I rather prefer having one commit with the changes so if we find a problem is easier to revert.

how else would we reach 30k commit by end of the year? :-)

lol, but honestly split into several commits changes caused by scripts does not scale, when we do naming changes it can easily go over 100 commits, it is insane. I think it is better one commit introducing the script and one commit with the changes, then it's easy to revert if needed.

lol, but honestly split into several commits changes caused by scripts does not scale, when we do naming changes it can easily go over 100 commits, it is insane. I think it is better one commit introducing the script and one commit with the changes, then it's easy to revert if needed.

Well, if it is split into multiple parts, it is human readable as well. People may be able to scroll to the end this way. And should someone object, only a part of the changes are shot down :-)

What about commonly used types like u8_t u_16t? I did not see them in the script.
Great job!

What about commonly used types like u8_t u_16t? I did not see them in the script.

That's what the remaining ones are lurking behind! Seems I didn't remember which unsigned definition was in use in Zephyr. I'll update.

Codecov Report

Merging #11446 into master will not change coverage.
The diff coverage is 60%.

@@           Coverage Diff           @@
##           master   #11446   +/-   ##
=======================================
  Coverage   48.37%   48.37%
=======================================
  Files         265      265
  Lines       42192    42192
  Branches    10137    10137
=======================================
  Hits        20412    20412
  Misses      17703    17703
  Partials     4077     4077

Impacted Files
Coverage Δ

misc/printk.c
88.55% <ø> (ø)
:arrow_up:

kernel/idle.c
100% <ø> (ø)
:arrow_up:

subsys/net/ip/utils.c
77.96% <0%> (ø)
:arrow_up:

subsys/net/lib/coap/coap.c
60.46% <100%> (ø)
:arrow_up:

subsys/net/ip/net_pkt.c
67.46% <100%> (ø)
:arrow_up:

subsys/net/lib/coap_sock/coap_sock.c
59.96% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 325954d...8eb934a. Read the comment docs.

Let's go with the changes that work on at least Debian's version of Coccinelle 1.0.4 and fight/fix the script later to be nicer. The updated script takes care of the uXX_t unsigned definitions.

Rebased.

Note that this script lacks depends on !(file in "ext") so running this would
produce warnings for ext/ too which I mentioned in a previous review
request to this PR.

This had some issues with coccinelle 1.0.4, let's try to get these changes in and then fix the script to saner behavior.

On Fri, 30 Nov 2018, Patrik Flykt wrote:

  Note that this script lacks depends on !(file in "ext") so
  running this would
  produce warnings for ext/ too which I mentioned in a previous
  review
  request to this PR.

This had some issues with coccinelle 1.0.4, let's try to get these changes
in and then fix the script to saner behavior.

I don't think file in is supported in 1.0.4.  I will see if the Ubuntu PPA
can be updated to 1.0.7, if that would help.
https://launchpad.net/~npalix/+archive/ubuntu/coccinelle
julia

On Fri, Nov 30, 2018 at 07:33:26PM +0000, JuliaLawall wrote:

On Fri, 30 Nov 2018, Patrik Flykt wrote:

  Note that this script lacks depends on !(file in "ext") so
  running this would
  produce warnings for ext/ too which I mentioned in a previous
  review
  request to this PR.

This had some issues with coccinelle 1.0.4, let's try to get these changes
in and then fix the script to saner behavior.

I don't think file in is supported in 1.0.4.  I will see if the Ubuntu PPA
can be updated to 1.0.7, if that would help.
https://launchpad.net/~npalix/+archive/ubuntu/coccinelle

Yes, excellent idea! Please try if possible.
I often find developers reluctant to install from source and
most of them prefer hassle free distribution packages.
At least after that I can convince more people to try it, though
majority use fedora for development.
Also, IIRC few of linux wireless folks do use the aforementioned
PPA.
--
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology

On Fri, 30 Nov 2018, Himanshu Jha wrote:

On Fri, Nov 30, 2018 at 07:33:26PM +0000, JuliaLawall wrote:

On Fri, 30 Nov 2018, Patrik Flykt wrote:

Note that this script lacks depends on !(file in "ext") so
running this would
produce warnings for ext/ too which I mentioned in a previous
review
request to this PR.
This had some issues with coccinelle 1.0.4, let's try to get these changes
in and then fix the script to saner behavior.

I don't think file in is supported in 1.0.4. I will see if the Ubuntu PPA
can be updated to 1.0.7, if that would help.
https://launchpad.net/~npalix/+archive/ubuntu/coccinelle

Yes, excellent idea! Please try if possible.

I asked, but no response so far.  Perhaps on Monday.
julia

I often find developers reluctant to install from source and
most of them prefer hassle free distribution packages.
At least after that I can convince more people to try it, though
majority use fedora for development.
Also, IIRC few of linux wireless folks do use the aforementioned
PPA.
--
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.[AAesmg0dK_5kvr9Ym8aMCi7yRTsA2i7-ks5u0Y5FgaJpZM4YmvOX.gif]

Another day, another rebase. If we could quickly push this it'd be great, else I start thinking of splitting this into several parts - as its quite large (but trivial), keeping everything without conflicts is an ever evolving game. @andrewboie @andyross ?


I am requesting you again to kindly provide your code for EFA + DFGAN. It'll be of great help if you provide it soon. Eagerly waiting for your response.

Hello, I'm really sorry that I don't have this separate code, only the code that I fused with another idea, but that is my junior brother who wants to publish a paper, and it can't be passed on for the time.


How to set a customed headers?

For example, i have done these:
return await new Promise(function(resolve, reject) {         needle.post('localhost:7001/test/remote', streamBuffer,           {             headers: {               'X-ACCESS-ID': APP_ID,               'X-ACCESS-NONCE': nonce,               'X-ACCESS-SIGNATURE': signature,             },             multipart: true,           },function(err, res) {             if (err) reject(err);             resolve(res.body);           });       });
what headers i get from reciever in console is:
{  'content-disposition': 'form-data; name="Redis"; filename="Redis"',   'content-transfer-encoding': 'binary',   'content-type': 'multipart/form-data'  }
there was no customed headers,plz giving me a guidence...

That's weird. Looks like something is messing up your headers, because 'Content-Disposition' should be part of the request's body, not the headers. What does streamBuffer look like?

It is my fault, i should print the headers of req rather than print the the stream headers of 'PassThrough' after using the 'multipart'.
Thank u~


Support for rplay.live

DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

[X] I understand that I will be blocked if I intentionally remove or skip any mandatory* field

Checklist

[X] I'm reporting a new site support request
[X] I've verified that I have updated yt-dlp to nightly or master (update instructions)
[X] I've checked that all provided URLs are playable in a browser with the same IP and same login details
[X] I've checked that none of provided URLs violate any copyrights or contain any DRM to the best of my knowledge
[X] I've searched known issues and the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue
[X] I've read about sharing account credentials and am willing to share it if required

Region
USA
Example URLs
https://rplay.live/play/64d88e33ea738d460d69831e/
https://rplay.live/play/659ed46a37f23766bdc28141/
Provide a description that is worded well enough to be understood
Another destination for exiled Korean Twitch ASMR streamers. One annoying quirk about this site is that even for free VODs you must be subscribed to the creator's "Free" tier in order to view them; this may or may not come into play.
Provide verbose output that clearly demonstrates the problem

[X] Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
[X] If using API, add 'verbose': True to YoutubeDL params instead
[X] Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output
[debug] Command-line config: ['-vU', 'https://rplay.live/play/64d88e33ea738d460d69831e/']
[debug] Encodings: locale cp1252, fs utf-8, pref cp1252, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version<EMAIL_ADDRESS>from yt-dlp/yt-dlp-nightly-builds [974d44403] (win_exe)
[debug] Python 3.8.10 (CPython AMD64 64bit) - Windows-10-10.0.19045-SP0 (OpenSSL 1.1.1k  25 Mar 2021)
[debug] exe versions: ffmpeg N-108915-g5661c8715c-20221102 (setts), ffprobe N-108915-g5661c8715c-20221102, phantomjs 2.1.1
[debug] Optional libraries: Cryptodome-3.20.0, brotli-1.1.0, certifi-2024.02.02, mutagen-1.47.0, requests-2.31.0, sqlite3-3.35.5, urllib3-2.2.0, websockets-12.0
[debug] Proxy map: {}
[debug] Request Handlers: urllib, requests, websockets
[debug] Loaded 1833 extractors
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp-nightly-builds/releases/latest
Latest version<EMAIL_ADDRESS>from yt-dlp/yt-dlp-nightly-builds
yt-dlp is up to date<EMAIL_ADDRESS>from yt-dlp/yt-dlp-nightly-builds)
[generic] Extracting URL: https://rplay.live/play/64d88e33ea738d460d69831e/
[generic] 64d88e33ea738d460d69831e: Downloading webpage
WARNING: [generic] Falling back on generic information extractor
[generic] 64d88e33ea738d460d69831e: Extracting information
[debug] Looking for embeds
ERROR: Unsupported URL: https://rplay.live/play/64d88e33ea738d460d69831e/
Traceback (most recent call last):
  File "yt_dlp\YoutubeDL.py", line 1586, in wrapper
  File "yt_dlp\YoutubeDL.py", line 1721, in __extract_info
  File "yt_dlp\extractor\common.py", line 718, in extract
  File "yt_dlp\extractor\generic.py", line 2531, in _real_extract
yt_dlp.utils.UnsupportedError: Unsupported URL: https://rplay.live/play/64d88e33ea738d460d69831e/

I was able to create a working extractor, although it is incompatible with main repo due to use of playwright to eval JS+WASM code. There might be a way to make PhantomJS work but don't feel it quite worth the efforts.
https://github.com/c-basalt/yt-dlp/tree/rplay
PS: The m3u8 of paid videos can still be accessed without membership, but the requests to AES key would get 403 denial.

Here's the code for generating the butter header using nothing but PyCryptodome, which is already yt-dlp dependency.
from Crypto.Util import Padding
from Cryptodome.Cipher import AES

def get_butter_token():
    KEY = 'S%M@#H#B(!@()a2@'
    SALT = 'QWI@(!WAS)Dj1AA(!@*DJ#@$@~1)P'
    ORIGIN = 'https://rplay.live'

    ts_value = int(time.time()) // 360
    iv = str(ts_value).zfill(16).encode()

    cleartext = f'{SALT}{ORIGIN}{ts_value}'
    cleartext_padded = Padding.pad(cleartext.encode(), 16)

    cipher = AES.new(KEY.encode(), AES.MODE_CBC, iv=iv)
    ciphertext = cipher.encrypt(cleartext_padded)
    return ciphertext.hex()

Feel free to use it, even if it's just a temporary solution to get this extractor merged into the main branch sooner.


Is core-js a dependency?

Is core-js a peer dependency? Without explicitly installing core-js in my project, starting the next app fails because of:
Error: Cannot find module 'core-js/modules/es.array.iterator'
...
 at Object.<anonymous> (xxx/node_modules/next-routes-with-locale/dist/index.js:5:1)

ha-ha, just opened same issue 1 minute ago

I am having also another error:
Cannot find module '@babel/runtime-corejs3/helpers/interopRequireDefault'

@iksent Did you install core-js 3? I also had your issue. Changing the babel setup to 3 was missing. For example in .babelrc
...
"preset-env": {
  "corejs": 3
  }
}
...

@rumtraubenuss, hello.
I did not have time to wait, and I was sure that the answer from the developer would not be given soon.
Therefore, I was forced to develop my own version of i18n subpaths.

@rumtraubenuss, hello.
I did not have time to wait, and I was sure that the answer from the developer would not be given soon.
Therefore, I was forced to develop my own version of i18n subpaths.

Hi can you share your solution ? ,i'm using react-i18next but it does not have local subpath support

I've added core-js as dependency because it is a dependency.


feat: add Manual Control

expose open,close func

Can control the popper through an external button.


types(router): added router array type for Array RouteConfig

What kind of change does this PR introduce? (check at least one)

[ ] Bugfix
[ ] Feature
[ ] Code style update
[ ] Refactor
[ ] Docs
[ ] Underlying tools
[x] Other, please describe:
Added a conditional in the generator of router when TypeScript is selected, added the routes array as <Array>, when using the @vue/composition-api using the routes without the type may return an error of incompatibility

Does this PR introduce a breaking change? (check one)

[ ] Yes
[x] No

Other information:

I'm closing this PR to make a new one with the correct changes without adding the lock files.


Reconcile Wikidata by Qualifier

I would like to reconcile Wikidata with a certain qualifier. Is it that possible, if not, could you implement it?
Exampl

Set qualifier property to North Sumatera III. or give me all people which ever had a candidacy at this district.

Hello @mshd, that is a totally valid feature request! But this feature would be implemented in the reconciliation service, not OpenRefine itself, so the correct repository for this is here: https://github.com/wetneb/openrefine-wikibase/issues/72. I am recording your use case there.

Ok appreaciate it!


Incomplete stack traceback with SOL_USING_CXX_LUA

This is a follow-up to issue #461, and I think I found why I was having an issue in the first place. I compile my own version of lua 5.3 as C++, and I use  SOL_USING_CXX_LUA. When this is turned on, the trace stack I get in case of missing arguments I get is incomplete:
runtime error caught (...) exception stack traceback: [C]: in field 'list_directory' /home/julien/Devel/dolmen/unit_test/lua/test.lua:3: in main chunk

When the define is off and I compile against my system's version of lua (which is compiled as C), I now get a proper error message indicating that an argument was missing:
sol: runtime error: /home/julien/Devel/dolmen/unit_test/lua/test.lua:3: stack index 2, expected boolean, received no value
stack traceback:
	[C]: in field 'list_directory'
	/home/julien/Devel/dolmen/unit_test/lua/test.lua:3: in main chunk

Is there any reason why lua-compiled-as-C++ doesn't behave as expected?

This is likely because we catch all exceptions using .... luaL_error communicates its errors by using a throw statement when you build with C++: likely, we're accidentally stuffing the error.
This is only a guess. I'll have to give it a spin and a try and see if I can't make something work out just a tiny bit better...

It looks like you'd need to have defined SOL_EXCEPTIONS_SAFE_PROPAGATION when using SOL_USING_CXX_LUA.
I define it for you now when you define SOL_USING_CXX_LUA, and it works out well enough:

Noted here: http://sol2.readthedocs.io/en/latest/exceptions.html#lua-and-luajit-c-exception-full-interoperability


Is the Atom text editor available as a separate package?

Hi.. I'm thinking of using Electron with the same text editor that Atom uses (I don't need the whole Atom).
Is it available as a separate package? Thank you!

No, the text editor isn't available as a separate package at this time. Thanks for the interest!

Thank you!


Don't validate grammar rules when empty

When you start typing a grammar rule
MyRule:
    ;

the editor used to show a whole bunch of validation errors, which is annoying because you know that you're in the middle of writing something. This change reduces the shown errors for the above case to just the syntax error.
I also changed the grammar AST along the way such that both ParserRule and TerminalRule have their definition in a definition property instead of alternatives and terminal.

Caveat: when you don't write the semicolon at the end, the rule is not detected as empty.
MyRule:

OtherRule: ...

Here OtherRule is parsed as it were a rule call within the definition of MyRule.