Platform server

Для администратора платформы (vidicap.cloud или сервер больницы): как загрузить файлы для устройств, собрать пакеты для флешки и понять, хватает ли серверу мощности. Установка самого сервера — в platform/deploy/VPS.md репозитория.

Файлы для устройств

Раздел «Выпуски для устройств» → «Все файлы» (видит только администратор платформы). Тип файла определяется сам по manifest.json внутри.

После каждого обновления сервера из git эти файлы собираются сами и сразу становятся доступными; уже загруженные версии пропускаются (VIDICAP_RELEASES_AUTOPUBLISH=0 в .env — добавлять скрытыми). Собрать вручную: sudo ./autoupdate.sh releases. Устройства всё равно ставят обновление только после подтверждения на экране.

Порядок выпуска вручную:

1. Загрузить файл скрытым (без галочки «Сразу сделать доступным»).
2. Проверить на одном устройстве (скачать вручную).
3. «Сделать доступным» — устройства и мастер установки берут самую новую доступную версию каждого типа.

Критическое обновление. Выпуск с важными исправлениями помечается красной меткой «Критическое» в «Все версии» и рядом с версией программы. Метку ставит разработчик (для программы Vidicap Touch 1.0 — файл rev1/release.json: "version" выпуска, "critical": true и текст «Что нового»), а суперадминистратор может снять её кнопкой «Снять «Критическое»» или поставить любому выпуску кнопкой «Отметить критическим». Устройства получают эту пометку вместе с предложением обновиться; ставится обновление по-прежнему только после подтверждения на экране.

Большие файлы (пакеты, ≈ 1,4 ГБ) удобнее добавить прямо на сервере:

cd ~/Vidicap_OR/platform/deploy
sudo ./up.sh packages                         # собрать пакеты Ubuntu здесь и сразу опубликовать
sudo PUBLISH=1 ./up.sh release vidicap2-2.1.0.tar.gz   # добавить готовый файл

Пакеты пересобирают, когда изменились requirements.txt или deploy/packages.txt — страница выпусков предупреждает об этом. Файл для флешки (установщик + пакеты) платформа собирает сама один раз и потом отдаёт сразу.

Если новая версия не работает: вернуть прежнюю

Все версии хранятся на платформе: «Выпуски для устройств» → «Все версии» — любую можно скачать (администраторы организаций и платформы).

1. Отозвать плохую версию (администратор платформы): «Все версии» → «Отозвать». Последней снова станет предыдущая; новые установки и обновления берут её. Устройства, где уже стоит отозванная версия, получат предложение «Вернуть версию …» — его подтверждают на самом устройстве, как обычное обновление. С платформы можно ещё и предложить возврат на странице точки.
2. Вернуть вручную: скачайте прежнюю версию в «Все версии» и поставьте её поверх теми же командами, что и при установке (Vidicap Touch 1.0 — install-addon.sh, Vidicap Touch 2.0 — deploy/install.sh). Настройки, подключение к точке и язык сохраняются.
3. Vidicap Touch 1.0, сразу на месте: «Платформа» → «Вернуть предыдущую версию» (предыдущая хранится на самом устройстве).

Исправленную версию выпускают с большим номером: отозванная версия с тем же номером больше не публикуется.

Нагрузка сервера

Плитка «Нагрузка сервера»: процессор, память, диск, трафик, число трансляций и зрителей — замер раз в минуту, графики за сутки, неделю, месяц и вывод простыми словами.

• Укажите скорость канала по тарифу хостинга в platform/deploy/.env: VIDICAP_SERVER_BANDWIDTH_MBIT=100 — тогда видно, какая доля канала занята и сколько ещё зрителей выдержит сервер.
• Решение «увеличивать ли сервер» принимается по значению, которое держится 95% времени, а не по коротким всплескам.
• Главный ресурс стримингового сервера — исходящий канал: каждый зритель ≈ 2–4 Мбит/с.

Трансляции Vidicap Touch 1.0: H.264 делает сервер больницы

Touch 1.0 пишет и транслирует в MPEG-4, а браузеры его не показывают. Раньше агент на самом Touch 1.0 переводил трансляцию в H.264, и это был третий кодировщик рядом с записью и трансляцией на старом процессоре. Теперь, если Vidicap подключён к серверу больницы (не к vidicap.cloud напрямую), это делает сервер:

1. Агент 1.56.0 и новее отправляет картинку на сервер как есть, без пережатия. Звук по-прежнему переводится в Opus на устройстве, это почти не нагружает процессор.
2. Сервер (служба cloudlink) переводит её в H.264 и выдаёт зрителям и на vidicap.cloud по прежнему адресу точки. Для врачей ничего не меняется.
3. Vidicap Touch 2.0 и Touch 1.0, переведённый на H.264, отправляют поток как раньше: сервер его не пережимает.

Сервер тратит на каждую такую трансляцию около одного ядра процессора. «Калькулятор сервера» это учитывает. Отключить пережатие на сервере можно строкой VIDICAP_SERVER_TRANSCODE=0 в platform/deploy/.env: тогда устройства снова пережимают трансляцию сами.

Как проверить: включите трансляцию на Touch 1.0 и откройте точку в браузере на сервере больницы, картинка должна идти. В «Нагрузке сервера» у такой точки два потока вместо одного: исходный и H.264. Нагрузка процессора самого Touch 1.0 во время трансляции заметно ниже.

Проектные документы

Только для администраторов платформы (суперпользователей): в главном меню плитка «Проектные документы», ссылка есть и внизу «Инструкций для техников». Другие пользователи этот раздел не видят, а по прямой ссылке получают «Страница не найдена».

Там лежат наши планы новых функций, которые ещё делаются: Vidicap Connect, Vidicap Assistant, маршрутизация видео IPS4000, архив обследований, связь с облаком, бот Telegram. Это не инструкции: когда функция готова, её инструкция появляется в «Инструкциях для техников». Внизу раздела ссылки на живые документы: общую схему системы и план облегчённой платформы.

Документ открывается с оглавлением слева:

Новый документ добавляется файлом в platform/core/design/ (Markdown, первая строка # Заголовок) и строкой в списке DOCUMENTS в platform/core/design_docs.py. Руководства других производителей (Mindray, FSN и др.) в репозиторий не кладутся.

Обслуживание

sudo ./autoupdate.sh status     # следит ли сервер за веткой main, последнее обновление
sudo ./autoupdate.sh run        # проверить и обновить сейчас
./autoupdate.sh builds          # что собралось для устройств, что нет и почему (и на платформе: «Выпуски для устройств»)
sudo ./diagnose.sh              # проверка сервера: службы, порты, сертификаты, логи
docker compose ps               # службы: web, mediamtx, caddy, db, monitor, cloudlink

← Troubleshooting Server calculator: procurement requirements →