Doorbird hangs itself up after a few hours

[Vicelow]

I run a Doorbird camera since 2 years without problems via Scrypted and HKSV, but since 2 weeks the camera stops responding in HK after a few hours. It can be resolved through reloading the plugin in Scrypted. Is this related to the other open ticket on a similar issue or a new one? (see camera console output attached)

Just weird that it worked flawlessly for 2 years before this.

Many thanks!

5/22/2024, 6:42:31 AM
########################
[Rebroadcast Plugin]: sending prebuffer 6000
[Rebroadcast Plugin]: Unable to find sync frame in rtsp prebuffer.
[Snapshot Plugin]: Snapshot failed Error: ffmpeg input to image conversion failed with exit code: 234, /server/node_modules/@scrypted/ffmpeg-static/artifacts/ffmpeg-linux-x64 -hide_banner -err_detect aggressive -fflags discardcorrupt -y -analyzeduration 0 -probesize 500000 -reorder_queue_size 0 -rtsp_transport tcp -f rtsp -i rtsp://127.0.0.1:40526/dee70aba8814eda8/22 -frames:v 1 -f image2 pipe:3
[Snapshot Plugin]: at /src/ffmpeg-image-filter.ts:177:23
[Snapshot Plugin]: at processTicksAndRejections (node:internal/process/task_queues:95:5)
[Snapshot Plugin]: creating error image with background Snapshot Failed true
[Rebroadcast Plugin]: sending prebuffer 6000
[Rebroadcast Plugin]: Unable to find sync frame in rtsp prebuffer.
[Snapshot Plugin]: Snapshot failed Error: ffmpeg input to image conversion failed with exit code: 234, /server/node_modules/@scrypted/ffmpeg-static/artifacts/ffmpeg-linux-x64 -hide_banner -err_detect aggressive -fflags discardcorrupt -y -analyzeduration 0 -probesize 500000 -reorder_queue_size 0 -rtsp_transport tcp -f rtsp -i rtsp://127.0.0.1:44310/22269e2f4ff0bb1b/22 -frames:v 1 -f image2 pipe:3
[Snapshot Plugin]: at /src/ffmpeg-image-filter.ts:177:23
[Snapshot Plugin]: at processTicksAndRejections (node:internal/process/task_queues:95:5)
[Snapshot Plugin]: creating error image with background Snapshot Failed true
[HomeKit]: snapshot error RPCResultError: ffmpeg input to image conversion failed with exit code: 8, /server/node_modules/@scrypted/ffmpeg-static/artifacts/ffmpeg-linux-x64 -hide_banner -y -f image2pipe -i pipe:4 -filter_complex eq=brightness=-0.2[snapshotBlur] ; [snapshotBlur] gblur=sigma=25[snapshotText] ; [snapshotText] drawtext=fontfile=/server/volume/plugins/@scrypted/snapshot/zip/unzipped/fs/Lato-Bold.ttf:text='Snapshot Failed':fontcolor=white:fontsize=h/8:x=(w-text_w)/2:y=(h-text_h)/2 -frames:v 1 -f image2 pipe:3
[HomeKit]: at /src/ffmpeg-image-filter.ts:177:23
[HomeKit]: at processTicksAndRejections (node:internal/process/task_queues:95:5)
[HomeKit]: @scrypted/snapshot:host
[HomeKit]: host:@scrypted/homekit {
[HomeKit]: cause: undefined
[HomeKit]: }
[Rebroadcast Plugin]: sending prebuffer 6000
[Rebroadcast Plugin]: Unable to find sync frame in rtsp prebuffer.
[Snapshot Plugin]: Snapshot failed Error: ffmpeg input to image conversion failed with exit code: 234, /server/node_modules/@scrypted/ffmpeg-static/artifacts/ffmpeg-linux-x64 -hide_banner -err_detect aggressive -fflags discardcorrupt -y -analyzeduration 0 -probesize 500000 -reorder_queue_size 0 -rtsp_transport tcp -f rtsp -i rtsp://127.0.0.1:40420/f00f034cc83d5572/22 -frames:v 1 -f image2 pipe:3
[Snapshot Plugin]: at /src/ffmpeg-image-filter.ts:177:23
[Snapshot Plugin]: at processTicksAndRejections (node:internal/process/task_queues:95:5)
[Snapshot Plugin]: creating error image with background Snapshot Failed true
[HomeKit]: snapshot error RPCResultError: ffmpeg input to image conversion failed with exit code: 8, /server/node_modules/@scrypted/ffmpeg-static/artifacts/ffmpeg-linux-x64 -hide_banner -y -f image2pipe -i pipe:4 -filter_complex eq=brightness=-0.2[snapshotBlur] ; [snapshotBlur] gblur=sigma=25[snapshotText] ; [snapshotText] drawtext=fontfile=/server/volume/plugins/@scrypted/snapshot/zip/unzipped/fs/Lato-Bold.ttf:text='Snapshot Failed':fontcolor=white:fontsize=h/8:x=(w-text_w)/2:y=(h-text_h)/2 -frames:v 1 -f image2 pipe:3
[HomeKit]: at /src/ffmpeg-image-filter.ts:177:23
[HomeKit]: at processTicksAndRejections (node:internal/process/task_queues:95:5)
[HomeKit]: @scrypted/snapshot:host
[HomeKit]: host:@scrypted/homekit {
[HomeKit]: cause: undefined
[HomeKit]: }

