alturismo

by the mass using this i would rather say no ;) there woul dbe more posts about this. most likely, dns (provider) issue for git access or broken USB devices, or not enough space (rather rare), and so on. may test if your docker updates are still working, may try a VPN to bypass ...

as satip broadcasts tvheadend wont see it in a regular bridge (or custom network in a bridge) you can try the following host mode custom br0 (eth0) on its own IP and you also may add the xml url as RUN_OPTS env in Tvheadend, like described in the tvheadend docs, sample i run dvb-c (fritz) and dvb-s (digital devices) when i google about your device, may should be something like this cant tell as i run different devices. if you want to keep in bridge mode, then you also need to bind ports on tuners and forward them to the docker, each tuner would need 2 ports, sample here 9998-9999 also may some settings specific for your tuner need to be done, read into it if there are issues. so, may just read some tvheadend docs and enjoy then ;)

nunja, wenn du permanent xy GB damit bearbeiten willst bleibt nur eine Lösung mit dGPU um wirklich solche Extreme abfangen zu können. Wundert mich zwar weil mein 40 GB Bilder bequem durch immich gelaufen sind, aber sei es drum, du wirst alles richtig eingestellt habn. Also, extreme CPU oder besser, dGPU für solche tasks dann (GPU Nutzung dann aber auch richtig einstellen). Der genannte Rest ist "unspektakulär", das schafft im normalen Modus so ziemlich alles. lies dich etwas ein, gibt hier ja einige Empfehlungen, aber in deinem Fall eher "oben" angreifen ;)

naja, der sollte bequem reichen, für die intensiven tasks nutzt man dafür die iGPU, openvino bei immich für intel ... was du bisher beschreibst reicht der normal bequem aus.

in short, most likely your provider doesnt like git, as sample from the german forums part https://forums.unraid.net/topic/200128-community-apps-%E2%80%9Edownload-of-appfeed-failed-durch-extrem-langsames-routing-zu-caunraidnet-m%C3%B6glicher-zusammenhang-mit-deutsche-telekom/ you can try using a VPN and see if that helps you, or like mentioned in the error message with a different DNS btw. pushing is not a nice attitude ;)

leider hört man das im Zusammenhang mit der Telekom öfters, siehe auch meinen Kommentar hier

wäre einfach hier anzufügen. das dropdown ist da wenn das array gestoppt ist

checksum bleibt oft nur Dateien beschädigt oder werden fehlerhaft gelesen (Stick) die Prüfung im RAM schlägt fehl daher wäre das einen Test wert, Unraid Stick hat memtest onboard, kann man im boot menu wählen

wenn du sicher bist dass der Stick ok ist, die Dateien nicht beschädigt sind, bliebe noch RAM Test

davon ausgehend du meinst wirklich nur die Downloads und nicht die nachgelagerte Installation der Pakete Ja, kann diverse Ursachen haben, meist liegt es am Routing, Beispiel Telekom und github werden wohl keine Freunde mehr, da hört man dies leider recht häufig, kommt aber auch gerne mal seitens github vor dass die gerade nicht den besten output haben, hatte ich persönlich bisher noch nicht wirklich. Beobachte es weiter, du hast auch sonst keine adblocker oder co in deinem Netzwerk was auch dafür hinderlich sein könnte ? (auch die verursachen gerne mal Probleme)

Moin, "klein" ist doch relativ ;) für das was es macht, vielleicht solltest du anhand eines Beispiels beschreiben für was es angedacht ist. ich sehe es in der Kurzform so das hier "Handy" Bilder und Videos in Ordner kopiert werden (nur Jahr oder Jahr / Monat). Wenn es mehr kann außer die "ausgeprägte" Sicherheit um wirklich alles und aktuell kopiert zu haben korrigier mich gerne. ein Hinweis, du schreibst copy or move, dein "move" ist jedoch "copy and delete" was ein großer Unterschied wäre bei vielen oder großen Dateien, nur als Hinweis ... viele bevorzugen bei Medien einen move (aber den echten move) Danke fürs Teilen wenn es 2jtzt auch nichts für mich ist.

short, nope.

Empfehlung, eher im englischen Teil lesen und nachfragen, da sind sicher mehr unterwegs damit ;) zur NPU mein Stand (ohne eigene Erfahrung), wenn wir von Docker oder VM sprechen sollte das funktionieren, Beeispiel immich vino Erkennung mit zur NPU offloaden --device=/dev/dri --device=/dev/accel wenn es um eine VM geht sollte die NPU per passthrough verfügbar sein /dev/accel/accel0 Lüftersteuerung, schätze du meinst alternativ aus dem OS steuern anstelle der BIOS Kurven, das scheint "tricky" zu sein, gemäß Chipsatz ggf. iT87 driver plugin mal probieren, aber wenn ich kurz die Suche bemühe sieht das nicht gut aus, auch google wirft da nichts Gutes raus, Beispiel wo die 6011 anscheinend auch noch nicht supported wird. GitHubGitHub - IT-Kuny/UGREEN-DXP-FAN-NAS-Driver: UGREEN DXP NA...UGREEN DXP NAS Driver for the system fan. Contribute to IT-Kuny/UGREEN-DXP-FAN-NAS-Driver development by creating an account on GitHub. in Summe, neue Hardware und Linux dauert meist etwas ...

@JorgeB when we look at all this (i am out of ideas here) do you have any idea why this only happens when the disk is set in a startup group? i don't see a causal link... If not, what would be needed for a meaningful bug report?

