Jump to content

VPS Nginx Cache Video Streams

lobschnurr

By lobschnurr
in German

 Share

Recommended Posts

lobschnurr

lobschnurr 6

Posted
Posted

Hallo zusammen,

ich hoffe ihr könnt bei einem Problem helfen.

Hier gibt es ja so einige schöne Anleitungen, um Emby und einen Reverse Proxy wie NGINX (meistens auf dem selben Server) richtig zu konfigurieren.

Meine Infrastruktur sieht allerdings ein wenig anders aus.

Ein VPS Server mit Ubuntu und erfolgreich eingerichtetem NGINX mit A+ SSL (90%) steht. Allerdings ist der Emby-Server nicht auf dem selben Server, sondern wird über vier

unterschiedliche VPN Verbindungen angebunden. Das Load Balancing funktioniert auch grundsätzlich extrem gut.

Allerdings haben wir nun zwei Nutzer, welche mit Consumer-Hardware (Fritzbox) und DSL Internetleitungen (bis zu 250Mbit) ebenfalls versuchen Emby zu nutzen.

Leider ist die Bitrate miserabel bei rd. 1 Mbit bei 1080p oder 720p. Höhere Raten sorgen für massives Ruckeln in der Wiedergabe.

Die anderen Nutzen haben 1Gbit Glasfaserleitungen und mit allen Geräten (TV, Browser, Smartphone [Wifi]...) absolut keine Probleme (ebenfalls 4K mit 40Mbits ruckelfrei).

 

Aufgrund der Cloudflare Einschränken bezüglich des Video Contents, sind Anleitungen rar bis nicht mehr für 2025 vorhanden.

Gerade der Part in der NGINX Konfiguration bezüglich des Video-Cachings interessiert mich natürlich. Aber selbst die böse JF Konkurrenz hat

diesen Teil seit Mitte letzten Jahres nicht mehr in den offiziellen Docs.

 

Kann mir vielleicht jemand sagen, wie ich das bei NGINX für EMBY nutzen/ aktivieren kann? Das http-slice Modul ist bei mir bereits aktiviert. Das

Image-Caching funktioniert auch bestens, nur bekomme ich die richtige Konfiguration für das Video-Slice nicht hin.

nginx.conf:

Spoiler

        #Video Caching EMBY
        proxy_cache_path  /var/cache/nginx/emby-videos levels=1:2 keys_zone=emby-videos:100m inactive=15d max_size=20g use_temp_path=off;
        map $request_uri $h264Level { ~(h264-level=)(.+?)& $2; }
        map $request_uri $h264Profile { ~(h264-profile=)(.+?)& $2; }

server.conf

Spoiler 
    location /emby/videos/ {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Protocol $scheme;
        proxy_set_header X-Forwarded-Host $http_host;
        proxy_set_header REMOTE-HOST $remote_addr;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "";
        proxy_set_header Accept-Encoding "";
        proxy_http_version 1.1;
        proxy_cache off;
        proxy_buffering off;
    }

    location ~ ^/emby/videos/\d+/(?!live|\w+\.m3u8|hls1) {
        slice 14m;

        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Protocol $scheme;
        proxy_set_header X-Forwarded-Host $http_host;
        proxy_set_header REMOTE-HOST $remote_addr;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "";
        proxy_set_header Accept-Encoding "";
        proxy_set_header Range $slice_range;
        proxy_ignore_headers Expires Cache-Control Set-Cookie X-Accel-Expires;
        proxy_http_version 1.1;
        proxy_connect_timeout 15s;

        proxy_cache emby-videos;
        proxy_cache_valid 200 206 301 302 7d;
        proxy_cache_lock on;
        proxy_cache_lock_age 60s;
        proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;
        proxy_cache_key "$uri?MediaSourceId=$arg_MediaSourceId&VideoCodec=$arg_VideoCodec&AudioCodec=$arg_AudioCodec&AudioStreamIndex=$arg_AudioStreamIndex&VideoStreamIndex=$arg_VideoStreamIndex&ManifestSubtitles=$arg_ManifestSubtitles&VideoBitrate=$arg_VideoBitrate&AudioBitrate=$arg_AudioBitrate&SubtitleMethod=$arg_SubtitleMethod&TranscodingMaxAudioChannels=$arg_TranscodingMaxAudioChannels&SegmentContainer=$arg_SegmentContainer&MinSegments=$arg_MinSegments&BreakOnNonKeyFrames=$arg_BreakOnNonKeyFrames&h264-profile=$h264Profile&h264-level=$h264Level&slicerange=$slice_range";
    }

 

