hawihoney

Ok, did reboot to collect required information. 1.) Before reboot. You can see that /etc/cron.d/root and /boot/config/plugins/user.scripts/customSchedule.cron do exist and contain all custom schedules from the User Scripts plugin: root@Tower:~# ls -l /etc/cron.d/root -rw------- 1 root root 1157 Sep 4 14:50 /etc/cron.d/root root@Tower:~# cat /etc/cron.d/root [... Standard Unraid cron jobs ignored ...] # Generated cron schedule for user.scripts 35 4 * * 0 /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/Backup/script > /dev/null 2>&1 30 4 * * 0 /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/Backup Flash/script > /dev/null 2>&1 40 4 * * * /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/Backup Tree/script > /dev/null 2>&1 root@Tower:~# ls -l /boot/config/plugins/user.scripts/customSchedule.cron -rw------- 1 root root 472 Sep 4 14:50 /boot/config/plugins/user.scripts/customSchedule.cron root@Tower:~# cat /boot/config/plugins/user.scripts/customSchedule.cron # Generated cron schedule for user.scripts 35 4 * * 0 /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/Backup/script > /dev/null 2>&1 30 4 * * 0 /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/Backup Flash/script > /dev/null 2>&1 40 4 * * * /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/Backup Tree/script > /dev/null 2>&1 2.) After reboot. You can see that /etc/cron.d/root does exist but does not contain the custom schedules. /boot/config/plugins/user.scripts/customSchedule.cron does exist and does contain all custom schedules from the User Scripts plugin: root@Tower:~# ls -l /etc/cron.d/root -rw------- 1 root root 533 Sep 5 11:44 /etc/cron.d/root root@Tower:~# cat /etc/cron.d/root [... Standard Unraid cron jobs ignored ...] root@Tower:~# ls -l /boot/config/plugins/user.scripts/customSchedule.cron -rw------- 1 root root 472 Sep 4 14:50 /boot/config/plugins/user.scripts/customSchedule.cron root@Tower:~# cat /boot/config/plugins/user.scripts/customSchedule.cron # Generated cron schedule for user.scripts 35 4 * * 0 /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/Backup/script > /dev/null 2>&1 30 4 * * 0 /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/Backup Flash/script > /dev/null 2>&1 40 4 * * * /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/Backup Tree/script > /dev/null 2>&1 3. Update the custom schedules via User Scripts command line tool. You can see that after running that tool the custom schedules reappear in /etc/cron.d/root: root@Tower:~# update_cron root@Tower:~# ls -l /etc/cron.d/root -rw------- 1 root root 1158 Sep 5 11:49 /etc/cron.d/root root@Tower:~# cat /etc/cron.d/root [... Standard Unraid cron jobs ignored ...] # Generated cron schedule for user.scripts 35 4 * * 0 /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/Backup/script > /dev/null 2>&1 30 4 * * 0 /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/Backup Flash/script > /dev/null 2>&1 40 4 * * * /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/Backup Tree/script > /dev/null 2>&1

I just change a digit in one of the schedules and hit Apply. This works always. Just to clarify: I check for this file after the reboot?

After upgrade from 6.11.5 to 6.12.4 where can I see that everything is configured correct? I don't see IPVLAN, MACVLAN or MACVTAB anywhere within the settings: CLI shows that - but shouldn't there be MACVTAB somewhere? root@Tower:~# docker network ls NETWORK ID NAME DRIVER SCOPE 8adcdd141eb5 bond0 macvlan local d0d7de380f93 bridge bridge local bf554ebaaab7 host host local 68626f6bf303 none null local Thanks in advance.

@Squid I think there must be something wrong with User Scripts running on 6.12.4. I own three Unraid Server. During the last week I did migrate all my servers from 6.11.5 to 6.12.4. From that time, after every reboot, the "Custom Schedules" are gone from the "/etc/cron.d/root" file. I have to change a schedule (replace a single digit in the custom schedule and hit Apply) to get them back in the file above. I had to reboot 5 times since last weekend and the custom schedules were gone after every reboot (race condition?, Unraid overwriting after User Scripts start?) Thanks for listening. root@Tower:~# cat /etc/cron.d/root # Generated docker monitoring schedule: 10 0 * * * /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/dockerupdate check &> /dev/null # Generated system monitoring schedule: */1 * * * * /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null # Generated plugins version check schedule: 10 0 * * * /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugincheck &> /dev/null # Generated Unraid OS update check schedule: 11 0 1 * * /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/unraidcheck &> /dev/null # CRON for CA background scanning of applications 13 * * * * php /usr/local/emhttp/plugins/community.applications/scripts/notices.php > /dev/null 2>&1 *** *** These are missing after every reboot *** # Generated cron schedule for user.scripts 34 4 * * 0 /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/Backup/script > /dev/null 2>&1 30 4 * * 0 /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/Backup Flash/script > /dev/null 2>&1 40 4 * * * /usr/local/emhttp/plugins/user.scripts/startCustom.php /boot/config/plugins/user.scripts/scripts/Backup Tree/script > /dev/null 2>&1

