hawihoney

Hab ich seit Jahren so und niemand war jemals auf meiner Kiste den ich nicht kenne (hab noch Basic Authentication in der htaccess für nicht gewünschten direkten Zugriff). Ich gestehe, wie schon so häufiger, dass Netzwerk absolut nicht meine Stärke ist. Ich habe das damals von den LSIO Docs abkopiert (SWAG, LetsEncrypt). Da wurde das genau so gemacht. Muss Marc doch mal wieder bei mir vorbei kommen und NPM einrichten. Nur so aus Interesse. Du hast 32400 nicht im Router weitergeleitet und in der Plex Konfiguration den öffentlichen Port nicht manuell definiert. Dann in der site-conf alle Referenzen zu 32400 entfernt. Und dann? Kommt doch auch jeder drauf. Bin gerade im Hotel, Bryan Ferry Konzertfilm läuft in der Plex App auf dem Fire-TV Stick im Hintergrund am Hotel TV. Da will ich gerade nicht rumfummeln... nachher sperre ich mich noch aus ...

War no nicht der Standard? Oder hat sich das ab 6.12.x geändert.

Das verstehe ich nicht. Bei mir ist eine proxy_pass Regel für den http Web-Content von Plex auf dem Port 32400 in der site-conf. Als ich den Server vor vielen Jahren aufsetzte hieß es, dass damit eine schnelle Umgehung für statischen Content geschaffen würde. Gibt es das nicht mehr? #PLEX location /web { # serve the CSS code proxy_pass http://192.168.178.35:32400; } [...] location / { auth_basic "Restricted"; auth_basic_user_file /config/nginx/.htpasswd; proxy_pass https://192.168.178.35:32400/web; include /config/nginx/proxy.conf; }

Check mal die Ports. Bei mir: Router (außen > innen für den Unraid Server): 443 > 444 80 > 81 32400 > 32400 SWAG Container Einstellungen: https: 444 http: 81 Plex Fernzugriff: Öffentlicher Port 32400

Dann kann ich nicht mehr helfen. Allerdings kann ich mir beim besten Willen nicht vorstellen, dass sich Plex eine 45er IP aus den Fingern saugt. Da musst Du IMHO ansetzen. Was sagt Dir diese IP? Löse sie mal auf.

Verstehe ich nicht. Was meinst Du mit integriert? Den Relay? Der springt nur ein wenn Plex keine direkte Verbindung findet. Lan=leer ist korrekt 10.10.10.0/24 kann nicht schaden Bei Dir ist aber auf jeden Fall etwas anders konfiguriert als bei mir (DuckDNS/SWAG/Plex). Hier ist lokal/remote zu 100,0% korrekt. Hast Du auf dem Server noch irgendetwas zwischen geschaltet? Die 45.* scheint ja keine lokale IP zu sein. Für mich sieht das korrekt entfernt aus. Bei uns schaltet HomeAssistant permanent die Fire-TVs und LGs und sonst alles gnadenlos an/aus. Hier gibt es in dieser Sache keine Probleme mit Fire-TVs. Die DTS Geschichte kam bei manchen LG Modellen hoch - hat wohl etwas mit Lizenzen zu tun. Auch an unseren LGs steckt ein Fire-TV - wegen dem Magenta TV. Es gibt noch keine App der Telekom für LG, etc. und die Box von denen kommt mir nicht ins Haus. Plex läuft zu 99,9% auf den TVs. Aber wie schon oben erwähnt gibt es extrem selten Probleme mit einzelnem Content - dann switchen wir halt rüber auf den Stick. Beides zusammen ergibt in der Summe 100% für den gesamten Content.

Kurze Anmerkung: Ich verstehe nicht warum so viele mit "sudo" und "docker exec" arbeiten statt die passende Konsole zu verwenden. Jeder Docker Container unter Unraid kommt mit einer passend konfigurierten Konsole. Diese ist mit allem PiPaPo wie User, Umgebung, usw sofort nutzbar: Der lange Befehl oben ist somit völlig obsolet. Es reicht dann i.d.R. nur noch: occ (und hier der Befehl) Das muss doch auch mit Nextcloud funktionieren, oder?