Nachdem man die nginx.conf und die server.conf mit dem o.g. Inhalt ergänzt hat und nginx neu gestartet wird, wird auch ordnungsgemäß das Verzeichnis /var/cache/nginx/emby-videos erstellt.

Allerdings werden dort nach dem Starten eines Streams keine temp Dateien abgelegt. Bei den "images" funktioniert das super.

Hat da jemand eine Idee wo in meiner Konfiguration der Fehler ist?

Luke Emby Team

Luke 40000

Posted
Posted

hi, this might be realistic when direct playing, but transcoded output is unique to each play session. You're not hoping to cache that are you?

lobschnurr

lobschnurr 6

Posted
  • Author
Posted

Hi Luke,

meine Hoffnung besteht darin, dass man durch Verlagerung sämtlicher Stream-Pakete (Directplay or Transcoded) zum VPS der miserablen Latenz der Internetleitung der beiden Nutzern entgegenwirken kann.

Mir ist bewusst, dass die transkodierten Pakete für jeden Benutzer und für jede Session neu berechnet werden müssen. Geschieht ja ebenfalls schon, wenn ein Benutzer den Stream für mehr als 60 Sekunden pausiert.

 

Hier ein grober Aufbau der Infrastruktur:

 

  --> VM 1/VPN-Provider inkl. Port-Forwarding -->      
EMBY --> VM 2/VPN-Provider inkl. Port-Forwarding --> VPS    Server --> EMBY Client
SERVER --> VM 3/VPN-Provider inkl. Port-Forwarding --> NGINX (Load Balancing)    
  --> VM 4/VPN-Provider inkl. Port-Forwarding -->      

 

lobschnurr

lobschnurr 6

Posted
  • Author
Posted

Danke für die großartige und umfangreiche Hilfe.

Habe den Fehler selber gefunden. 

Video - Caching funktioniert und die DSL-Anschluss-User können nun ruckelfrei den Stream genießen. Auch in Stoßzeiten.

  • Thanks 1
rogaven

rogaven 8

Posted
Posted
14 hours ago, lobschnurr said:

Danke für die großartige und umfangreiche Hilfe.

Sarkasmus?

14 hours ago, lobschnurr said:

Habe den Fehler selber gefunden. 

Video - Caching funktioniert und die DSL-Anschluss-User können nun ruckelfrei den Stream genießen. Auch in Stoßzeiten.

Würdest Du Deine Erkenntnis mit anderen teilen?

 

Ich habe von Deinem dargestellten Problem nichts verstanden, aber der ein oder andere vielleicht doch.

lobschnurr

lobschnurr 6

Posted
  • Author
Posted

Ok, hier meine Lösungskonfiguration um die Videostreamschnipsel dichter an den Client bereitzustellen und damit die Wege zum emby-server zu verkürzen.

Bitte bedenkt bei meinen Ausführungen, dass ich kein gelernter IT-ler bin und hier nur meine eigenen Erfahrungen oder Beobachtungen darlegen kann.

Hier basierend auf Nginx (nicht Nginx Proxy Manager):

nginx.conf

Spoiler

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
        worker_connections 1024;
        # multi_accept on;
}