They were missing on both migrated servers (6.11.5 to 6.12.4). I would guess that there is a bug in the handling of additional cron entries during upgrade. Thanks.

Don't know if this is a Unraid 6.12.4 thing or a User Scripts problem. I did upgrade two of my three Unraid servers from 6.11.5 to 6.12.4. The third one is still on 6.11.5. On the 6.12.4 machines the custom scheduled User Scripts don't start. Where should I report? Unraid bug or User Scripts?

Does this require two Reboots then or can I upgrade with Autostart disabled, change the settings and then start the Array. Would this Work?

Sofern nicht anders erzwungen schreibt der Linux Kern durch den RAM-Cache auf die Platten. Das ist höchst effizient aus vielen verschiedenen Gründen (u.a. Reduzierung der Schreiboperationen, Performance). Es wird zunächst in den RAM-Cache geschrieben. Mit dem Füllen des Caches beginnt der Kern mit dem Schreiben vom Cache auf die Platte - Block für Block (Pages). Was noch nicht weggeschrieben wurde nennt man Dirty Pages. Durch den RAM-Cache ist jede Schreiboperation i.d.R. am Anfang erheblich schneller. Solange das RAM nicht anderweitig benötigt wird, bleibt das auch im Cache liegen. Deshalb kannst Du ab und zu Leseoperationen durchführen ohne das die Platten aufwachen. Gleichzeitig wirst Du oft sehen, das die Software "Fertig" sagt und die Platten noch schreiben. Dann werden noch die restlichen Blöcke aus dem RAM-Cache weggeschrieben. Manche Software schaltet den RAM-Cache ab (z.B. Datenbanken - die machen das oft selbst). Manche Dateisysteme kommen mit eigenem Caching. Solange man sich aber im Standard Umfeld bewegt ist der RAM-Cache immer dabei.

Wir speichern aktuell 25.000 private Fotos in folgender Struktur: .../Bilder/2023/2023 Was auch immer/20230901 123456.jpg Das ganze wird in Plex geladen und dort getaggt. Bis vor 1-2 Monaten erfolgte durch Plex ein automatisches Geo-Tagging und Bild-Tagging. Das wurde abgekündigt. Bild-Tagging war nicht wirklich sinnvoll. Aber das Geo-Tagging schon. So kannst Du nach Bonn o.ä. suchen. Nachtrag für die etwas älteren hier: Früher hatte man Fotoalben. In die klebte man auch Bierdeckel, Quittungen, Visitenkarten oder auch nur Info-Material. Wir ziehen das auch digital weiter durch: .../Bilder/2023/2023 Was auch immer/20230901 123456.jpg .../Bilder/2023/2023 Was auch immer/Unterlagen/20230901 Bonn Dorint Hotel Rechnung.pdf Da wir dort auch Angebote der Reisebüros, Reisepläne, etc. hinterlegen hat man eine wunderbare Sammlung für einen Ausflug/Urlaub/Aufenthalt zentral an einer Stelle.

The only plugins installed are Dynamix File Manager, Unassigned Devices, User Scripts and Community Applications. No Docker Container, no VM. On Windows Chrome it looks ok. Android Chrome looks like shown above. Mi Browser (Xiaomi) Android looks ok. Another Unraid Server on 6.11.5 looks ok with Android Chrome. Unraid Server on 6.12.4 on same Android tablet looks wrong.

Look at that red square. This is a tile? The area behind the red is white "nothing" here.

Does this look correct? Latest Chrome on Android tablet. Cache was cleared. Thanks in advance.

Und inwiefern hätte ein Minimum-Wert von Shares einen Bezug zu Uhrzeit und Datum? Ein Video-Share erfordert sicherlich einen anderen Minimum-Wert als ein Dokumente-Share. Deshalb ist die Angabe dort genau richtig. Das hat etwas mit den zu erwartenden Dateigrößen zu tun. Ich buche den Kommentar mal auf das Konto "unerfahren".

Hab es doch mal getestet. Die Port-Weiterleitung für 32400 im Router gelöscht, in der Plex Konfiguration den öffentlichen Port entfernt (Checkbox disabled) und Fernzugriff neu gestartet. Es klappt alles, aber jetzt greifen die Klienten mit ganz lustigen externen Ports zu. Ist das ok? Danke schon mal.

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.