ich777

Ändert sich was wenn du das transcoding stoppst? Ich weiß leider nicht mehr welche balken sich ändern müssen, aber es sieht in deinem Fall nicht so aus als wird die iGPU genutzt, ich glaub du solltest einen Ausschlag bei Graphics pipe haben und noch ein oder zwei anderen. Bist du dir denn sicher das du den Transcode forcierst?

Woher weißt du das? Ist der USB Stick denn noch dran oder hast du den mal kurz abgeschlossen gehabt nach dem Boot? Welchen USB Stick verwendest du denn? Bitte Poste mal deine Diagnostics natürlich wenn diese Meldung aufscheint. EDIT: Ich hab mir erlaubt den Titel des Threads zu ändern.

Wenn du jemand quotest bitte mit einem @ Zeichen und dann musst auch auf seinen Namen klicken ansonst bekommt derjenige keine Benachrichtigung: Hast du denn das GPU plugin dementsprechend auf deine AMD GPU umgestellt was gibt denn der Befehl: radeontop aus wenn du eine Konsole öffnest von Unraid während einer Wiedergabe? Wie meinst du gebraucht? Was meinst du mit testen? Wenn du oben den Befehl ausführst dann müsstest du während einer Wiedergabe last sehen, aber nur wenn du in Jellyfin einen transcode forcierst (Qualität mit dem Zahnrad unten rechts im Wiedergabefenster auf etwas niedrigeres als das Quellmaterial einstellen).

In terms of the container nothing changed, maybe a mod is incompatible or something in terms of the game server itself changed but in terms how the container is working nothing has changed. That's my best guess...

Hast du container im bridge und container im custom: br0 Netzwerk? Falls ja, stell mal in den Docker Einstellungen von macvlan auf ipvlan um (Settings -> Docker -> Advanced View):

