Transcoding fails abruptly during stream

[OpenSrcerer]

Background

Client: Symfonium 9.1.0
LMS 3.51.0 (Docker)

Running behind NGINX with this config:

server {
    # Setup HTTPS certificates
    listen       443 default ssl;
    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    server_name  my.domain.name;

    ssl_certificate /path/to/ssl; # managed by Certbot
    ssl_certificate_key /path/to/key; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

    location /lms/ {    
        proxy_pass                            http://localhost:4042/;
    }
}

Issue Description

Media usually plays fine. However, I've noticed that sometimes they abruptly stop - this phenomenon is especially prevalent in longer tracks.
Today I ran a test and found this:

[2024-Mar-31 14:52:26.633] 1 - [info] "wthttp: 172.19.0.1   GET /rest/ping.view?u=Bonkers&p=enc%3A56336e6f6d7370333364&v=1.13.0&c=Symfonium&f=json HTTP/1.0 200 109"
[2024-Mar-31 14:52:26.633] 1 - [info] "WebRequest: took 23.135 ms"

# This seems problematic to me, there's no real "error" thrown here but maybe it makes the transcoding restart?
[flac @ 0x7efee3943000] Could not find codec parameters for stream 1 (Video: mjpeg, none): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options

# I believe transcoding restarts here
[2024-Mar-31 14:52:40.739] 1 - [info] - 139633201892152 [TRANSCODING] [155] - Transcoding file '/music/public_music/Dream Theater/Dream Theater - Octavarium (2009) [FLAC] [16B-44100kHz]/08. Dream Theater - Octavarium.flac'

[2024-Mar-31 14:52:48.160] 1 - [info] "wthttp: 172.19.0.1   GET /rest/scrobble.view?id=tr-50285&submission=false&u=Bonkers&p=enc%3A56336e6f6d7370333364&v=1.13.0&c=Symfonium&f=json HTTP/1.0 200 109"

On NGINX side I'm getting these logs. The timestamps don't really match up so maybe this is irrelevant, but thought to add it anyway for context.

2024/03/31 14:36:24 [alert] 649#649: *6957 open socket #23 left in connection 11
2024/03/31 14:36:24 [alert] 649#649: *6953 open socket #18 left in connection 15
2024/03/31 14:36:24 [alert] 649#649: *7033 open socket #9 left in connection 17
2024/03/31 14:36:24 [alert] 649#649: aborting

[epoupon]

Hello!

Did you try to increase timeout settings in nginx?
For example:

    proxy_read_timeout 10m;
    proxy_send_timeout 10m;
    keepalive_timeout 10m;

Tell me if that helps.

[OpenSrcerer]

Did you try to increase timeout settings in nginx? For example:

Hi, thank you for your reply!

Yes, I have done that. This is my current configuration:

    location /lms/ {
        proxy_read_timeout 30m; 
        proxy_send_timeout 30m; 
        keepalive_timeout 30m;
        proxy_pass http://localhost:4042/;
    }

On songs that are longer than 8 minutes I usually start having issues. The logs show behavior in exactly the same way as I've described above.

[epoupon]

Can you by chance try without proxy and tell how it behaves?