[digitalentropy]

I am seeing a similar behavior and it's maddening. Were you able to find any solutions?

[Vicelow]

Additional input for whoever can interpret this :-)
When the plugin starts, it complains about a deprecated buffer method. Maybe the issue?

linux x64 #69057 SMP Fri Jan 12 17:02:28 CST 2024
server version: 0.105.0
plugin version: @scrypted/doorbird 0.0.2
full
########################
5/24/2024, 7:30:30 AM
########################
starting plugin @scrypted/doorbird
node modules /server/volume/plugins/@scrypted/doorbird/node20-linux-x64-20240321
Doorbird: Our intercomId is: ghhars
Doorbird: starting event socket listening...
plugin loaded
(node:4834) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
(Use node --trace-deprecation ... to show where the warning was created)
Doorbird: starting audio silence generator...
-hide_banner -nostats -re -f lavfi -i anullsrc=r=8000:cl=mono -f mulaw pipe:3
Input #0, lavfi, from 'anullsrc=r=8000:cl=mono':
Duration: N/A, start: 0.000000, bitrate: 64 kb/s
Stream #0:0: Audio: pcm_u8, 8000 Hz, mono, u8, 64 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (pcm_u8 (native) -> pcm_mulaw (native))
Press [q] to stop, [?] for help
Output #0, mulaw, to 'pipe:3':
Metadata:
encoder : Lavf60.16.100
Stream #0:0: Audio: pcm_mulaw, 8000 Hz, mono, s16, 64 kb/s
Metadata:
encoder : Lavc60.31.102 pcm_mulaw

Input #0, lavfi, from 'anullsrc=r=8000:cl=mono':
Duration: N/A, start: 0.000000, bitrate: 64 kb/s
Stream #0:0: Audio: pcm_u8, 8000 Hz, mono, u8, 64 kb/s
Stream mapping:
Stream #0:0 -> #0:0 (pcm_u8 (native) -> pcm_mulaw (native))
Press [q] to stop, [?] for help
Output #0, mulaw, to 'pipe:3':
Metadata:
encoder : Lavf60.16.100
Stream #0:0: Audio: pcm_mulaw, 8000 Hz, mono, s16, 64 kb/s
Metadata:
encoder : Lavc60.31.102 pcm_mulaw

[koush]

@slyoldfox I think maintains this plugin?

[slyoldfox]

@koush doorbird? no, just a bit of sip and the bticino plugin.

[stephanlinke87]

Observing the same behavior with two different doorbirds running the 142 firmware :)

[koush]

@nanosonde is the plugin developer. I think there were some rebroadcast changes a month ago but that's it.

[koush]

someone try rebroadcast version 0.10.17

[Vicelow]

someone try rebroadcast version 0.10.17

Installed it and will observe now for 1-2 days

[stephanlinke87]

Same - so far, it works since 10h :)

[Optic00]

same here, has been working for 16 hours now on 0.10.17

[Vicelow]

someone try rebroadcast version 0.10.17

Installed it and will observe now for 1-2 days

Same here, up and running now for >24h

[stephanlinke87]

