i gather this has historically been a bit of a problem, but i haven’t found a solution anywhere. i just tried uploading a video file that was 342 mb in size, and it just gets stuck. after a while, the bar will move over some more, but then it fails with « Your video file was too large (max. size: 8G) » my instance has 32 threads allowed to it, and 32 threads are set for transcoding. is this a bug?
Hi,
Ensure your nginx configuration is up to date with our latest template: PeerTube/support/nginx/peertube at develop · Chocobozzz/PeerTube · GitHub
it seems there are several components on this situation that are in need of an update. i am not only new to peertube, i am new to the entirety of linux, so bear with me a little.
i can’t just go update peertube my executing a scrypt, eh? because when i try, it says there are some dependencies that are below the minimum version. for example node. so do i go through and update the dependencies from top to bottom first? and then execute the update script for peertube?
ok. i updated peertube to 6.1 using the update scripts, and as part of that also ran your nginx configuraiton update script:
cd /var/www/peertube/versions
diff -u "$(ls -t | head -2 | tail -1)/support/nginx/peertube" "$(ls -t | head -1)/support/nginx/peertube"
the behavior persists. 140 mb files exhibit the same behavior. goes to about 8% and grinds to a halt. after about 5-10 minute the upload seems to finish, but at the very end the upload bar turns red with « Your video file was too large »
p.s. sometimes spamming the « retry » button seems to eventually succeed. but for some it doesn’t.
This is not an update script, this is only a command line that shows you if there are differences between the two last nginx config files. You then have to report them manually.
If you did some upgrades without checking this, you could have some missing configuration (as it only compare the 2 last versions).
As said by Chocobozzz, you should compare the last available nginx config with your configuration file, and update it accordingly.
If there are too many differences, and you had the official nginx file (without any customization), you can just apply again the webservice installation guide (copy the template, then run the two sed commands)
hey john,
thanks for clarifying. one day i’ll be a linux ninja and i won’t need clarification on these simple matters.
after i update peertube to the 6.1 version, and then run the copy template script, i should have the latest configuration of nginx, right? is that what choco was referring to when he said to make sure my configuration is up to date?
ok. i have done the above:
- upgraded peertube to 6.1.0
- executed the script to copy the nginx config from « peertube latest »
- ran both of the
sedcommands
the behavior remains the same, except now it doesn’t wait as long to say the file is too large. even a 150 mb file basically fails instantly with « file too large »
Yes
Can you copy the content of your nginx configuration file?
Can you check what is the error in your browser console (F12 to open it).
Have you any error log on Peertube? (you can get them using the admin web interface).
how much of the browser console would you like to see? there doesn’t seem to be too much in it:
the admin console says « no log ».
And can you copy your nginx config file?
Just to be sure, have you reloaded or restarted nginx after modifying it?
hey john, sorry, it’s been a bit crazy here; sorry for the delayed response.
yes. i did a sudo systemctl restart nginx after doing the update. it did not return any errors, so i’d say it did work.
i’m a bit new to linux here, so pardon my ignorance. you want me to copy the config file itself and post it? or copy the next of the config file and post it? if you could give me a file path to the file you need i’ll send you what you need. as an fyi, peertube is running on an ubuntu desktop machine, and everything is installed on a single drive following the production guide.
The content of the file you edited (something like /etc/nginx/sites-enabled/peertube), to check if there is a mistake.
hey John,
thanks for your time on this. i couldn’t upload the file here, so here’s a link to it:
also, hopefully there are no security implications in sharing this here. i assumed that’s what you were asking me to do 
I have no google account to access this.
You can just copy paste the content in a forum message, using ``` (as you made in this post).
There is no security implication, as this file should be similar to the one in the Peertube source code. It will just reveal your instance url.
ok no problem. here you go.
# Minimum Nginx version required: 1.13.0 (released Apr 25, 2017)
# Please check your Nginx installation features the following modules via 'nginx -V':
# STANDARD HTTP MODULES: Core, Proxy, Rewrite, Access, Gzip, Headers, HTTP/2, Log, Real IP, SSL, Thread Pool, Upstream, AIO Multithreading.
# THIRD PARTY MODULES: None.
server {
listen 80;
listen [::]:80;
server_name leuttube.com;
location /.well-known/acme-challenge/ {
default_type "text/plain";
root /var/www/certbot;
}
location / { return 301 https://$host$request_uri; }
}
upstream backend {
server 127.0.0.1:9000;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name leuttube.com;
access_log /var/log/nginx/peertube.access.log; # reduce I/0 with buffer=10m flush=5m
error_log /var/log/nginx/peertube.error.log;
##
# Certificates
# you need a certificate to run in production. see https://letsencrypt.org/
##
ssl_certificate /etc/letsencrypt/live/leuttube.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/leuttube.com/privkey.pem;
location ^~ '/.well-known/acme-challenge' {
default_type "text/plain";
root /var/www/certbot;
}
##
# Security hardening (as of Nov 15, 2020)
# based on Mozilla Guideline v5.6
##
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256; # add ECDHE-RSA-AES256-SHA if you want compatibility with Android 4
ssl_session_timeout 1d; # defaults to 5m
ssl_session_cache shared:SSL:10m; # estimated to 40k sessions
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
# HSTS (https://hstspreload.org), requires to be copied in 'location' sections that have add_header directives
#add_header Strict-Transport-Security "max-age=63072000; includeSubDomains";
##
# Application
##
location @api {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
client_max_body_size 100k; # default is 1M
proxy_connect_timeout 10m;
proxy_send_timeout 10m;
proxy_read_timeout 10m;
send_timeout 10m;
proxy_pass http://backend;
}
location / {
try_files /dev/null @api;
}
location ~ ^/api/v1/videos/(upload-resumable|([^/]+/source/replace-resumable))$ {
client_max_body_size 0;
proxy_request_buffering off;
try_files /dev/null @api;
}
location ~ ^/api/v1/users/[^/]+/imports/import-resumable$ {
client_max_body_size 0;
proxy_request_buffering off;
try_files /dev/null @api;
}
location ~ ^/api/v1/videos/(upload|([^/]+/studio/edit))$ {
limit_except POST HEAD { deny all; }
# This is the maximum upload size, which roughly matches the maximum size of a video file.
# Note that temporary space is needed equal to the total size of all concurrent uploads.
# This data gets stored in /var/lib/nginx by default, so you may want to put this directory
# on a dedicated filesystem.
client_max_body_size 12G; # default is 1M
add_header X-File-Maximum-Size 8G always; # inform backend of the set value in bytes before mime-encoding (x * 1.4 >= client_max_body_size)
try_files /dev/null @api;
}
location ~ ^/api/v1/runners/jobs/[^/]+/(update|success)$ {
client_max_body_size 12G; # default is 1M
add_header X-File-Maximum-Size 8G always; # inform backend of the set value in bytes before mime-encoding (x * 1.4 >= client_max_body_size)
try_files /dev/null @api;
}
location ~ ^/api/v1/(videos|video-playlists|video-channels|users/me) {
client_max_body_size 6M; # default is 1M
add_header X-File-Maximum-Size 4M always; # inform backend of the set value in bytes before mime-encoding (x * 1.4 >= client_max_body_size)
try_files /dev/null @api;
}
##
# Websocket
##
location @api_websocket {
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_pass http://backend;
}
location /socket.io {
try_files /dev/null @api_websocket;
}
location /tracker/socket {
# Peers send a message to the tracker every 15 minutes
# Don't close the websocket before then
proxy_read_timeout 15m; # default is 60s
try_files /dev/null @api_websocket;
}
# Plugin websocket routes
location ~ ^/plugins/[^/]+(/[^/]+)?/ws/ {
try_files /dev/null @api_websocket;
}
##
# Performance optimizations
# For extra performance please refer to https://github.com/denji/nginx-tuning
##
root /var/www/peertube/storage;
# Enable compression for JS/CSS/HTML, for improved client load times.
# It might be nice to compress JSON/XML as returned by the API, but
# leaving that out to protect against potential BREACH attack.
gzip on;
gzip_vary on;
gzip_types # text/html is always compressed by HttpGzipModule
text/css
application/javascript
font/truetype
font/opentype
application/vnd.ms-fontobject
image/svg+xml;
gzip_min_length 1000; # default is 20 bytes
gzip_buffers 16 8k;
gzip_comp_level 2; # default is 1
client_body_timeout 30s; # default is 60
client_header_timeout 10s; # default is 60
send_timeout 10s; # default is 60
keepalive_timeout 10s; # default is 75
resolver_timeout 10s; # default is 30
reset_timedout_connection on;
proxy_ignore_client_abort on;
tcp_nopush on; # send headers in one piece
tcp_nodelay on; # don't buffer data sent, good for small data bursts in real time
# If you have a small /var/lib partition, it could be interesting to store temp nginx uploads in a different place
# See https://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_temp_path
#client_body_temp_path /var/www/peertube/storage/nginx/;
# Bypass PeerTube for performance reasons. Optional.
# Should be consistent with client-overrides assets list in client.ts server controller
location ~ ^/client/(assets/images/(icons/icon-36x36\.png|icons/icon-48x48\.png|icons/icon-72x72\.png|icons/icon-96x96\.png|icons/icon-144x144\.png|icons/icon-192x192\.png|icons/icon-512x512\.png|logo\.svg|favicon\.png|default-playlist\.jpg|default-avatar-account\.png|default-avatar-account-48x48\.png|default-avatar-video-channel\.png|default-avatar-video-channel-48x48\.png))$ {
add_header Cache-Control "public, max-age=31536000, immutable"; # Cache 1 year
root /var/www/peertube;
try_files /storage/client-overrides/$1 /peertube-latest/client/dist/$1 @api;
}
# Bypass PeerTube for performance reasons. Optional.
location ~ ^/client/(.*\.(js|css|png|svg|woff2|otf|ttf|woff|eot))$ {
add_header Cache-Control "public, max-age=31536000, immutable"; # Cache 1 year
alias /var/www/peertube/peertube-latest/client/dist/$1;
}
location ~ ^(/static/(webseed|web-videos|streaming-playlists/hls)/private/)|^/download {
# We can't rate limit a try_files directive, so we need to duplicate @api
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_limit_rate 5M;
proxy_pass http://backend;
}
# Bypass PeerTube for performance reasons. Optional.
location ~ ^/static/(webseed|web-videos|redundancy|streaming-playlists)/ {
limit_rate_after 5M;
set $peertube_limit_rate 5M;
# Use this line with nginx >= 1.17.0
limit_rate $peertube_limit_rate;
# Or this line with nginx < 1.17.0
# set $limit_rate $peertube_limit_rate;
if ($request_method = 'OPTIONS') {
add_header Access-Control-Allow-Origin '*';
add_header Access-Control-Allow-Methods 'GET, OPTIONS';
add_header Access-Control-Allow-Headers 'Range,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';
add_header Access-Control-Max-Age 1728000; # Preflight request can be cached 20 days
add_header Content-Type 'text/plain charset=UTF-8';
add_header Content-Length 0;
return 204;
}
if ($request_method = 'GET') {
add_header Access-Control-Allow-Origin '*';
add_header Access-Control-Allow-Methods 'GET, OPTIONS';
add_header Access-Control-Allow-Headers 'Range,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';
# Don't spam access log file with byte range requests
access_log off;
}
# Enabling the sendfile directive eliminates the step of copying the data into the buffer
# and enables direct copying data from one file descriptor to another.
sendfile on;
sendfile_max_chunk 1M; # prevent one fast connection from entirely occupying the worker process. should be > 800k.
aio threads;
# web-videos is the name of the directory mapped to the `storage.web_videos` key in your PeerTube configuration
rewrite ^/static/webseed/(.*)$ /web-videos/$1 break;
rewrite ^/static/(.*)$ /$1 break;
try_files $uri @api;
}
}
This files seems ok.
Have you setup anything else on your server? Have you any nginx customization?
No other reverse proxy in front of peertube?
What is your user quota on Peertube?
the quota is unlimited by default. we do have a cloudlfare proxy in front of peertube, just for DDOS attacks and whatnot. should that change anything? also, no we didn’t custonize anything on nginx. we just followed the production guide to install, and didn’t touch it after that.
It can totally explain the issue.
I don’t use cloudflare, but i think i saw some related messages on this forum. If i remember well, cloudflare does not allow too big requests.
Search on the forum.
You can probably tweak the maxChunkSize settings in your production.yaml, to meet Cloudflare requirements.
ok, i cannot just edit the file on a running peertube instance, can i? do i need to shut down some kind of service first?