There are many different solutions to this. What came in my mind too is that you can turn on Resume After Power Loss in the BIOS and buy such a Timer Adapter thingi for the Wall (I think such a Shelly also supports a Timer functions if I'm not mistaken) so that when it turns on again the Server also turns on, you just have to make sure to turn the Server off early enough so that the Timer doesn't cuts the power before it fully shut down.

Ich verstehe nicht ganz, den Container den du verlinkt hast liefert einen Exporter mit und du musst den nur einbinden: Klick

it fails to initialize fully: Dec 20 09:42:25 Rynvis kernel: NVRM: GPU at PCI:0000:09:00: GPU-e273a6ee-127f-8286-a1ea-e21a0308187c Dec 20 09:42:25 Rynvis kernel: NVRM: GPU Board Serial Number: 1425021077950 Dec 20 09:42:25 Rynvis kernel: NVRM: Xid (PCI:0000:09:00): 31, pid=13315, name=modprobe, Ch 00000003, intr 10000000. MMU Fault: ENGINE HOST6 HUBCLIENT_HOST faulted @ 0x1_01030000. Fault is of type FAULT_PDE ACCESS_TYPE_READ AFAIK this is a common issue and is around for many years. This bug can also happen at run time while the card is in use and will usually cause most systems to hang or leave X in a hanging state. Nothing I can really do about since this is a driver thing that needs to be fixed by Nvidia. I would really recommend that you go that way.

I don't understand, you see the status in the Container log. Did you open up the container console and start a prefill like that? If yes, do you maybe have CA Backup installed? Keep in mind that CA Backup will stop the container while taking a backup by default. Keep also in mind the container is not supposed to be used with the console (only for the first run and selecting games). Usually you set a CRON schedule in the template and after that the container will run the schedule at the given interval and you can view the status in the Docker log. However you can also force the container to always do a check or better speaking prefill on start by setting the Variable "Force Sync" to true. Keep in mind that the container is set by default to clean the log file on every restart so it is maybe a good thing set Log cleanup to false, but in general I would recommend to leave it at false. Hope that helps and explains how the container works.

With this container?

Yes. All packages should work fine. There was a downtime for about 2 months from the TBS package but that has been fixed now.

Are you sure that you've installed the Linux version from the mods and not the Windows version?

Exactly, otherwise PhotoPrism won't work.

I think it is a bit misleading since most people, even until now think that @Squid is the maintainer and if they come here it also looks like he does maintain the plugin. It's okay that you didn't rewrite it but I would still recommend to create a new thread since you are the maintainer now, at least that's how I see it. Basically this is a support thread and people should only come here if they have any issues so I think a new thread wouldn't be too bad. I would start a new thread for the "new" CA Backup put a note here on the first and last page that the "old" CA Backup is deprecated and link to the new thread and of course link to the new thread in the plugin. What do you think about that @Squid?

Good if you are using it with bridge or a custom bridge network like your proxynet but not necessary for custom: br0 networks. Not really, because the default STUN/TURN port is 5349 and I would not change standardized ports anyways because you can cause all sort of weird issues with this. TURN is usually only needed if a relay server is needed for example if two devices trying to talk to each other which are both behind a CG-NAT. Maybe TURN is working for you and it is just displayed wrong in Nextcloud, that's my best guess. Okay then I'm glad that I could help, at least I think so...

Would be interesting what happens when the device is not in your network. The port shouldn't jump to anything else than what you specified in the "PORT" variable from the container, other than that if you change it to "custom: br0" you can ignore the ports which are displayed because basically all ports are exposed and the container is now handled like a computer on your local network and all ports are reachable. Ah, now I get it, you changed the port from 5349 to 5309 <- may I ask why? If you set the PORT variable to 5309 and you are running the container in custom: br0 mode then simply forward the port to 5309 TCP and UDP.

Just my thoughts, wouldn't it be better to start a new thread and rename the plugin to CA Appdata Backup / Restore v3 or something like that because the plugin now has a new maintainer?

Dyndns is not really supported or better speaking well supported for STUN/TURN... I would strongly recommend that you give it's own unique IP and forward the ports (in custom: br0 if possible), I've never tried it to use the same network and won't recommend that. It is possible that it isn't working because of that, are you sure that you've set up your Hair Pin NAT correctly? Have you yet tried it from outside your network?

I'm not entirely sure what causes that in your case but I can only think of an issue with the Kernel itself because 6.11.5 uses a newer Kernel than 6.10 As said, I really don't support the Sleep plugin over here because I know the issues with the Nvidia cards and you are not the first one who experiencing this issue and posting about it here. I would rather go the shutdown method because you don't stress the hardware as much as waking it up and then shutting rebooting again, at least from my perspective.

Please try to restart the Docker service. No, because the plugin simply downloads, installs and activates the driver for the card and as you've said the card shows up on the plugin page so it should work. This is Kernel specific and since the Nvidia driver is a out-of-tree module, so to speak from a third party it is on Nvidia to fix this with newer Kernels, which indeed Unraid 6.11.5 uses. The plugin doesn't need a update and there is nothing I can do about it if it's not working with Sleep and 6.11.5 this is driver specific and the driver is compiled for each individual Unraid version and then uploaded to GitHub. The plugin simply downloads the driver package, installs and activates it. From my perspective not really, the boot takes a bit longer, at least I'm assuming that. powerdown -r Is the command that you want to issue to reboot the server. However that doesn't makes much sense, please do it over WOL or a BIOS schedule <- the BIOS Schedule shouldn't even be hard to set up. Sorry I'm not that familiar with this plugin at all and have never seen it as I usually don't support it and I personally don't see a reason why to use it on a server (even not on a home server), if possible, please use the shutdown instead.

But I see nothing obvious in that Diagnostics, the card is recognized and the drivers are loaded. Can you maybe try to restart (disable and enable) the Docker service after Sleep and see if this makes a difference? You can't reboot the plugin since it's a plugin and if I'm not mistaken you should see the card just fine on the Plugin page or am I wrong about that after the server wake up from sleep? Nvidia and Sleep in general on Linux. Linux is getting better and better with sleep but a few years back it was horrible and caused issues over issues, even when there was no Nvidia GPU involved and even on consumer grade Laptops when you wan't to wake devices from sleep it most of the times won't work properly anymore or won't wake up at all. As said above, this is a server, I would rather recommend that you shutdown your server entirely and boot it back up on a schedule whether you do this through a BIOS schedule or through WOL instead of using Sleep. The output would be interesting after it woke up from Sleep. Oh, I forgot to ask, do you shutdown your server when processes are running on the card or do you stop the processes first?

In general, yes and no. I would recommend that you the readme from the repository which this plugin is based on over here. You have to test if your specific controller is supported and is working with it. Please read the readme carefully because it is also possible that you destroy your RAID controller or your data with this tool.

Are the Diagnostics from before or after a sleep? I have to say that Nvidia and sleep on Linux where never best friends anyways... You find dozens of threads (not especially Unraid related) on the Internet about Nvidia cards not working properly after waking the device from Sleep. In general I really don't support sleeping servers because well, it's a Server and should always run, I completely get the point putting it to sleep but that is not common practice. This is most likely no issue on your side, this is most likely caused because of some change in the Kernel and nothing you can do about. Anyways, please post a Diagnostics file from before it was put to Sleep and a Diagnostics file after it woke from Sleep. Maybe also a screenshot from the plugin page and also from the output from: nvidia-smi after it woke from sleep would be helpful.

If possible that would be nice for testing purposes... Maybe that's caused by some weird power saving measurement from the browser for background tabs.

Because I've seen containers not starting/running properly with older Unraid versions. It was the same when Unraid 6.9 series was around and users where on Unraid 6.8 (I think it was TeamFortress 2 but I really can't remember which game it was). Anyways I only can tell you that I've tested it on 6.11.5 and I'm able to connect to it regardless if I change the server name or fill in my Steam64 User ID...