alturismo

Docker Tab, oben rechts auf advanced view umstellen, wait einstellen (in Sekunden), advanced wieder retour stellen (benötigt unnötig ressourcen wenn es bleibt)
 
teste dies aber bitte mit max 30 Sekunden oder so, da braucht es normal nicht "ein paar Minuten" ....
 

also auch ich trenne cache und vm nvme drives nach wie vor
 

 
jedoch nicht wegen diesem Grund, ich kann mir nicht vorstellen dass du das bei nvme's merken würdest, ich habe eher ein Problem mit btrfs und daher bevorzuge ich nach wie vor single drive xfs cache drive's
 
aus meiner Erfahrung, robust ... btrfs ... unclean shutdown "warum auch immer" führt (leider) immer wieder zu Fehlern.

der docker (sofern es der von mir ist) aktualisiert standardmäßig um 0.00 Uhr die xml, nur wenn du eine andere Zeit möchtest dann editiere die cron.txt wie beschrieben.
 
ansonsten sollte die cronjob.sh recht selbsterklärend sein ... oder ?
 
wenn es Dir nur um das EPG geht, owi2plex auf yes, deine bouquets (Favoriten Gruppen), ip, root, passwort, fertig
 
den Rest braucht es dann nicht ... sind "Extras"
 

kann es sein dass die shares wo du keine spezifischen smb user Settings hast auf public stehen, sprich, es nichts einzustellen gibt ?
 
Bsp., ein public share

 
Bsp., ein secure share

 
und smb secure mit user Settings hat grundsätzlich nichts mit der HDD Verschlüsselung zu tun falls dass die Frage war.

korrekt ...
 
wenn ich das oben richtig gelesen habe wird LSIO genutzt, sprich kein Apache ... und du hast bereits in allen relevanten .conf Dateien den Client max auf 0.
 