Nur zum Verständnis: Du spielst etwas lokal ab und im Plex Dashboard wird remote Playback angezeigt. Da ist aber etwas falsch konfiguriert. Was hast Du in Plex unter Netzwerk in das Feld "LAN-Netzwerke" und unter "Liste der IP-Adressen und Netzwerke, die keine Authentifizierung benötigen" eingetragen? Zu dem Rest: Nicht alle Plex Klienten können alles. Sogar die GUI sieht oft unterschiedlich aus. Meine Tipps mit dem Erzwingen des Transcodens (Bandbreite runtersetzen) oder der Wahl eines anderen Audio- bzw. Subtitle Streams kennen alle meine User. Es wird extrem selten bei uns benötigt. Aber auch mich trifft es so ungefähr einmal im Jahr beim lokalen Abspielen - und das bei einem Intel W1290P. Bisher haben wir die geringsten Probleme mit den Fire-TV 4K Ultra, LG TV ab WebOS 3.5 und den Samsung TV Plex Klienten. Dazu kommt natürlich die NVIDIA Shield und deren kleine Geschwister - aber nicht die mit 2 GB RAM oder so. Zu wenig RAM kann bei den NVIDIAs kritisch werden. Sieht man ja schon z.B. an den alten 1050ti. Die mit 2 GB RAM zickt, die mit 3 GB RAM nicht.

Das habe ich mit allen Containern und deren /tmp/ so gemacht. Der Plex Transcoder liegt bei mir ebenfalls im Container auf /tmp/. Und das Container /tmp/ ist bei mir auf dem Host immer nach /tmp/<containername>/ gemappt. Es ging mir um den Standard. Wenn der Transcoder im Docker Image bzw. im Docker Ordner werkelt, dann ist das ja wohl ein ziemlicher Flaschenhals - sofern /appdata/ dann auch noch auf dem Array liegt.

Nur so aus Interesse. Was passiert wenn das nicht explizit auf den Host gemappt wird? Landet das im /config/ und somit im appdata Image/Ordner?

In den Container Einstellungen ist es eigentlich richtig. Aber die Shares in Unraid liegen falsch. Du musst nur cloud aufs Array legen und appdata auf die SSD - die beiden sind vertauscht. Das ändert aber nix an Deinem Problem. Das Array wird derzeit bei den o.g. Einstellungen von Mariadb/Nextcloud nicht berührt.

Die Shares für /data/ und /config/ vertauscht. /appdata/ gehört auf die SSD und /cloud/ aufs Array.

Das läuft dann wohl über appdata. Wo liegt das? Das wäre im Container z.B. - je nach Container - /tmp/. Das muss auf dem Host irgendwo liegen. Wo ist das? Bei mir sieht das Mapping so aus: Die Codecs und Bandbreiten sind ein Witz. Die können nur Probleme bereiten wenn der Klient mit HEVC oder DTS überfordert ist. Das kannst Du testen indem Du auf dem Klient Transcoden erzwingst - aber nicht über appdata (s.o.). Setz mal auf dem Klient auf 2 Mbit/s für die Wiedergabe. Außerdem kannst Du Dir mal die CPU Auslastung des Servers anschauen während der Wiedergabe Bei diesen winzigen Bandbreiten, vor allem bei lokaler Wiedergabe, mag das klappen.

@ich777 asked me to add the following to my question above: I'm running three Unraid server: One Unraid server running on bare metal and two Unraid server as VMs on that bare metal server. These two VMs act as DAS (Direct Attached Storage, access thru SMB) only - just the Array. No Docker Containers, no VMs. His idea is that bridging needs to be enabled on the Unraid VMs - it is currently already. Currently: Unraid Bare metal: Bonding=no, Bridging=yes, br0 member=eth0, VLANs=no Unraid VMs: Bonding=yes (active_backup(1)), Bridging=yes, VLANs=no Docker Bare metal: MACVLAN, Host access=no Docker on VMs: Disabled Is this ok? It's running happily since years, currently on Unraid 6.11.5 with Fritzbox DSL IPv4-only.

Is it recommended to make these changes in 6.11.5 before the update from 6.11.5 to 6.12.4-rc18? Or should I update to 6.12.4-rc18 first and apply these changes afterwards?

