MAM59

good guess, but leave out the "v".
 
ghcr.io/blakeblackshear/frigate:0.14.0
 
should do what you want. give it a try (cant harm anything, you can always go back to "latest")
 

Cannot find any proof in your diagnostics, but my educated guess is that your configured name servers are not reachable during UNRAID boot.
They are hidden within a VLAN, which is started quite late, so many timeouts may occur.
 
Set the UNRAID DNS Entries to 8.8.8.8 or something other public and reboot. If the delays are gone, you know what is going on.
 
BTW, it is not needed and not wise to use local DNS servers for UNRAID, there are not many ads to be filtered out. More likely is that you block some updates.
 

Nothing directly connected to network, but a constant repeating error:
 
you UPS (connected through NUT) loses connection. The NUT daemon runs havoc.
This happens with some kind of UPS, the USB Port blocks and the machine becomes unresponsive for some time.
 
This MAY lead to "missing a resume packet" on the LAN (port stopped by flow control, the resume packet could not be received because NUT blocked everything).
 
To see if this is your problem, check two things:
 
1) if the machine is not reachable again, pull out the LAN cable. After a few seconds put it back in. If it works again then, this is likely the described problem above then:
2) deinstall NUT and unplug the USB Connection to the UPS!
 
If the network problems are gone, better run without UPS notifications.
(I even connected the UPS here to a raspberry running NUT, using NUT on UNRAID as a slave. But the "NUT running wild" reappeared on the PI too, UNRAID was not harmed, but the error messages that flooded the logs drove me crazy. So, at the end, I am running an "unconnected" UPS... 😞 The same UPS runs fine on Windows, no dropouts... seems to be a serious driver problem)
 
 
 

Wackel mal am Kabel, oder tausch es aus.

From what I can see, I would guess that you have simply used the wrong ethernet port of the Mobo. One of them is for management only, not for the booted os.
Try to put the cable into the other one and see.
 

Ja das geht in den Disk Einstellungen.
Erstmal den Hauptschalter umlegen:

(Also Datenträger-Gruppen zum Hochfahren auf Ja setzen)
 
Danach tauchen bei den einzelnen Disks neue Einträge auf, mit denen man die Disks den verschiedenen Gruppen zuordnen kann (gleicher Name = gleiche Gruppe).
Die Spindown Zeit ist für jede Gruppe getrennt einstellbar.
Sind sonst nicht sichtbar, deshalb jetzt hier kein Screenshot.
 
Aber, kleine Warnung vorab: Zumindest ich hier hab das Problem, dass jeweils die letzte Disk einer Gruppe niemals Spindown macht. Selbst wenn man sie von Hand runterfährt geht sie sofort wieder an. Das ging mir auf den Keks, deshalb hab ich es hier wieder abgeschaltet. Aber, vielleicht klappt es ja woanders?
 

Also nachdem ich das aktute Magenknurren durch Nahrungsaufnahme kompensiert habe, ist mir noch eine Lösung eingefallen, die sowohl die Speed erlaubt, als auch zukunftsträchtiger als das Derzeitige ist (aber etwas Geld kostet)
 
* Den NetGear Switch schickst Du in Rente, wenn er noch neu ist, schick ihn zurück.
* kaufe ZWEI kleine Switche von der Art: https://www.amazon.de/Netzwerk-Switch-VIMIN-10G-SFP-Ethernet/dp/B0CYFHV1KZ/ref=sr_1_16?crid=T6FXDH5RQPQB&dib=eyJ2IjoiMSJ9.O7_8eepmVeM1WqjlrwNvLYKOi7sqzkhMPugYPM_v0bneUv4cBKdDKESvhfoKn0lrOqzJL0NTKKaQp5Cw_NcsLB2wAvwAJo_98Y_GEOzv4cXdjEnj2IhHsEvJcYtGTmCOWtXnfc-ELfWGaEVIZDamR7WjzUupLNng6LHBAWORSwGHtEzkrFkmL9sBDxAZ5XCJ7WEOBd86t2ht6rgqJ8kCovhiGzHZndT2i9IJaVOgG6A.P6OYIq3tNqLOYozGUwoRoIqfpWTubCa7Afq2MT9KVpE&dib_tag=se&keywords=switch+2.5gbit&qid=1726914212&sprefix=switch+2%2Caps%2C216&sr=8-16
Die gibts in viele Variationen, auch mit 8 Ports 2,5 und nur einem SFP Port, liegen alle so zwischen 60 und 100€. Achte dabei auf möglichst hohe "Switching Kapazität" (dieser hier hat nur 60, das is das unterste Ende der Nahrungskette. Mehr ist zukunftssicherer)
 