http {

        ##
        # Basic Settings
        ##

        sendfile off;
        tcp_nopush on;
#       keepalive_timeout 65;
        types_hash_max_size 2048;
        server_tokens off;

        # server_names_hash_bucket_size 64;
        # server_name_in_redirect off;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ## Start: Timeouts ##
            client_body_timeout   10;
            client_header_timeout 10;
            keepalive_timeout     30;
            send_timeout          10;
            keepalive_requests    10;
        ## End: Timeouts ##

        server_names_hash_bucket_size 128;
        map_hash_bucket_size 64;

        ##
        # SSL Settings
        ##

        ssl_protocols TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers off;

        # Image Cache for emby
        proxy_cache_path /var/cache/nginx/emby levels=1:2 keys_zone=emby:100m max_size=15g inactive=30d use_temp_path=off;

        #Logging cencor for emby
        log_format stripsecrets '$remote_addr $host - $remote_user [$time_local] '
                    '"$secretfilter" $status $body_bytes_sent '
                    '$request_length $request_time $upstream_response_time '
                    '"$http_referer" "$http_user_agent"';


        map $request $secretfilter {
            ~*^(?<prefix1>.*[\?&]api_key=)([^&]*)(?<suffix1>.*)$  "${prefix1}***$suffix1";
            default                                               $request;
        }


        #Video Caching EMBY
        proxy_cache_path  /var/cache/nginx/emby-videos levels=1:2 keys_zone=emby-videos:100m inactive=3h max_size=20g use_temp_path=off;
        map $request_uri $h264Level { ~(h264-level=)(.+?)& $2; }
        map $request_uri $h264Profile { ~(h264-profile=)(.+?)& $2; }


        ##
        # Logging Settings
        ##

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        ##
        # Gzip Settings
        ##

        gzip on;
        gzip_disable "msie6";


        ##Aus´m Emby Forum als NGINX Zusatz aus der allgemeinen Doku
        gzip_comp_level 6;
        gzip_min_length 1100;
        gzip_buffers 16 8k;
        gzip_proxied any;
        gzip_types
           text/plain
           text/css
           text/js
           text/xml
           text/javascript
           application/javascript
           application/x-javascript
           application/json
           application/xml
           application/rss+xml
           image/svg+xml;

            tcp_nodelay on;

 

example.com

Spoiler

upstream backend {

        least_conn;
        server XXX.XXX.XXX.XXX:Port;
        server XXX.XXX.XXX.XXX:Port;
        server XXX.XXX.XXX.XXX:Port;
        server XXX.XXX.XXX.XXX:Port;
        keepalive 1000;

  }


server {
    listen 80;
    listen [::]:80;
    server_name example.com;

    # Uncomment to redirect HTTP to HTTPS
    return 301 https://$host$request_uri;
}

server {
    # Nginx versions prior to 1.25
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    # Nginx versions 1.25+
    #listen 443 ssl;
    #listen [::]:443 ssl;
    #http2 on;

    server_name example.com;

    ## The default `client_max_body_size` is 1M, this might not be enough for some posters, etc.
    client_max_body_size 20M;

    # Comment next line to allow TLSv1.0 and TLSv1.1 if you have very old clients
#    ssl_protocols TLSv1.3 TLSv1.2;

    # OCSP stapling
    ssl_stapling on;
    ssl_stapling_verify on;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
    resolver 1.1.1.1 1.0.0.1 valid=300s;
    resolver_timeout 5s;

 

    # Security / XSS Mitigation Headers
    add_header X-Content-Type-Options "nosniff";

    ## Strict Transport Security (HSTS): Yes
    add_header Strict-Transport-Security "max-age=31536000; includeSubdomains; preload";


    ## HTTP security headers | X-Frame-Options
    add_header X-Frame-Options "SAMEORIGIN" always;

    # Permissions policy. May cause issues with some clients
    add_header Permissions-Policy "accelerometer=(), ambient-light-sensor=(), battery=(), bluetooth=(), camera=(), clipboard-read=(), display-capture=(), document-domain=(), encrypted-media=(), gamepad=(), geolocation=(), gyroscope=(), >

    # Referrer-Policy
    add_header 'Referrer-Policy' 'no-referrer';


    # Content Security Policy
    # See: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
    # Enforces https content and restricts JS/CSS to origin
    # External Javascript (such as cast_sender.js for Chromecast) must be whitelisted.
    add_header Content-Security-Policy "default-src https: data: blob: ; img-src 'self' https://* ; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' https://www.gstatic.com https://www.youtube.com blob:; worker-src 's>

    #Must be inside server block
    #Insert into all servers where you want filtering (e.g HTTP + HTTPS block)
    access_log /var/log/nginx/access.log stripsecrets;


    location / {
        # Proxy main EMBY traffic
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Protocol $scheme;
        proxy_set_header X-Forwarded-Host $http_host;

        # Disable buffering when the nginx proxy gets very resource heavy upon streaming
        proxy_buffering off;
    }

    location /socket {
        # Proxy EMBY Websockets traffic
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Protocol $scheme;
        proxy_set_header X-Forwarded-Host $http_host;
    }


   location = /web/ {
       # Proxy main EMBY traffic
       proxy_pass http://backend/web/index.html;
       proxy_set_header Host $host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto $scheme;
       proxy_set_header X-Forwarded-Protocol $scheme;
       proxy_set_header X-Forwarded-Host $http_host;
   }

        # Cache images 
        location ~ /Items/(.*)/Images {
          proxy_pass http://backend;
          proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header X-Forwarded-Proto $scheme;
          proxy_set_header X-Forwarded-Protocol $scheme;
          proxy_set_header X-Forwarded-Host $http_host;

          proxy_cache emby;
          proxy_cache_revalidate on;
          proxy_cache_lock on;
          # add_header X-Cache-Status $upstream_cache_status; # This is only to check if cache is working
        }


    # Für Video-Stream Cache
     location ~ ^/emby/videos/\d+/(?!live|\w+\.m3u8) {
#    location ~ ^/emby/videos/\d+/(?!live|\w+\.m3u8|hls1) {
        slice 14m;

        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Protocol $scheme;
        proxy_set_header X-Forwarded-Host $http_host;
        proxy_set_header REMOTE-HOST $remote_addr;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "";
        proxy_set_header Accept-Encoding "";
        proxy_set_header Range $slice_range;
        proxy_ignore_headers Expires Cache-Control Set-Cookie X-Accel-Expires;
        proxy_http_version 1.1;
        proxy_connect_timeout 15s;

        proxy_cache emby-videos;
        proxy_cache_valid 200 206 301 302 7d;
        proxy_cache_lock on;
        proxy_cache_lock_age 60s;
        proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;

        # Cache-Schlüssel 
        proxy_cache_key "$uri?  MediaSourceId=$arg_MediaSourceId&VideoCodec=$arg_VideoCodec&AudioCodec=$arg_AudioCodec&AudioStreamIndex=$arg_AudioStreamIndex&VideoStreamIndex=$arg_VideoStreamIndex&ManifestSubtitles=$arg_ManifestSubtitles&>
        add_header X-Cache-Status $upstream_cache_status;

    }

  location ^~ /swagger {   ## Disables access to swagger interface
        return 404;
}

}

 

Jetzt vielleicht noch einmal die Rahmenbedingen, welche mich dazu gedrängt haben, eine solche doch etwas umfangreichere Server-/ Verbindungskonfiguration wie in meinem

o.g. Beitrag bereits erwähnt, zu wählen.

Nach meinen Erfahrungen und Recherchen haben wir in Deutschland ein großes Problem mit den Telekom-basierten DSL Internetanschlüssen. Hier fängt meist die Problematik mit

einem ordentlichen Routing und Internetstabilität zu anderen Servern und Ländern.

Ein kleines Beispiel aus der Praxis:

Selber Ort, ein User hat Telekom-DSL (250Mbit), ein User hat 1&1 DSL (250Mbit) und ein Weiterer hat die örtlichen Stadtwerke mit Glasfaser gebucht (100Mbit).

Wenn man nun einen Speedtest auf z.B. speedtest.net macht, sucht sich der Test logischerweise immer den besten Server in der Nähe.

Wählt man aber nun manuell einen Server im Land des emby-Servers aus, sehen die Ergebnisse anders aus.

Alle Geschwindigkeiten sind logischerweise reduziert, aber die DSL Verbindungen sind zusätzlich während des Tests instabil und springen wie wild hoch und runter.

Mit iperf (oder bestimmt auch anderen Tools) kann man deutlich sehen, dass einige Pakete der DSL Verbindungen zwischendurch hohe Latenzen haben.

Teilweise führt das sogar zu Paketverlusten.

In DSL-Stoßzeiten (wenn viele Kunden Zuhause sind und das Internet nutzen) reduziert sich die Verbindungsqualität weiter.

In einigen Foren wurde auch bereits diskutiert, dass, und das scheint für mich logisch zu sein, Netflix/ Google/ etc. reservierte/ gekaufte Bandbreiten bei den Internetanbieter zu haben,

damit deren Services problemlos funktioniert bzw. selbst Routingserver betreiben und die Nutzung sich teuer bezahlen lassen (Sind die ISPs teilweise nicht bereit auszugeben).

 

Das alles fällt nicht sonderlich in´s Gewicht, wenn der Emby-Server direkt im selben Land oder sogar Bundesland wie der User steht/ erreichbar ist.

Also einfach nen Server im heimischen Netzwerk mit Nginx Proxy Manager betreiben und diesen dann mit Port 443 und ner eigenen Domain im Internet freigeben,

wird keine große Probleme bereiten.

Wenn man aber nun, wie ich, User hat, welchen man nicht 100%ig vertraut, wäre es schon ziemlich fahrlässig denen seine öffentliche IP Adresse auf die Nase zu binden.

Also musste eine anonymere Lösung her.
Einen dedizierten Server mit Grafikeinheit zu mieten war zu teuer und den notwendigen Speicher für emby zu buchen außerdem unglaublich teuer.

Stattdessen habe ich mich für einen günstigen VPS (2 Kerne/ 4GB RAM/ 30GB SSD) entschieden. Der alleine ist aber mit einer eigenen Emby-Instanz hoffnungslos überfordert.

Mein Emby-Server selbst steht im heimischen Homelab, welcher über vier virtuelle Maschinen mit dem VPS in Frankreich verbunden ist.

Die virtuellen Maschinen nutzen jeweils eine eigene VPN Verbindung eines VPN-Providers, welcher das Port Forwarding unterstützt. Diese Verbindungen laufen

über unterschiedliche Länder.

Der VPS kann nun über Load-Balancing, den öffentlichen IP Adressen des jeweiligen VPN-Provider Servers inkl. des freigegebenen Ports den emby-Server erreichen.

 

Der Emby-User verbindet sich nun mit der Domain "meinembyserver.de" landet auf dem VPS in Frankreich und der verteilt dank Load-Balancing die Last zwischen den einzelnen

VPN Verbindungen.

Allerdings fängt der Stream bei den DSL-Usern häufig an zu ruckeln an. Emby reagiert offenbar allergisch in Kombination mit Paketverlusten und der längeren Paketwege.

 

Nun hatte man in der Vergangenheit mit Cloudflare die Möglichkeit, diesen als CDN zu nutzen (Content Delivery Network). Sowohl für den statischen Inhalt der emby-Oberfläche,

als auch für die Streamingpakete.

Grundsätzlich gesagt, hat Cloudflare ein riesen Netzwerk an Servern. Ein Server steht bestimmt auch in Deiner Nähe. Somit werden die Wege zwischen den Usern und dem Server verkürzt.

Damit dies aber funktioniert, musste man Cloudflare Zugriff auf die Bilddateien und auch Streaming-Pakete geben. Diese werden dann ganz grob gesagt zum jeweiligen, nahegelegen (zum User) CDN-Server übertragen und zwischengespeichert. Diese kostenlose Möglichkeit hat Cloudflare allerdings abgeschaltet.

Es ist nun nur noch kostenlos möglich die kleinen Bild Dateien für die statische emby-Oberfläche auf die CDN-Server in Deiner Nähe zu übertragen.

(Die Zwischenspeicherung der Video-Streaming-Pakete geht in die GB, wobei die Zwischenspeicherung der statischen Bild Dateien meistens weit unter 1GB verbrauchen)

 

In meinem Fall fungiert der VPS nun als eigener CDN Server, welcher sowohl Bild als auch Streampakete zwischenspeichert.

Damit muss der Emby-User nicht mehr jedes Mal den gesamten Weg für das Videostreamingpaket gehen
(Emby-User -> VPS     statt     Emby-User -> VPS -> VPN-Server -> VM -> Emby).

 

Auch das Springen während eines Streams auf der Zeitachse funktioniert viel schneller und sauberer.

  • Thanks 2
quickmic

quickmic 1605

Posted
Posted (edited)

Meiner Meinung nach ist die Bandbreite gar nicht so das Problem, sondern wirklich die Latenz.

Mein Server steht hier in Oesterreich und meine Schwester greift von Thailand drauf zu. Der Ping kann da schonmal bis zu 200ms brauchen und macht das ganze relativ traege. Wenn das Playback aber einmal initialisiert wurde, geht das Abspielen releativ stabil.

Edited by quickmic
K1ng_Lear

K1ng_Lear 198

Posted
Posted

Ich kenne das Problem. Wen meine Mama, die wohnt nur 20km weg, am Abend streamen will, geht das erst in der Nacht wenn der Traffic in der Stadt etwas gefallen ist. Meine Schwägerin in Asien ein ähnliches Problem beim streamen. Gerade bei der Strecke nach Asien habe ich das immer auf die Distanz geschoben. Dem ist aber nicht so. Wenn ich selbst in Asien bin und streame ist das nicht ansehbar, lade ich den Content aber runter, habe ich eine konstante Übermittlung, wobei Emby beim runterladen irgendwie manchmal zickt. 

Fazit: Könnte man den Puffer einstellen oder generell beim streaming mehr puffern, denke ich, dass man das Problem in den Griff bekommt.

lobschnurr

lobschnurr 6

Posted
  • Author
Posted

Den Ruf nach einem besseren Client-seitigen Puffer habe ich hier schon häufiger gelesen. Schon vor Jahren. Aber so richtig Fortschritt konnte ich auch nicht beobachten.

Ein Freund war gerade kürzlich in Süd-Afrika und der hatte gar keine Probleme mit dem Stream. Lief sogar in 4K ruckelfrei.

Inwiefern zickt emby beim Download denn bei Dir rum?

Übrigens haben ich die vier Ubuntu VMs für die VPN-Verbindungen gegen eine VM mit Opnsense ersetzt. Weniger verschwendete Server Ressourcen und vielleicht dadurch

auch ein besseres Routing.

Und bei meinem größten DSL-Problemfall wurde nun das Wlan optimiert. War wirklich ganz grauenvoll konfiguriert. Fernseher war nur mit 2.4 Ghz angebunden, Router stand

an einer sehr ungünstigen Stelle im Keller und zusätzlich hatte er diverse BT-Geräte, welche den Wifi Empfang gestört haben.

Nun ist der Fernseher mit einem Netzwerkkabel verbunden und zusammen mit dem Nginx Cache sind die Probleme beseitigt.

 

K1ng_Lear

K1ng_Lear 198

Posted
Posted
13 hours ago, lobschnurr said:

Inwiefern zickt emby beim Download denn bei Dir rum?

Irgendwie scheint er den Download manchmal nicht durchführen zu wollen. Ich markiere z.B. einen Film, sage EMBY er soll es mit Auflösung X auf mein iPhone runterladen, dann transkodiert er den Film in die entsprechende Auflösung und stellt die transkodierte Version zum Download bereit aber er beginnt nie damit. Ich kann das Problem meistens lindern wenn ich via VPN zugreife während der Reverse Proxy da irgendwie spinnt. Bei Musik ist das z.B. nicht, die lädt er immer. Teilweise sammelt er auch für jeden Übertragungsversuch einen eigene, transkodierte Datei. 

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing
×
×
  • Create New...