mal abgesehen davon dass das auch unter /mnt/user so sein sollte (und hier auch so ist) das nur die benötigte disk in den spinup geht, haben wir hier eh wohl eine etwas andere Basis. bei @MAM59 liegen wahrscheinlich auch Fanarts in den Ordnern welche dann "verstreut" sind und nicht unbedingt auf der passenden disk wo auch der zugehörige Film oder die Serie liegt, daher das kaskadierende spinup Thema, daher würden hier disk Shares auch leider nichts bringen .... Ich nutze das jetzt nicht in der Form, weder mit nfo files noch fanarts, plex, emby, ... haben Ihre Datenbank und Ihre Caches wo der Kram dann abgelegt ist, daher macht es für mich in der Form auch wenig Sinn, aber das ist "Glaubensfrage" und OT hier. Bin echt gespannt wenn die disk mal öfters hoch und runter gefahren ist, den Zusammenhang begreife ich halt 0, würde mich auch frustrieren ;)

bliebe ja nur ein bug report, wundert mich zwar irgendwie da ja die Hardware sagt "kein spindown möglich" und die Startup Gruppen ja "eigentlich" nichts damit zu tun haben sollten, läuft ja außerhalb davon ... aber, die Erfahrung zeigt, es ist wohl so ;) Vorausgesetzt, die besagte disk spinned aktuell genau so oft hoch wie in der Gruppe, zum Ausschluss würde ich die einfach mal noch ein paar mal hochfahren lassen, in den auto spindown gehen lassen usw usw ... nur um sicher zu sein das es nicht an X spinups liegt und dann die Hardware sagt "ist nicht".

most informations you get are here when you read up. RTX5080 user here and had no issues with open source drivers. overall, i assume there are plenty RTX5060/Ti users around here also using NV drivers, if there would be a major issue you would find it here ;) and yes, most likely if there are issues, its due hardware combos or bios settings and so on, sometimes trial & error. on your intel platform it should be pretty straight forward, but nobody can tell ... and yes, in the end its the NV driver and not modified, just compiled for Unraids kernel. so may go ahead and get your card and hopefully enjoy oob ;)

kann das aktuell bestätigen, wobei ich sehe dass der Author täglich auch da etwas macht (github), warum jedoch ein Update (ohne Update) immer kommt ... denke wenn er fertig ist wird sich das erledigen ;)

dann würde ich empfehlen einen bug report zu eröffnen ;) https://product.unraid.net/b/unraid-os-bugs

as far as i see, different platforms, how you come to the conclusion its compatible ?

hier war es immer von ~ 70 - 80 MB/s auf > 200+ MB/s wie es auch sein sollte. habe ich eine SMR Platte dabei (gerade als Parity) dann hilft es wahrscheinlich weniger. wundert mich, aber ok, wird wohl in deiner Konstellation so sein. Ich kann es nicht mehr lokal quer testet da ich lokal keine Parity mehr nutze, bin komplett auf Spiegelserver umgestiegen für den Fall eines Ausfalls, aber mal schauen, zumindest einer der von mir "gewarteten" Server hat noch Parity.

Alternative wäre gewesen, Turbo write ON zumindest zum Befüllen https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/overview/#turbo-write-reconstruct-write dann hat man normal native Geschwindigkeit da nicht r/w/m parallel laufen muss, es laufen halt alle Platten dann, das sollte in Summe die schnellste Variante sein. ich schätze eher das ist disk i/o und nicht echt CPU Last, da wartet halt alles bis es weiter geht ...

soweit klar, nur wenn du einen rebuild startest dann schreibt ja einiges neu, sei es drum. Auszug syslog, disk4 hier war die noch da (mit Fehler falscher Key) hier nicht mehr ... sprich, da passt schon etwas nicht (als wäre die disk abgezogen, empty ...) mal egal wie das hier aus geht, in Zukunft sicher die Daten in so einem Fall zumindest lokal weg solange du im emulierten Zustand bist, wenn eine disk emuliert wird, von der disk die Daten weg auf ne andere disk im array (oder unassigneed, oder am Besten extern, oder ...) BEVOR man anfängt hier versucht zu reparieren ! (hier alles von disk4 auf eine funktionierende disk3 in einem vorhandenen Backup Verzeichnis) dann wären die Daten zumindest erhalten geblieben als Kopie, sollte nicht genug Platz sein, halt verteilen, danach dann die Reparatur starten.

ich glaube nicht dass das eine gute Idee war, vor allem wenn auch die Parity Fehler auswirft, dann einen Abbruch zu erzwingen ... Rebuild from Parity ist ja Block based, wenn da angefangen wird und dann abgebrochen wird, hmm. gefühlt würde ich sagen die disk ist jetzt teilweise überschrieben, aber nicht sauber. Versuch, die disk aus dem array entnehmen und per unassigned devices mounten und da versuchen zu retten was zu retten ist. normal würde ich sagen aus deinem Backup wieder einspielen, anhand der Fragestellung befürchte ich jedoch ist keines vorhanden ... ich bin jetzt weder zfs User noch LUKS, aber ich schätze das wird nicht einfach. @JorgeB may an idea, zfs and luks encrypted disk errored out from array, user tried to rebuild anyway, again errored while rebuilding, hard resetted several times, any ideas what to try to may resolve the data again, i suggested to try in UAD and try to mount and encrypt there, but i personally guess ...

your diagnostics, yes, but those looking fine, they dont contain the specific docker log, you can see them here as sample left click the docker icon, a menu will appear, logs ...