* den einen packst Du in Deinen Abstellrauf und schliest dort Router und UNRAID an
* den anderen ins Wohnzimmer (wir haben beim Kauf ja wohl auf "lüfterlos" geachtet, damit die empfindlichen Öhrleins geschont bleiben? 😄) und dort schließt Du "alles andere" an (vielleicht sollte man hier gleich zu einem 8er greifen, üblicherweise wachsen Kinder schnell und die Anzahl der Rechner auch...?)
* und natürlich verbindest Du die beiden Switche untereinander.
 
Was ist damit nun "gewonnen" ?
Nun ja, die Switche untereinander reden dann mit 2,5 G (durch die freien SFP Ports kann man sogar irgendwann auf 10G hochrüsten, aber dazu muss die Leitung absolut sauber verlegt und angeschlossen sein!!!), zum Internet gehts nur mit 1G, zu Unraid mit 2,5G
"unten" (im Wohnzimmer) sind aber nur 1G Geräte bislang, d.h. keiner davon kann die Switchverbindung (und Unraid) voll auslasten. Selbst wenn 2 Leute voll die Filme im LAN kopieren, bleiben noch 500Mb/s über fürs Internet.
Moderne PCs haben inzwischen alle 2,5G LAN Karten auf dem MoBo, so dass im Laufe der Zeit dieser Vorteil aufgefressen wird, aber, wie schon erwähnt, man kann die Switche dann auf 10G hochrüsten, sollte zumindest einer davon ZWEI SFP+ Ports haben, könnte man auch UNRAID später mit einer 10G Karte beglücken und somit wieder Reserven haben.
 
Gerade bei Netzwerken sollte man immer "die nächste Generation" mit einbeziehen, denn sonst muss man wieder Wände aufreissen. Also heute schon mal CAT7 Kabel (oder LWL) einziehen und die Vorteile in 10 Jahren geniessen...
(Nein, hier ist das nicht so langsam, hier läuft jetzt schon alles auf 10G LWL und ist bereit für 100G)
 
Ist aber nur ein Vorschlag, kein Zwang.
 

Jumbo Frames are Dinosaurs, left over from an ancient period.
They are not needed anymore today, and, like you have already noticed, they can produce a lot of grief.
 