schau mal bitte was hier bei Dir steht, Übersicht, system. etwas runter scrollen ... entweder Standard 1 oder 2 GB.
 

 
im LSIO Docker wird das wie folgt angepasst
 

 
Bsp. wenn ich den Wert ändere auf 16384M
 

 
das Thema wurde auch bereits im lsio NC Forum behandelt ... ich hoffe das löst dein Problem (ich nutze die "Standard" Photo upload Funktion von NC

plugin mover tuning, eine Einstellung wäre dann
 

heißt das der share nicht sichtbar ist, so gewollt ?
 
hier mal wie ich die einbinde, bewusst ohne Schreibrechte per smb, also das auf "yes" wenn gewollt
[_DROPBOX] path=/mnt/remotes/_dropbox comment = browseable = yes # Public public = yes writeable = no vfs objects = [_ONEDRIVE] path=/mnt/remotes/_onedrive comment = browseable = yes # Public public = yes writeable = no vfs objects = [_MEGA] path=/mnt/remotes/_mega comment = browseable = yes # Public public = yes writeable = no vfs objects =  

davon ausgehend dass die Einstellungen auch verändert wurden (nur dann kommt der Apply Button hoch) ... würde ich das mal in einem anderen Browser versuchen ?

was für ein Dateisystem nutzt du als single drive cache ? btrfs oder xfs ?

 
btrfs bringt das (leider) öfters ... da es ein single drive cache ist würde ich xfs empfehlen, würde jetzt jedoch heißen, 1 x komplettes backup des caches, Platte neu formatieren als xfs, Backup retour oder über die Regeln den mover nutzen und appdata etc auf das array und nach xfs format wieder retour spielen. Beides geht NUR richtig wenn der VM und Docker Dienst gestoppt sind.
 
wieso ... am Ende ja deine Entscheidung  das appdata cleanup ist nur mit Vorsicht zu bedienen, heißt aber nicht dass man es nicht nutzen kann, vorher lesen was da steht, entsprechend handeln, alles ist gut ...
 
es gibt diverse Backup Lösungen hier, Luckybackup, scripts, ... von Hand kopieren ... auf externe Geräte, in ein Backup Share, ... was auch immer am Besten zu Dir passt

bitte den Host Zugang aktivieren ... ansonsten kann wie oben beschrieben das nicht gehen ... host <> docker

auch mal im Nextcloud Forum geschaut ?
 
Beispiel
 

das wäre die Grundvoraussetzung ...
 
aktuell versuchst du anscheinend unraid mit Gewalt die "laufende" GPU zu entwenden ... was sicherlich in die Hose geht.
 
mach mal einen screen wie das bei Dir aussieht

 
wenn das deine einzige GPU ist ... wird es eh kritisch ... dann musst du unraid komplett headless booten und hoffen dass das funktioniert, sprich, die GPU auch wirklich nicht vom host (unraid) beansprucht wird, auch ist Nutzung des vbios Pflicht ...
 
den Anfang mit dem Zusammenbau braucht es nicht ... mal anschauen
 
 

ok, also gvt-g in einer VM
 
perfekt, damit ist alles grundsätzlich auch erledigt, daher greift auch die iGPU in der Windows VM ... und auch in Docker(s)
Ich gehe davon aus du hast im Plugin auch die vgpu erstellt zu deiner VM (so sehe ich das mal in deiner xml), bedenken, neue VM, neu zuweisen, ...
 
das macht das plugin für Dich wie beschrieben
 
schau einfach im Gerätemanager nach deiner Grafikkarte, Doppelklick ob es irgendwelche Probleme gibt ...
 
Nutzung in Windows, normal keine größeren Probleme dies umzusetzen, du hast ja bereits eine VM damit laufen. ich empfehle hier nachdem RDP eingerichtet ist evtl. eine Alternative, entweder nativ VNC (Bsp. TightVNC) oder chrome remote desktop (läuft erstaunlich gut) oder parsec (beste Variante was die flüssige Darstellung angeht).
 
zu deinen Abstürzen, ich schließe mal aus deiner Vorgehensweise dass du RDP genutzt hast, was passiert da (leider) gerne, RDP zieht sich mehr vram als es sollte und die gvt-g vgpu schmiert im Hintergrund ab und legt das komplette System lahm ... wenn das passiert und man noch reagieren kann sieht man im syslog viele Einträge "unRAID kernel: gvt: guest page write error, ...).
 
Unser Problem hier liegt bei der Speicherzuweisung, Beispiel, ich habe auch 1GB Ram der igpu zugewiesen, wird aber leider ignoriert ... schön zu sehen bei diesem Befehl
lspci -vv -s 00:02.0 | grep prefetchable Region 0: Memory at 6222000000 (64-bit, non-prefetchable) [size=16M] Region 2: Memory at 4000000000 (64-bit, prefetchable) [size=256M] mehr wie 256mb sind es nicht ... hängt am BIOS der Mainboard Hersteller ... es gibt Anleitung zu "Hacks" hierzu mit custom Bios ... aber ... auf eigene Gefahr, ich mache es nicht
 
mit den anderen Tools wie TightVNC (nutzt auch die igpu zur Hardware Beschleunigung), Parsec und co ... treten diese Probleme nicht auf, ich konnte das nur nachstellen mit RDP Verbindungen, kann man auch recht einfach selbst nachstellen da RDP ja in der Regel die client Resolution nimmt, sprich, wenn dein Mac eine höhere Auflösung wie 1920x1080 nutzt schaltet die VM auch in diesen Modus und benötigt mehr vram ... das crasht gerne dann komplett das System nach einer gewissen Nutzungsdauer, erst die VM, dann unraid wenn man nicht schnell genug ist  daher meine grundsätzliche Empfehlung RDP zu lassen (ist normal auch mein favorisiertes Protokoll, aber ...)
Ich habe dann auch RDP mit erzwungenen max 1920x1080 getestet, läuft länger ok, aber leider ... nicht permanent wie mit anderen Protokollen ...
 
Thema Mac VM und gvt-g, ich mache es kurz, wird nichts nach aktuellem Stand  ich wüsste niemand der das hinbekommen hat (mich eingeschlossen)
du kannst Dich hierzu im macinabox thread eher kundig machen und schauen ob da jemand mehr Input liefern kann, wobei ich damit durch bin und meine macos VM mit Nvidia (High Sierra) dann sauber am Laufen hatte, das Thema macos an sich aber gekippt habe da für mich absolut uninteressant
Empfehlung, aktuelles macos geht ja nur mit AMD Karten, hier eine günstige kompatible besorgen und hoffen das AMD passthrough geht, ist leider anfälliger als Nvidia aber für macos die aktuell einzige nennenswerte Option ...
 
---
was ich noch vorschlage bei gvt-g VM's, wenn RDP, Parsec, ... läuft, den unraid qxl vnc Adapter zu entfernen, das geht leider nur manuell in der xml, dazu folgende Einträge entfernen (löschen).
<graphics type='vnc' port='5900' autoport='yes' websocket='5700' listen='0.0.0.0' keymap='de'> <listen type='address' address='0.0.0.0'/> </graphics> <video> <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> <alias name='video0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </video> somit hast du nur noch einen Bildschirm in der VM ... und lieber nativ VNC wie oben erwähnt dann direkt zur VM (oder parsec oder ...)
 
Zusammengefasst, RDP ist/kann kritisch werden wegen den oben genannten Aspekten zu vram der vgpu ...und ist wahrscheinlich der Grund deiner Crashes.
 
 
 
das wäre jetzt die parallele Nutzung der igpu in einem Docker, Beispiel Mediaserver wie Plex, Emby, ... die intel hardware transcoding unterstützen.
 
Beispiel im Plex Docker als Device hinzufügen
 

 
so kann die Hardware (igpu) auch in einem Docker genutzt werden sofern dieser dies unterstützt (alle gängigen Mediaserver usw ... unterstützen vaapi, QSV, ...) und du musst nicht zum Streaming mit der CPU encoden, interessant für Mediaserver remote Zugang, Beispiel, Plex im Browser was anschauen ... auf einem Mobilgerät ... usw
 
Bei Fragen ... einfach in die Tasten hauen

bist du nicht auf 192.168.2.0/24 ?

ok, du kannst mal versuchen das noch für RDP zu aktivieren, Nvidia opengl
 
https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/291628/adding-an-opengl-support-on-win10-remote-desktop/
 
musst dich jedoch dafür anmelden usw ... ich weiß nicht ob es ok ist das file hier zu posten, daher lasse ich es jetzt mal
 
ob das wirklich etwas bringt bei einem rpi client und remmina wage ich jedoch zu bezwiefeln, es funktioniert, aber ist halt rdp ... und kein streaming.
 
Alternativen
- moonlight am client (rpi) und gamestream in der VM aktivieren, dann mtsc.exe (Desktop) streamen ...
- andere Streaming Clients wie Parsec und co ...
damit bekommst du es flüssig dargestellt da hier auch Spiele gestreamed werden.
 
Zum Gegentest, andere Windows Maschine (Laptop ?) und mal damit zur VM per RDP testen ? wird sicherlich besser sein, aber auch lange nicht "natives Desktop Feeling"

ok, du kannst mal versuchen das noch für RDP zu aktivieren, Nvidia opengl
 
https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/291628/adding-an-opengl-support-on-win10-remote-desktop/
 
musst dich jedoch dafür anmelden usw ... ich weiß nicht ob es ok ist das file hier zu posten, daher lasse ich es jetzt mal
 
ob das wirklich etwas bringt bei einem rpi client und remmina wage ich jedoch zu bezwiefeln, es funktioniert, aber ist halt rdp ... und kein streaming.
 
Alternativen
- moonlight am client (rpi) und gamestream in der VM aktivieren, dann mtsc.exe (Desktop) streamen ...
- andere Streaming Clients wie Parsec und co ...
damit bekommst du es flüssig dargestellt da hier auch Spiele gestreamed werden.
 
Zum Gegentest, andere Windows Maschine (Laptop ?) und mal damit zur VM per RDP testen ? wird sicherlich besser sein, aber auch lange nicht "natives Desktop Feeling"

hast du eine VM am laufen ? wenn ja ... wenn Nein, dafür halt eine einfache VM aufsetzen, installieren, fertig.
 
Vielleicht aber mal anders herum, wenn du viele Medien hast, keinen Medienserver wie Plex am Laufen ? Plex, Emby, ... haben das mehr oder weniger integriert ...
 
Beispiel in Plex wie du Dir Dubletten anzeigen lassen kannst, dann unter Mediainfo die Dateien siehst ...
 

naja, da steht permission denied was ungewöhnlich ist
 
mach mal
 
chmod -R 777 /mnt/user/appdata/prometheus  
wobei das angepasst werden sollte auf deinen Pfad wo du im template angegeben hast.