flyize

Everything, including transcoding, works just fine for me.

Maybe @ich777 can shed some light on this?

I'm pretty sure intel-gpu-top is still required. Is that also installed?

Have you followed the setup instructions and added the device in your Docker config?

Has anyone seen this error and been able to resolve it. I believe it started with v28. Refused to send form data to 'https://nc.domain.com/index.php/login' because it violates the following Content Security Policy directive: "form-action 'self'". I'm unable to login via Chrome/Edge. Firefox works just fine. edit: Seems I asked this a week or so ago and forgot. Apologies. Still would love an answer though!

Anyone else seeing this error when attempting to login from Chrome/Edge? Firefox works fine. Refused to send form data to 'https://nc.xxxxxxxxx.com/index.php/login' because it violates the following Content Security Policy directive: "form-action 'self'".

root@Truffle:~# docker exec xteve_guide2go crontab -l 0 0 * * * /config/cronjob.sh

Correct. Nothing in logs and it works manually.

I've got an odd problem. I'm running xteve_guide2go, and the cronjob.sh file seemingly isn't running correctly unless I manually go in and run it. I can see the timestamps getting changed, so the script is running. But it isn't downloading anything new. Any ideas?

I don't think so. Any chance you have a suggested pattern for backing up Plex?

That folder is full of stuff.

I got the following error when the backup ran last night: [13.11.2023 03:08:18][❌][Plex-Media-Server] tar verification failed! Tar said: tar: /mnt/cache/appdata/Plex-Media-Server: Not found in archive; tar: Exiting with failure status due to previous errors Debug log: 3c4431dd-b78f-4391-963a-871abb2ed18e Thanks for any help.

How do I unmount it then. lsof is blank

Shouldn't it work even if I don't, since zeroing will nuke the partition making a write impossible? That said, I tried to unmount it, but got a 'target is busy' error.

Thanks @mgutt and Google. This fixed a hang for me. Not sure why it didn't run swapoff on its own.

Just happened again. Memory seems fine? truffle-diagnostics-20231010-0850.zip

Will do. I had seutp netdata for that purpose, but it seems that it doesn't store data for very long.

But if I'm really not running out of RAM, and I think the fragmentation issue should be properly band-aided, there's nothing that *should* be causing it. Any ideas on how to further troubleshoot this?

Any chance you have any other suggestions? I thought it was fixed, but OOM is still killing things. I can confirm its not running out of RAM (80GB), I've added a 40GB swap file, and I've started running the memory compact command to defrag the RAM.

Any reason the standard wisdom is that the Docker and VM services need to be shut down to zero out a drive?

How did you determine that it was Unassigned Devices? I too have that installed. edit: Also, after upgrading to the new 6.12 the other day, my server crashed again this morning. Same thing OOM killed everything, but server still responds to pings. I just downgraded back to 6.11 and since I'm headed out of town for a few days, I've set the RAM compact script (posted in the SO threads I linked) to run hourly.

If all my docker and VMs are on a cache drive, and I go into Global Share Settings and exclude a drive that I want to zero - can that be done online relatively safely? I really don't want to have to be without the server for two days while the drive zeroes out.

Would it be possible for someone to add Threadfin to Unraid? Apparently its based on xTeve and possibly in more active development. https://github.com/Threadfin/Threadfin

@shaunvis As expected, @JorgeB seems to be correct in that memory fragmentation was causing my issues. 6.11 seems to handle this *much* better, in that it only seemed to kill a couple of things - and most importantly put it in syslog. 6.12 seemed to kill almost everything, and had ZERO logging of it. I solved it with a swap file, but it could seemingly also be solved by compacting memory according to these threads: https://stackoverflow.com/questions/62077590/why-can-a-user-process-invoke-the-linux-oom-killer-due-to-memory-fragmentation https://stackoverflow.com/questions/60079327/how-to-mmap-a-large-file-without-risking-the-oom-killer/62855363#62855363 So maybe try 6.12 again but with swap and see if it help you too.

Interesting. I assume you can see that I have 80GB in there and I'm pretty sure I'm not hitting that. The way you describe it, its a Linux problem. That seems odd. In the real world, that's solved by adding a swap file?