Down again unfortunately :( I‘ll check the logs later and post them.

[koush]

The change in 17 was a periodic restart that was removed. I think this has always been an issue, but was just masked due to that restart.

[stephanlinke87]

Just figured that the plugin got updated to 18 via autoupdate again xD From what I can tell, it's working fine with 17 :)

[nanosonde]

Hi!
Just a quick update from my side.
The plugin always had the described issue.
If you study the doorbird API docs closely, you will read that the native doorbird apps take precedence over any API functionality.
So this might be an issue as well.
Also the plugin is missing advanced error handling code if the streams get interrupted somehow. They do not recover from such a failure.
When I was using scrypted, I have used it for just for 2-way audio Video-Doorbell in Homekit. This worked out. I also experienced the described issue, but only with active rebroadcasting plugin which consumes the doorbird streams permanently. Later I have disabled the rebroadcasting plugin, as homekit stream setup was fast enough for me without it.

It might be that the doorbird closes the stream after some fixed time as well. Also using the doorbird apps might cause this.

I am not using scrypted anymore as I have moved to frigate+HAOS and the native doorbird apps.

So sorry to say that I won‘t work on this anymore as I do not have any spare time for it.

[koush]

I am not using scrypted anymore as I have moved to frigate+HAOS and the native doorbird apps.

@nanosonde

Doesn't frigate also keep the stream open on door bird? Or are you not recording the doorbird? The easiest fix here may be to simply disable pre buffering on door bird by default, and I can do that myself. Setting the video stream metadata as a "cloud" or "battery" camera will accommodate this need.

[nanosonde]

@koush
Yes, you are right. I am using the same RTSP URL as it is used in the doorbird plugin.
go2rtc consumes the stream for very long times without any issues.
So the video streaming should not be an issue.

As far as I remember while implementing the doorbird plugin, I had an issue with audio streaming as described here:
https://www.doorbird.com/downloads/api_lan.pdf (page17, ...)

How does the doorbird plugin work in general?
It permanently received the RTSP video-only stream from the doorbird.
As resulting output for scrypted must contain video and audio at the same time, I had come with the idea that I use a silence generator that generates a silent audio stream when the scrypted intercom is inactive.
As soon as the intercom gets activated the audio input us switched from silence generator to the doorbird audio receiver. The audio receiver does not use SIP, but instead uses the HTTP as described in the LAN API PDF.

The problem I had once was that the HTTP audio receiver stopped receiving audio packets for whatever reason (mayb the issue that is decribed here?). If this happens, the ffmpeg instance does not die, but instead stops outputing the combined A+V streams although the received doorbird video stream is still fine.
In some other issue I wrote that one probably would have to write a custom HTTP doorbird audioreceiver that is more tailored for the doorbird HTTP audio RX instead of relying on the other FFMPEG instance with HTTP input. See this code: https://github.com/koush/scrypted/blob/main/plugins/doorbird/src/main.ts#L239

Maybe you could check the logs of this FFMPEG instance for HTTP audio RX to see if it is still alive and receiving/outputing audio frames.

So just to sum it up for the doorbird plugin: we have four ffmpeg instances running:

1. one for the silence generator that outputs silence on pipe:3
2. one for audio RX from doorbird via HTTP that outputs doorbird audio on pipe:3
3. one for audio TX that sends audio from scrypted to doorbird via HTTP
4. one for video RX from doorbird via RTSP (video-only) combined with audio input via TCP from plugin's internal TCP audio server that either receives data from 1) or 2)

If 2) does not receive any audio data anymore via HTTP, then 4) stops processing and does not output anything. -> No video, no audio. This is probably the issue you experience here.

Possible solution would be to add make audio RX via HTTP for 2) more robust and either restart it or just fallback to silence from silence generator.

Please note also that the doorbird API clearly states that any Doorbird APP would have priority over the API stuff.
So the described possible solution above would be required anyway if a mixed usage of Doorbird App and Doorbird API is desired.

[stephanlinke87]

Just as an fyi, it has been working for four days straight now :)

[digitalentropy]

Thank you everyone for investigating this!

As an aside, what are some of the functional differences between the ONVIF plugin and the DoorBird-specific plugin? I ended up switching to ONVIF plugin as a test and it appears to be functioning smoothly.

[nanosonde]

Thank you everyone for investigating this!

As an aside, what are some of the functional differences between the ONVIF plugin and the DoorBird-specific plugin? I ended up switching to ONVIF plugin as a test and it appears to be functioning smoothly.

