Ситуація знайома: на сайті користувач заповнює форму, після відправки бачить статус «Надіслано», але в поштовій скриньці (або CRM) заявка так і не з'являється. При цьому помилка може не відображатися на фронтенді — отже, втрачається лист десь «по дорозі» між формою, сервером та поштовими сервісами. 1) Обробник форми не відправляє листа (або відправляє в неправильне місце) Найчастіша причина – серверна частина форми налаштована так, що користувач бачить успішну відповідь від бекенда, але фактичне відправлення листа не відбувається. Це буває, коли обробник: - Повертає «успіх» до завершення відправки; - падає помилково, але помилка не логується і користувачу не показується; — надсилає лист на іншу email/адресу або в інше середовище (staging замість production). Перевірка: відкрийте логи сервера (PHP/Node/Python/NGINX) і перегляньте, чи викликає запит очікуваний endpoint, і що відбувається після POST-запиту. Хороший індикатор — чи є у логах рядка про надсилання листа чи запис про винятки.
Щоб зрозуміти, скільки місця на диску знадобиться для зберігання записів з камер , використовують простий підхід: спочатку оцінюють бітрейт відео (скільки Мбіт/с витрачає потік), потім рахують об'єм за добу і множать число днів. 1) Головна формула розрахунку Якщо відомий бітрейт потоку (Мбіт/с), то приблизний об'єм: Обсяг за добу (ГБ) ≈ Бітрейт (Мбіт/с) × 86 400 / 8 / 1 000 Найчастіше в практичних завданнях зручно користуватися заокругленням: 1 Мбіт/с ≈ 10.8 ГБ на добу (у десятковій системі: 1 GB = 10бай байт). 2) Як отримати бітрейт із дозволу та “якості” Дозвіл сам по собі не дає точної відповіді: на розмір найсильніше впливають кодек (H.264/H.265), складність сцени (рух), налаштування (CBR/VBR, профіль, якість) та тривалість/тип запису. Проте для попередньої оцінки можна використовувати типові орієнтири. Для постійного запису (24/7) середні значення часто беруть так: камери H.264 зазвичай вимагають більше місця, ніж H.265 при порівнянні якості.

Коментарі
Дописати коментар