[Camera Support]: #22803
-
Beta Was this translation helpful? Give feedback.
Replies: 6 comments 2 replies
-
|
The issue where 5 cameras show 0.00 MB storage and 0.00 MB/hour bandwidth while others record normally points to a problem with the recording stream, not the detection or configuration. Since detection, motion, and events work on those cameras, the issue is isolated to the Key observations from your config: Your non-recording cameras (Perimeter_1 through Perimeter_4 and Entrada_1) use hardware transcoding in their substream definition: Perimeter_1_sub:
- ffmpeg:Perimeter_1#video=h264#hardwareWhile your working cameras (like Entrada_2, Salon_1, etc.) use: Entrada_2_sub:
- ffmpeg:Entrada_2#video=copyTroubleshooting steps:
logger:
logs:
frigate.record.maintainer: debugThis will produce logs showing copy times. If copy times exceed 1 second, storage may be too slow. (2)
Perimeter_1:
- tapo://{FRIGATE_TAPO_USER}:{FRIGATE_TAPO_PASSWORD}@192.168.2.46?subtype=0&audio=aacEnsure these cameras can provide a stable stream for recording by checking go2rtc's web interface for connection status and errors on those specific streams.
The pattern suggests the hardware transcoding ( 📚 Sources: Have another question? Just tag @inkeep. |
Beta Was this translation helpful? Give feedback.
-
|
In addition to the AI's recommendations, here are a few more points: One thing to remember is that the Tapo cameras only support 2 of these three concurrently:
|
Beta Was this translation helpful? Give feedback.
-
|
Hi. I reverted to version 16.04 and the cameras started recording. Version 17.0 didn't work either. I found a backup config.yml file from before the tapo:// implementation and extracted the go2rtc configuration without the tapo:// protocol (goodbye to two-way audio). Once verified, I reverted to version 0.17.1, deleted the recordings and the database, and for now it's working. I suspect the interference is due to the combination of tapo:// with a TC70v5 or a TC65v1. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
`go2rtc: |
Beta Was this translation helpful? Give feedback.
-
|
In summary: So far, so good. I ran some tests with different browsers, Edge and Safari. I discovered that with two-way audio (Tapo://), the screen worked correctly, but it still wouldn't record. When I say "normal," I mean Safari: with the microphone disabled, in Live View, MSE displayed the image with the correct framing, without cropping. This didn't happen on Windows (Edge, Firefox, Chrome), where the image wasn't displayed in MSE on those specific cameras: 1xTC70v5 Wi-Fi and 4xTC65 wired. In Safari, when the microphone is enabled, it switches to WebRTC with the correct framing, which also failed on Windows, where the image recovered but cropped. Now, in Safari without Tapo://, MSE works without problems, but the image doesn't adjust and appears cropped. I tested Firefox on a Mac, and it frames correctly, unlike Safari. Note: Now on Windows, correct framing without cropping is adjusted. Thanks |
Beta Was this translation helpful? Give feedback.

Hi. I reverted to version 16.04 and the cameras started recording. Version 17.0 didn't work either.
I found a backup config.yml file from before the tapo:// implementation and extracted the go2rtc configuration without the tapo:// protocol (goodbye to two-way audio). Once verified, I reverted to version 0.17.1, deleted the recordings and the database, and for now it's working.
I suspect the interference is due to the combination of tapo:// with a TC70v5 or a TC65v1.