Why is the video player on the site trying to pick up non-existent hls segments?

Question

Nginx

На сервере(nging + rtmp-module + ffmpeg) настроена ретрансляция по протоколу hls. Проблема заключается в том, что видеоплеер запрашивает с сервера сегменты, которые сервер уже удалил. Почему так происходит и как это исправить?
Если отключать hls cleanup, то для воспроизведения берутся старые фрагменты. Это уже не трансляция в режиме реального времени, а воспроизведение записи получается.

конфиги

rtmp.conf

# RTMP configuration
rtmp {
    server {
        listen 1935; # Listen on standard RTMP port
        chunk_size 4000;

        application show {
            live on;
            hls on;
            hls_path /tmp/hls;

            hls_fragment 1;
            hls_playlist_length 10;

            exec_static ffmpeg -i "rtsp://@10.10.120.200/0" -vcodec h264 -vf scale=640:480 -f flv -an rtmp://localhost:1935/show/live 2>>/var/log/nginx/ffmpeg_show.log;

        }
    }
}

test.ru.conf

server {
    listen      192.168.100.87:80;
    server_name test.ru www.test.ru;

    index       index.php index.html index.htm;
    access_log  /home/user1/logs/tm2.demis.ru.log combined;
    access_log  /home/user1/logs/tm2.demis.ru.bytes bytes;
    error_log   /home/user1/logs/tm2.demis.ru.error.log error;

    root        /home/user1/web/blog/public;

    location / {

        add_header 'Access-Control-Allow-Origin' '*';
        try_files $uri $uri/ /index.php?$query_string;

        location ~* ^.+\.(jpeg|jpg|png|gif|bmp|ico|svg|css|js)$ {
            expires     max;
        }

        location ~ [^/]\.php(/|$) {
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            if (!-f $document_root$fastcgi_script_name) {
                return  404;
            }

            fastcgi_pass    127.0.0.1:9006;
            fastcgi_index   index.php;
            include         /etc/nginx/fastcgi_params;
            add_header Access-Control-Allow-Origin *;
        }
        

    }


    location /hls {
        # Disable cache
        add_header Cache-Control no-cache;

        # CORS setup
        add_header 'Access-Control-Allow-Origin' '*' always;
        add_header 'Access-Control-Expose-Headers' 'Content-Length';

        # allow CORS preflight requests
        if ($request_method = 'OPTIONS') {
            add_header 'Access-Control-Allow-Origin' '*';
            add_header 'Access-Control-Max-Age' 1728000;
            add_header 'Content-Type' 'text/plain charset=UTF-8';
            add_header 'Content-Length' 0;
            return 204;
        }

        types {
            application/vnd.apple.mpegurl m3u8;
            video/mp2t ts;
        }

        if ($request_method = 'GET') {
        add_header 'Access-Control-Allow-Origin' '*';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
        add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
        add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';
     }

        root /tmp;
        #alias /tmp/hls;

    }

    error_page  403 /error/404.html;
    error_page  404 /error/404.html;
    error_page  500 502 503 504 /error/50x.html;

}

Answer 1

Даю ссылку по которой обычно вспоминаю как конфиг делать на hls:
https://www.vultr.com/docs/setup-nginx-on-ubuntu-t...
Смысл в том, что вроде логика нарушена:
У вас прописан в /show exec в теле и указывающий на то что надо запустить некий rtsp и пустить его в /show/live
Но на сколько мне не изменяет память пока вы не сделаете вещание на точку show, он не запустит exec
Но самое смешное что если вы что-то запустите на /live он два раза запустит exec и возникнет конфликт
hls_fragment пропустили s после единицы.
Во-вторых это практически заведомо не работающая конфигурация. У клиентов возникнут беды. По-русски вы просите сделать буфер из 10 кусков по одной секунде.
That's bullshit. Pieces should be larger and pieces smaller. In this configuration, you force the client to download 10 chunks in a row, which will create a problem even in terms of the number of connections.
Conf: 10s / 1 - working average delay 12-15 seconds
Conf: 3s / 2 - delay about 6-7 seconds, tested, works stably.
The second digit is playlist_length