Ahem, don't I need the ACTION ADD, etc. stuff then? I simply put a Python script to rsync something from A to B into that Device Script field? And that's all? Who does mount then? If this is true, I never got the help text on that page ...

Keine Ahnung, ich denke nicht. Das sind meinem Verständnis nach zunächst einmal zwei Paar Schuhe: 1.) Ein Stick/Device, wie hier in diesem Thread gefordert, steckt immer drin und wird 1x pro Monat automatisch gemounted, beschrieben und wieder abgemeldet --> User Script 2.) Du willst einen Stick einstecken, dann das Skript automatisch laufen lassen, ... --> Device Script Ein Device Skript sieht schon inhaltlich ganz anders aus als ein User Skript. Guck Dir das mal an. Du könntest vielleicht den eigentlichen Job in ein User Script packen und diesen aus dem Device Script aufrufen. Aber so weit bin ich noch nie gegangen. Bei mir rennen manuell/automatisch dutzende Skripte - jeden Tag, jede Woche, jeden Monat, jedes Jahr, beim Start des Arrays, etc. etc. etc. das reicht mir.

Vielleicht sind es hier zwei verschiedene Welten deren Begriffe so nicht 1:1 vergleichbar sind. Vielleicht stammt der Remux ja eher vom Remix und nicht vom Multiplexen. Das würde dann auch wieder zum Duden passen "das erneute Mischen einer bereits veröffentlichten Tonaufnahme". Da geht es zwar nur um Musik aber wer weiß... Da gefühlt eine Trillion Remux und Dubbed Release im UseNET existieren und mit dem Release-Katalog übereinstimmen, verlasse ich mich dann doch eher darauf - auch wenn es vielleicht Deiner Fachkompetenz widerspricht. In dieser "Welt" entspricht ein "Remux" dem Weglassen von Streams z.B. aus einer Bluray sowie dem neuen Verpacken und ein "Dub" dem Hinzufügen von externen Streams z.B. zu einer Bluray. Das steht dann als DUBBED oder REMUX etc. im Header. Gestritten wurde schon ob das Verpacken einer Bluray in einen MKV Container ohne etwas wegzulassen ebenfalls ein Remux ist. Meiner Meinung nach ja. Nur mal zwei wahllose Header aus NZBIndex: Im ersten Fall wurde etwas weggelassen und im zweiten Fall etwas weggelassen sowie etwas Zusätzliches hinzugefügt. In einer NFO sieht das dann wie folgt aus. Es kommt eine zusätzliche Audiospur von der Bluray zur UHD hinzu (Dubbed). Alle weiteren Audiospuren der UHD, als die aufgeführten, wurden weggelassen und das Ganze in einen MKV Container verpackt (Remux): Resident.Evil.Death.Island.2023.German.DTSHD.Dubbed.DL.2160p.UHD.BluRay.HDR.HEVC.Remux-QfG [...] Audio.............: Deutsch DTS-HD MA 5.1 (Blu-ray) @ 2363 kb/s English Dolby TrueHD Atmos 7.1 @ 4809 kb/s English Dolby Digital 5.1 @ 640 kb/s [...] Source............: Ultra HD Blu-ray Wäre blöd wenn Du das mit Deiner Fachkompetenz jetzt auf den Kopf stellst und die Leute etwas Anderes erwarten. Nur zum Verständnis: Du tummelst Dich nur im MicroHD Bereich <SCNR>?

Dann sag das aber schnellstens dem Duden. Denn bei dem heißt Dubben "mit einem Ton unterlegen, vertonen, eine weitere Tonspur darüberlegen".

Nennt sich übrigens dubben. Muxxen bedeutet, dass man aus einem Release nur die Streams verwendet, die man benötigt. Viele Kracher entstehen genau aus dieser Kombination des Muxxens und Dubbens. Aus dem Katalog der Szene-/Release-Begriffe Teil 1: Releasegroups der Untouched Fraktion machen genau das alles ebenfalls. Ich gebe nur eins zu bedenken. Guck Dir Deinen 1 GB Film mit 2 MBit/s Bandbreite mal auf aktuellen oder gar zukünftigen TVs der etwas größeren Klasse an. Wenn aus einem Pixel 10 cm im Quadrat werden, dann wirst Du das bereuen - das betrifft aber nur den Sammler .

