res2001

В C++17 есть std::filesystem::exists.
В более ранних версиях C++ можно после открытия сразу перейти в конец файла и посмотреть текущую позицию. Если позиция 0, то файл либо был пустой при открытии, либо вновь только что созданнался. После этого надо опять вернуться на начало файла.
Вместо ofstream можно использовать функцию std::fopen, там можно с помощью параметра mode запретить открывать не существующий файл. Если функция вернет пустой FILE*, то либо файл не существует, либо произошла другая ошибка. Можно дальше проанализировать значение переменной errno, чтоб отделить ситуацию отсутствия файла от других возможных ошибок, но это уже платформозависимо.

Так же можно использовать API ОС для проверки существования файла. В линукс - stat(..).

В addv и delv в блоке else вы разблокируете мьютекс и дальше он у вас все время в разблокированном состоянии.
Так что никакой синхронизации не происходит в принципе.
Вам не нужно разблокировать мьютекс, просто вместо usleep используйте pthread_cond_timedwait. Внутри этой функции мьютекс неявно разблокируется, потом ждет наступление события (сигнал или таймаут), затем мьютекс снова захватывается и только после этого возвращается управление вызывающему коду.
Аналогично работает и pthread_cond_wait, только без таймаута.
В этом случае блок if следует переписать так что бы не было двойного вызова pthread_cond_wait.

Не увидел в коде где вы инициализируете мьютекс и условную переменную, а так же где вы их удаляете. Без инициализации все функции их использующие будет возвращать ошибки.

Нужно ВСЕГДА обрабатывать возвращаемые значения системных функций!

Почему вы потоки используете из std, а мьютекс и условную переменную из pthread? Где логика?

У вас там ожидалось только имя файла, а вставляется полный путь к файлу, поэтому и ошибка.
Вот это место в команде "part-^%03d.mp4".
Замените на "%%~ni.mp4"

что может влиять?

Много факторов: медленная/высокая скорость на одном из портов и/или не достаточная длина буфера, большая загрузка ЦП во время работы (причем он может быть загружен любой не связанной задачей), плохое качество связи по сети, что приводит к повторной передаче и тормозит текущую передачу, что приводит к переполнению буферов и т.п.
Учитывая, что в TCP данные не могут теряться, значит они теряются либо по дороге в nc, либо внутри nc.
Если в nc есть возможность поиграть с размерами буферов - поэкспериментируйте с ними. Но часто универсальные решения не являются оптимальными для конкретной задачи.

Оба варианта правильные. Имя функции это и есть указатель на функцию, так что sizeof(foo) == sizeof(&foo). По сути тут компилятор просто игнорирует операцию взятия адреса от функции.
Вся функция никогда не передается - только указатель.

Я бы предпочел второй вариант, т.к. тут явно указано, что надо передавать указатель на функцию.
На самом деле тип указателя на функцию я бы оформил через typedef, и в параметре указывал бы уже имя типа:

typedef void (*foo_t)();
void fooPrint(foo_t foo) {
    foo();
}

Так же lua (как и другие скриптовые языки) можно встраивать в собственное приложение.
Оба варианта имеют место быть, вопрос лишь в том кто главный и кто рулит тут всем.
При использовании подхода из ответа shurshur главный - интерпретатор скриптового языка (и твое приложение, написанное на этом языке), а твоя С/С++ библиотека - один из модулей используемых скриптом.
При встраивании главное твое приложение, которое может вызывать скрипты для каких-то своих целей. Скрипты могут использовать объекты твоей программы, для которых ты разрешил это действие.
Выбор реализации во многом зависит от того, что хочется получить в итоге.

Батники не умеют работать с датами. Все переменные там - строки.
Вы можете вручную разделить дату на составные части и вычислить -3 дня.
Так же можно написать вспомогательный скрипт на JS/VBS, которые умеют работать с датами. В скрипт передавать дату и он будет вычислять -3 дня и выводить ее в stdout, где батником можно эту дату прочитать.
Или же вы можете использовать powershell вместо cmd, там, наверняка, можно решить вашу задачу без лишних телодвижений.