First of all, make yourself clear why they have been invented some decades ago. CPUs were single core mostly and slow. NICs were dumb. The CPU had to do all the computations for checking and signing the frames and also to re-request them when something was wrong.
Building and checking the Frame Headers was a tough and time consuming job.
This became more and more ugly with the arrival of 1G ethernet.
So the Idea came up that bigger ("Jumbo") frames would carry more data with fewer headers (and computations).
This wasn`t too bad, but had some serious glitches:
* more data will statistically produce more errors. So more retransmissions and more recalculations would be needed on not-so-stable lines
* all devices on the transmission path (computers, switches and so on) need to be informed about this and support the larger frame type (THIS will be your current problem, it is NOT sufficient to set the Intel Card to 9000, all other Devices on the LAN need to be set to the same value! If one is missing (unmanaged switches are often a real big problem, you cannot see or check what they do or not), the packets are lost!)
 
After some time people realized that the idea was bad. Many old devices did not play along and even newer devices often were incompatible because the frame size is reported different between vendors (your Intel "9000" reads "9024" elsewhere)
 
In real life, jumbo frames never worked really well if enough devices were in the LAN.
 
Technics moved on instead. CPU became faster, but more important: NICs became intelligent!
Now even the cheapest NIC on the cheapest Motherboard offers "offloading", which means, all the computations, checkings and retransmission handlings formerly done by the CPU are now done by the NIC itself and do not bother anymore. The NIC is fast enough to handle full traffic of the desired speed now.
"offloading" usually does Layer2 stuff, but very expensive (Server) NICs even offer Layer 3 offloading, meaning the whole TCP/IP stuff is done on the NIC.
This made Jumbo Frames totally unnecessary anymore and almost everybody stopped using them.
 
So, either turn them off (EVERYWHERE) or try to find the device(s) on your LAN, that do not support them properly and change them.
 
(And before you asked: yeah, they still exist just because they have once existed. Like the 10Mbit/s Ethernet that still is to be handled by every current Device)

Du hast "New Config" nicht richtig gemacht. Bei Erfolg sind ALLE Platten weg und Du musst alle neu zuordnen (natürlich dann die alten NICHT)
 

Du darfst bei der Weiterleitung zu HA kein https verwenden, der HA hat selber kein Zertifikat, das stellt ja NGINX davor zur Verfügung
Also als Ziel bei nginx nur "http://192.168.2.40:8123" eintragen, dann gehts.
 
Ach ja, "internal" und "external" URL kannst Du Dir auch sparen, das führt nur zu fehlerhaften Umleitungen, da über den Proxy ja alles "intern" aussieht für HA.

A longer Answer would be: "Parity is only needed when writing or when reading the data disk fails".
So in case you only read your data and this is successful, she can keep on sleeping.
 

sure, cannot work at all!
On eth0 you have activated bonding in "active backup" mode, but the only bond member is eth0.
Giving eth1 the same address and config does not work (as you might know now already :-.) )
 
Instead, add eth1 to the bond of eth0 (the eth1 config will vanish, it is not needed).
 
But keep in mind, nothing will become faster or better or more reliable. Active backup means that only the first line is used unless it loses connection. Then Unraid switches over to eth1. It helps if the cable is killed by your hamster, but nothing else.
 

just edit the warning level for this disk. NVMes can safely run up 70°, error would be >85°.
 
The next version of unraid will contain seperate warning settings for normal hard drives and SSDs (with a much higher default).
 

you need to read the board's manual VERY carefully!
These boards come "overequipped", they contain more devices that can be handled at the same time. There are evil restrictions which slot can be used for what or if at all!
Look if you have put the card into the correct slot and turn on 4x4x4x4x for this slot (note that many boards only offer 8x8x mode, or even only 8x0x mode if a different slot is used too).
Unless you manage to turn on 4x4x4x4x there will be always some nvmes "missing". In 8x8x mode you will only see #1+#3 and 8x mode will only offer #1 alone.
 
Note also that some processors cut off lanes to the outside and reserve them for the internal iGPU. This also will cut off one or more NVmes from the card (my AMD for instance reserves 4 lanes and the card only shows nvmes 1,3&4)
 
Note too that on most board if you use slot #3 for anything, it will "steal" 8 lanes from slot #1!
 
"bifurbication" alone means almost nothing, the details are very important!
 

You can use any pool.
But take care!
If you click on "zima", the path above maybe vanish and you will have to readd subdirectories and filenames manually again!
It SHOULD exchange only "user", but replaces much more sometimes...
 
BTW: der is another glitch in the current version:
* the paths are shown as /mnt/user (and with the note "path does not exist") at start time
* but if you do not change anything and just hit "apply", UNRAID searches for a pool "cache" and makes the links to "user".
* if there is no "cache" anywhere, it selects the first available pool (in your case "zima", because it is the only one).
 
So, if you apply and look back again later, all will be "moved" to "zima" automatically. There is just no optical feedback at the first setup (would be more clever to check the pools directly and prompt with the correct paths BEFORE you apply)
 
Permissions will be corrected automatically at creation time of the path. Don't worry.

Du kannst sie weiterverwenden, aber nicht bedenkenlos. Docker haben im Array eigenlich nichts zu suchen, sie gehören auf eine eigene SSD (oder "Cache"), möglichst die schnellste NVMe oder so.
Neue Schreibbefehle werden mit die Parität aufgenommen, die Daten bleiben also konsistent. Trotzdem solltest Du recht zügig die defekte Platte ersetzen, wenn noch was kapput geht, sind die Daten dann futsch, denn nur mit der Parität alleine kann man nichts rekonstruieren. Ausserdem ist das "Emulieren" natürlich arbeitsaufwendig und stromfressend.
Apropos stromfressend: Docker und VMs gehören nicht ins Array auch, weil sie niemals schlafen, die Platten also nicht in standby wechseln können und somit Strom sparen....
Dann sind sie NUR auf dem Cache, also nicht mehr durch die Parität abgesichert. Heißt nicht umsonst "move" (verschieben) und nicht "copy" (kopieren).
Sofern Dein Cache keine eigene Sicherungsmaßnahme hat (zB Spiegelung), stuft UNRAID sie dann als "gefährdet" ein.
 

I'm using (used) Mellanox X3 with Multimode Fiber modules (RJ45 get too hot the fanless switch does not like them and often shuts down a port because of overheating). A few ports with DAC. No problems, most of the times full speed (of course, if somebody else is doing something, max speed drops to 50% for that period, so you only get constant speeds if you are alone)
 
I had those Intel cards before, a lot of them, they only caused trouble for me (lost links, dropped connections, stale transfers), maybe it was because they were RJ45 only. Never tested SFP+ versions with fiber or DAC. So they all ended up on ebay, lost a lot of money but its a life saver if you wake up and see all backup jobs run properly over night 🙂
 
Because the X3 is rather old already I guess the next computer will get an X5 or even an X7.
Problem with these cards is that they are always some PCIe versions behind. So they need 8 (very old PCIe 2.) or 4 (PCIe 3.0) lanes to run with full speed. More modern chipsets would allow the same speed with a single lane now already. But nobody builds cards with a modern bus interface 😞
 

Found the culprit (But dunno how to fix it LIMETECH!!!)!
 
The problem is, that the X Server is started before "setxkbmap de" is run (of course, it has to because without it, the keymap cannot be altered at all).
The wanted keyboard type is restored later on, but this only works for LAN connections that are forked later!
So the initial console GUI never gets the proper layout.
 
I wanted to change /etc/rc.d/rc.4.local to see if the setting works if beeing forced.
But before "exec slim" there is no display window to be altered and behind the script never comes across because of the exec...
 
Thing is, the desired keyboard layout need to be stored somewhere and restored after the X server got started but before the login window is shown.
Also, if somebody changes the layout with the GUI, the optional local X Server (including the session) needs to be killed and restarted (with the new layout).
 
(maybe after this change the annoying firefox messagebox offering translation (back to english) will vanish too, I hate it!!!)
 
 

Expect to see a lot of troubles.
 
What you are about to create is a "chicken & egg" problem what we call it over here.
 
The VMs (and Dockers) are started last on UNRAID, but the shares start before already. Without a running DC there may be enormous delays in many (even unexpected) situations.
Remember, once you turn off the UNRAID array, VMs and Dockers are stopped too again, so disk maintanence can become very cumbersome too.
 
Even logins to the webgui may be affected by this.
 
So I would say: AVOID, AVOID, AVOID!
 

try to disable any speedups in BIOS, like "fast boot" or something.
Maybe the stick needs more time to become ready.

Nein, guck mal auf die GUI, da ist bei den Netzwerkeinstellungen irgendwo "interface rules"

Geh dahin und vertausche die beiden Einträge (Drop Down Liste)
Dann neu booten und Du bist fertig!
(Du wechselst damit einfach ETH0 und ETH1, die Einstellungen bleiben)
 

The "path to the exe" won't be very helpful, because python is an interpreter so knowing WHERE python is located is not sufficient.
 
You need to find the commanline arguments of that python task to see which script it is executing.
 
You can find this out by issuing:
 
ps -axf | grep python
 
Sample:
root@F:~# ps axf | grep python 22554 pts/2 S+ 0:00 \_ grep python 19645 ? Ssl 7:08 \_ python3 -m homeassistant --config /config 29547 ? Ssl 0:07 | \_ python3 /app/calibre-web/cps.py 19031 ? S 0:04 \_ /usr/bin/python3 /usr/bin/websockify -D --web=/usr/share/novnc/ --cert=/etc/ssl/novnc.pem 8080 localhost:5900 23412 ? S 0:01 \_ /usr/bin/python3 /usr/bin/websockify -D --web=/usr/share/novnc/ --cert=/etc/ssl/novnc.pem 8080 localhost:5900 here several pythons are working at the same time, so compare the pid (first number) to the one you have seen in top.
 

To close this case: problem solved!
 
I just moved the drive to a different bay within the same controller. Since then, spindown works flawlessly again.
 
There were no other errors besides "no to spindown", so I still dont know what happened. But at least it is gone now .
 
 

are you sure you know what you really have???
There is no Parity Drive within RAID5 and there is no RAID5 within an UNRAID array...
 
In case you are talking about a real UNRAID array (x data drives + 1 parity), yes, you can move the drives freely. If a special sata controller is used for the enclosure, you have to limit the move within this enclosure. But normally you can move them anywhere because UNRAID recocgnizes them by their serial number (some SATA controllers fake / hide the number to the host, this gives stress then)
 

Also das ist eigentlich egal.
 
Ob Du nun per unassinged Devices einen Mount Punkt selber festlegst, oder einen neuen Pool anlegst und dort die Platte reinpackt, macht keinen Unterschied.
 
Aber "sauberer" ist es den Pool anzulegen (und somit auch direkt den Mountpunkt festzulegen). Sonst hast Du später auch noch viel Handarbeit beim Anlegen und Freigeben des Shares.
Wichtig ist eben nur, dass as Primary Storage für den DVR Share nur dieser Pool eingetragen wird und keine Secondary Storage. Dann packt der Mover diesen Kram niemals an.