Ich rate mal. Es läuft ein Rebuild der Disk3. Die Position des Rebuilds ist aktuell jenseits der 1 TB. Daher werden Disk1 und Disk2 nicht mehr für den Rebuild benötigt. Disk3 wird somit nur noch mit dem restlichen Inhalt der Parity beschrieben. Bis das abgeschlossen ist wird Disk3 emuliert - und zwar durch den Inhalt der anderen Platten. Disk3 ist keine zusätzliche Platte sondern ersetzt eine zuvor schon existierende Disk3. Die alte Disk3 hatte auch 2 TB. Sonst würde sie im Screenshot genullt und dabei die Parity aber nicht gelesen. Passt das?

OMG, wieso sollte man gefühlt hundert Tools installieren? Abgesehen davon ist das NERD-Pack deprecated bzw. sogar schädlich. Ich verfolge immer den Weg nur dann etwas zu installieren wenn man etwas benötigt und nicht vorab alles zu installieren. Unraid selbst bringt alles mit was Du für den Start benötigst. Nur wenige zusätzliche Plugins sind für den Anfänger wirklich, wirklich empfehlenswert: Community Applications - um weitere Programme/Tools überhaupt installieren zu können Unassigned Devices (Pro) - wenn man externe Platten (z.B. USB) oder Ressourcen (z.B. SMB) einbinden will. (Pro für die Unterstützung weiterer Dateisysteme) Dynamix FileManager - wenn man mal etwas hin und her kopieren/verschieben will User Scripts - wenn man Skripte (Bash/Python/...) ablegen, aufrufen oder auch zeitgesteuert laufen lassen will Ich persönlich nutze noch Python, Unrar und Rar für ein bisschen Spielerei. Aber das wars auch schon. Mehr Tools nutze ich persönlich nicht. Alles weitere läuft in Docker Containern (Plex, HomeAssistant, MakeMKV, NZBGet, MKVToolNix, SWAG). Alles vorgenannte wird bei mir benötigt. Sollte ich mal mehr benötigen, dann - genau dann - kann man ja mal auf die Suche nach weiteren Tools gehen ...

Für diese Anforderung machst Du das mit dem User Script Plugin und nicht mit dem Device Script. Die Kommandos hierzu findest Du oben sowie in der Hilfe der Unassigned Devices Seite: Du musst das in etwa so machen: #!/bin/bash #backgroundOnly=true #clearLog=true # Mounten /usr/local/sbin/rc.unassigned mount name=diskname ### Hier machst Du was immer Du machen willst ### rsync -avPX --delete-during /mnt/user/<Deine Quelle>/ /mnt/disks/<Dein USB Stick>/ # Und wieder unmounten /usr/local/sbin/rc.unassigned umount name=diskname Danach noch Cron Einträge für dieses User Script setzen. Die Hilfe hierzu ist auf der User Scripts Seite verlinkt. Deine Anforderung läuft auf "Custom: 0 2 1 * *" hinaus. Einzige Bedingung: Stick bleibt immer stecken wie von Dir angegeben. Ich hänge dazu mal ein Bild vom meinen User Scripts an.

Ganz ehrlich: Bis zu Deinem Post hier hatte auch ich noch nie etwas von dem Format gehört. Musste erst mal googeln um dann auch 720p zu lesen. Woran kann man das erkennen? Wie heißt denn derart modifiziertes Material? Ich habe hier eine etwas ältere Liste mit Release Bezeichnungen. Da steht das nicht drin. Ist das ein Containerformat oder einfach nur eine Komprimierung bzw. ein Reencoden? Nachtrag: Ah, habs gefunden. Es gibt keine offizielle Release-Bezeichnung. Vergiss meinen Text von oben. MicroHD scheint keine große Rolle zu spielen. Bei einem der großen Aggregatoren (z.B. xrel.to, Suche nach MicroHD) gibt es sage und schreibe knapp 70 Einträge. Im UseNET (z.B. NZBKing.com, Suche nach MicroHD) kann man vor ca. 2.500 Tagen (6 Jahren) eine etwas größere Rolle sehen. Danach ging es massiv den Bach runter.

Das passt dann schon eher als die genannten 48 Stunden.