Но вам же для чего-то нужна дата "-3 дня". Если знать для чего вы пытаетесь вычислить такую дату, то может найдутся и другие способы ее решения, без вычисления.

Подсоединяюсь по VPN в локальную сеть, все ок

Как вы подсоединяетесь в локальную сеть? Как вы видите, что все Ок?
Пинги с ВПН клиента до любого компьютера в сети идут? Подозреваю, что пинги не идут.

Скорее всего вам надо на ВПН клиенте добавить маршрут до сети за ВПН сервером через ВПН адрес маршрутизатора.
Делается это командой: route add ...
Для справки смотрите route /?

Cогласен с Сергей - фаервол может блокировать трафик. Причем фаервол на любом промежуточном узел, а у вас их 3: ВПН клиент, ВПН сервер, RDP сервер. Любой из 3 фаерволов может блокировать трафик.

Антивирус скорее всего не при делах.

Прежде чем добиваться работы RDP рекомендую добиться, что бы работал пинг на внутренние адреса в локальной сети. Кроме того антивирус на пинги не влияет, хотя фаервол может блокировать и их.

Подключение ВПН на клиенте и сервере создает дополнительный виртуальный сетевой адаптер со своим IP адресом. Программное обеспечение ВПН отвечает только за трафик, который попадает внутрь ВПН. Все остальное конфигурируется стандартными средствами: таблицы маршрутизации, фаерволы, NAT. В openvpn некоторые настройки таблиц маршрутизации можно (нужно) указывать в конфиге ВПН, а не напрямую править таблицы в ОС. Все это относится к любой ОС - принципы работы openvpn одинаковы в линукс и винде.

Обычно конфиг клиента делают максимально "легким". Там указывают только необходимые опции для подключения к серверу (протокол, адрес и порт сервера, параметры шифрования и логирования). Все что касается маршрутизации между сетями (route, push route) убирается в конфиг сервера.
Опция push "route ..." - добавляет маршрут на удаленной стороне. Т.е. если опция указана в конфиге сервера, то маршрут добавляется на стороне клиента.
Для добавления маршрута на стороне сервера в конфиге сервера используется опция: route

CCD файлы:
У вас не правильный синтаксис для опции ifconfig-push.
Правильный такой: ifconfig-push client_ip mask
Т.е. IP сервера не требуется указывать.
В опции iroute указываем сети за этим конкретным клиентом. Эти маршруты добавятся в таблицу маршрутизации сервера при подключении клиента. Не нужно дублировать эти маршруты опциями route в основном конфиге сервера.
Так же можно в CCD файле указать опцию push route для добавления маршрута клиенту для сети за сервером. Обычно push route указывают в основном конфиге сервера и она работает для всех клиентов.

Но! Что бы сети за клиентом и сервером могли друг друга видеть они должны знать по каким маршрутам передавать трафик друг для друга. Если ВПН сервер и ВПН клиент являются для своих сетей шлюзами по умолчанию - то проблемы нет, компы внутри сетей и так будут слать весь трафик через них. Но если ВПН сервер и/или ВПН клиент не являются шлюзами по умолчанию для своих сетей, то требуется добавить дополнительные маршурты для соседних сетей через ВПН сервер/клиент. Централизованно маршруты можно добавить через опции DHCP, возможно политиками AD.

Фаерволы на любом узле могут блокировать трафик. Для отладки взаимодействия сетей через ВПН рекомендую сначала отключить фаерволы на всех тестовых устройствах. После того как настроите маршрутизацию фаерволы включайте по одному, сразу проверяйте работу и вносите изменения в правила фаервола, если необходимо.

После того как вы добились соединения ВПН клиента с сервером все остальное - это правильная настройка маршрутизации и фаерволов.