The doorbird ONVIF does not support two-way audio as it does not support ONVIF profile-T with RTSP audio backchannel support.
This is the main reason why I wrote the doorbird specific plugin. I wanted to use it with Scrypted&Homekit as two-way-audio-video-doorbell.

[Vicelow]

Just as an fyi, it has been working for four days straight now :)

Same here! Up and running since I reverted to the previous version

[Vicelow]

Has the Doorbird connection also stopped working for someone else? All of a sudden, the stream is not working for me at all

[Vicelow]

[WebRTC Plugin]: signalingState have-remote-offer
[WebRTC Plugin]: signalingState stable
[WebRTC Plugin]: iceGatheringState gathering
[WebRTC Plugin]: waiting ice connected
Doorbird: timed out waiting for tcp client from ffmpeg
[WebRTC Plugin]: iceConnectionState completed
[WebRTC Plugin]: iceGatheringState complete
[WebRTC Plugin]: connectionState connecting
[WebRTC Plugin]: iceConnectionState checking
[WebRTC Plugin]: iceConnectionState connected
[WebRTC Plugin]: connectionState connected
[WebRTC Plugin]: Connection is local network: false 178.199.184.165 {
[WebRTC Plugin]: ipv4: true,
[WebRTC Plugin]: type: 'prflx',
[WebRTC Plugin]: isLocalNetwork: false,
[WebRTC Plugin]: destinationId: '178.199.184.165'
[WebRTC Plugin]: }
[WebRTC Plugin]: done waiting ice connected
[WebRTC Plugin]: Connection is local network: false 178.199.184.165 {
[WebRTC Plugin]: ipv4: true,
[WebRTC Plugin]: type: 'prflx',
[WebRTC Plugin]: isLocalNetwork: false,
[WebRTC Plugin]: destinationId: '178.199.184.165'
[WebRTC Plugin]: }
[Rebroadcast Plugin]: Selected stream default
[Rebroadcast Plugin]: rebroadcast error Error: timeout waiting for data, killing parser session
[Rebroadcast Plugin]: at eval (/@scrypted/prebuffer-mixin/main.nodejs.js:1:70085)
[Rebroadcast Plugin]: at Timeout.eval (/@scrypted/prebuffer-mixin/main.nodejs.js:1:70099)
[Rebroadcast Plugin]: at listOnTimeout (node:internal/timers:581:17)
[Rebroadcast Plugin]: at process.processTimers (node:internal/timers:519:7)
[Rebroadcast Plugin]: Klingel restarting prebuffer session in 5 seconds
[Rebroadcast Plugin]: default prebuffer session ended with error Error: ffmpeg killed before sdp could be parsed
[Rebroadcast Plugin]: at eval (/@scrypted/prebuffer-mixin/main.nodejs.js:1:72248)
[Rebroadcast Plugin]: at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
[WebRTC Plugin]: Error starting playback for WebRTC track. RPCResultError: ffmpeg killed before sdp could be parsed
[WebRTC Plugin]: at eval (/@scrypted/prebuffer-mixin/main.nodejs.js:1:72248)
[WebRTC Plugin]: at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
[WebRTC Plugin]: thread:main
[WebRTC Plugin]: @scrypted/prebuffer-mixin:host
[WebRTC Plugin]: host:@scrypted/webrtc {
[WebRTC Plugin]: cause: undefined
[WebRTC Plugin]: }
[WebRTC Plugin]: signalingState closed
[WebRTC Plugin]: connectionState closed
[WebRTC Plugin]: iceConnectionState closed
[Rebroadcast Plugin]: default prebuffer session started
[Rebroadcast Plugin]: default prebuffer session starting
[Rebroadcast Plugin]: -hide_banner -fflags +genpts -analyzeduration 0 -probesize 32 -fflags nobuffer -flags low_delay -f rtsp -rtsp_transport tcp -i rtsp:[REDACTED] -f mulaw -ac 1 -ar 8000 -channel_layout mono -use_wallclock_as_timestamps true -i tcp:[REDACTED] -rtsp_transport tcp -vcodec copy -acodec copy -f rtsp rtsp://127.0.0.1:40087/77f4b3e6299aab15
Doorbird: timed out waiting for tcp client from ffmpeg

[Vinisz]

I tired above "solutions" but still issues with the doorbird plugin, the stream just stops working after couple of hours and it's not reliable at the moment