augot

Posting this here for anyone else who was worried about a bunch of "new" errors showing in the Overview page of Admin Settings since upgrading to v28. Apparently this is an intended behavior since the update to the new version (according to this post on the main Nextcloud support forum from one of the devs). Those errors were apparently always there in the log, but in v28 onwards a decision was made to put an alert on the Overview page for admins since you'd otherwise not see errors were happening unless you went digging in the log manually (or had set up some other kind of alerts notification system). Personally, I discovered that my error number kept going up because a couple of videos had become corrupted when backing up from my iPhone, and Memories was failing to index them/ffmpeg was unable to generate preview thumbnails. Since they were trying to do this every hour on the hour, it meant I had a handful of new errors every hour. Deleting the corrupted versions and reuploading clean versions from my phone again fixed it. If you're seeing lots of errors, don't panic that it necessarily means something super serious, but it seems like we're being given a nudge by the Nextcloud devs to take a more proactive approach to being admins (and personally, since it saved me accidentally deleting some stuff I thought I had safely backed up, I'm grateful!), although there is currently discussion over whether there's a better way to handle these notifications without spooking people so much/giving more granular information about what exactly is wrong. Also - the blank log page seems to be an unrelated caching issue. Mine eventually resolved itself on its own, but lots of people over there say their logs reappeared once they cleared their browser caches.

Is there a setting somewhere within Tdarr (or the Docker template) to get it to work with Recycle Bin? Old files are being deleted fully instead of moved into the bin when replaced with new, transcoded versions, and I'm wary of letting it go on my entire library without that safety net.

I'm also having a similar issue since the latest update (28.0.0) - the security warning on the admin overview page is reporting a steadily increasing number of errors in the log, but the log page itself is blank. The log is still being written to (I've looked it up directly on my server), and everything else in my instance seems to be working OK? Still, it's weird.

This is the weird thing - I found that unless I also unplugged the USB cable into my PSU, those lines kept getting re-added to the config file whenever I re-ran sensors (or changed things via the plugin GUI), even if I never selected them to be added. And that was even after removing the CorsairPSU plugin too. So weird!

Anyone have an idea what might cause my router to start blocking Plex, but specifically only the app.plex.tv browser app? Not sure when it started happening because 99% of my usage is via TV/device apps, and also because the localip:32400 connection for the GUI via docker still works and I'm more likely to use that than the app.plex.tv URL. But anything that tries to connect to app.plex.tv via a browser (PC or phone) on my home network gets a "No content available. Check your network connection and verify that any media servers are online." error. Everything else works totally fine, including app.plex.tv from outside my network. So I figure it must be something to do with my router. Nothing's changed in my router's settings that I can identify. Port forwarding rules are the same as they've always been, no new settings or rules have appeared that relate to either Plex or my server. Any ideas? EDIT: Ignore me, it was the DNS rebind issue. My ISP allocated me a new static IP a few weeks ago and I assume they also updated their DNS service to block Plex requests. Changed to Google's DNS in my router settings and it works fine now.

Yep, but also the PSU itself - it was still happening even after I removed the plugin. Had to unplug the USB from the PSU so the sensors weren't picked up at all. Weird bug!

Did you ever find a solution to this? I've started having the exact same problem since the 6.12.* releases came out. x570 Taichi board, all temps and fan speeds were monitored absolutely fine for months before this. If I run 'sensors-detect' in the CLI then reboot, then run 'sensors', I get normal output: nct6798-isa-0290 Adapter: ISA adapter in0: 344.00 mV (min = +0.00 V, max = +1.74 V) in1: 1.68 V (min = +0.00 V, max = +0.00 V) ALARM in2: 3.44 V (min = +0.00 V, max = +0.00 V) ALARM in3: 3.25 V (min = +0.00 V, max = +0.00 V) ALARM in4: 1.81 V (min = +0.00 V, max = +0.00 V) ALARM in5: 1.10 V (min = +0.00 V, max = +0.00 V) ALARM in6: 1.19 V (min = +0.00 V, max = +0.00 V) ALARM in7: 3.44 V (min = +0.00 V, max = +0.00 V) ALARM in8: 3.30 V (min = +0.00 V, max = +0.00 V) ALARM in9: 1.62 V (min = +0.00 V, max = +0.00 V) ALARM in10: 1.02 V (min = +0.00 V, max = +0.00 V) ALARM in11: 632.00 mV (min = +0.00 V, max = +0.00 V) ALARM in12: 936.00 mV (min = +0.00 V, max = +0.00 V) ALARM in13: 920.00 mV (min = +0.00 V, max = +0.00 V) ALARM in14: 904.00 mV (min = +0.00 V, max = +0.00 V) ALARM fan1: 0 RPM (min = 0 RPM) fan2: 837 RPM (min = 0 RPM) fan3: 1229 RPM (min = 0 RPM) fan4: 2122 RPM (min = 0 RPM) fan5: 509 RPM (min = 0 RPM) fan6: 2854 RPM (min = 0 RPM) fan7: 381 RPM (min = 0 RPM) SYSTIN: +43.0°C sensor = thermistor CPUTIN: +36.5°C (high = +80.0°C, hyst = +75.0°C) sensor = thermistor AUXTIN0: +16.0°C sensor = thermistor AUXTIN1: -61.0°C sensor = thermistor AUXTIN2: +12.0°C sensor = thermistor AUXTIN3: +31.0°C sensor = thermistor SMBUSMASTER 1: +69.0°C (high = +105.0°C, hyst = +95.0°C) SMBUSMASTER 0: +41.0°C PCH_CHIP_CPU_MAX_TEMP: +0.0°C PCH_CHIP_TEMP: +0.0°C TSI0_TEMP: +41.0°C TSI1_TEMP: +69.2°C intrusion0: ALARM intrusion1: ALARM beep_enable: disabled k10temp-pci-00c3 Adapter: PCI adapter Tctl: +41.8°C Tccd1: +42.5°C Tccd2: +36.8°C corsairpsu-hid-3-1 Adapter: HID adapter v_in: 230.00 V v_out +12v: 11.98 V (crit min = +8.41 V, crit max = +15.59 V) v_out +5v: 5.03 V (crit min = +3.50 V, crit max = +6.50 V) v_out +3.3v: 3.30 V (crit min = +2.31 V, crit max = +4.30 V) psu fan: 0 RPM vrm temp: +41.8°C (crit = +70.0°C) case temp: +32.5°C (crit = +70.0°C) power total: 176.00 W power +12v: 134.00 W power +5v: 36.00 W power +3.3v: 7.00 W curr +12v: 11.25 A (crit max = +100.00 A) curr +5v: 7.44 A (crit max = +40.00 A) curr +3.3v: 2.19 A (crit max = +40.00 A) They also all appear in the GUI dropdown. However, as soon as I select any and hit save/apply, they then disappear, and 'sensors' delivers this: Error: File /etc/sensors.d/sensors.conf, line 9: Undeclared bus id referenced sensors_init: Can't parse bus name Only rebooting brings them back. EDIT: Oh my god I think I fixed it. The issue seems to be the sensors on my Corsair PSU, which were listed in line 9 of my sensors.conf. Here's my process - using midnight commander, I navigated to /etc/sensors.d/sensors.conf. Completely fresh after a new sensors-detect run, it looks like this: # sensors chip "nct6798-isa-0290" ignore "temp9" chip "nct6798-isa-0290" ignore "temp10" chip "nct6798-isa-0290" ignore "fan1" chip "corsairpsu-hid-3-1" ignore "fan1" Deleting lines 9 and 10 (corsairpsu and its associated fan sensor) and saving immediately returns all other sensors to the GUI dropdown. If I select the fans, CPU, and mobo temp sensors I want, and hit save, they again all disappear from the GUI. However, I can then reopen sensors.conf in mc and see that the corsairpsu sensor has snuck back in along with the other sensors I actually selected in the GUI. Deleting that line again (and also its associated "ignore fan" line) both returns all options to the GUI and makes the relevant temps/fan speeds reappear throughout the system GUI. 2nd EDIT: Unfortunately this does not persist between reboots, but only because the corsairpsu line is re-added to sensors.conf. Deleting it again restores normal functionality.

Riiight, gotcha - conceptually parity works more like it does in the Unraid array (but striped across all disks) rather than the "two copies" version I had in my head. Thanks for clearing up.

Not really a problem as such, but I've just set up a new ZFS pool to try out some of these new features I've heard so much about, and I had a bit of a pleasant surprise. 3 x 2TB SSDs, running RAID-Z, so I had assumed that it would give me a total pool capacity of around 3TB. But it's actually 3.9TB total? Just wondering how the pool could cope with the loss of one drive, with two "copies" of everything, when the total disk space is only 6TB, not 7.8TB...

Ah I came here to post about having this exact issue, glad to see it's already been identified and solved in the new release.

I see - thank you for clarifying.

I see - thank you for clarifying.

Excited to upgrade and finally see what all the fuss is about with ZFS. If I wanted to switch one of my array disks from XFS to ZFS, is it as simple as unbalancing everything off it, stopping the array, formatting the empty disk, then restarting the array and unbalancing everything back onto it? Or will that also destroy parity and require a rebuild of that too?

Upgraded from 6.11.4 to 6.11.5 without any issues except that it still says "Starting services..." on the bottom bar on the GUI dashboard. Can't see anything in the log that hasn't started yet (server's been up for a few hours now) so not sure if it's a graphical bug or not:

Having a weird issue. Not sure when it started but must have been within the last few weeks. Radarr's log is reporting that it doesn't have permission to access the directory assigned to /trash in the Docker template (a default directory defined by the Recycle Bin plugin), so every time it grabs something that's an upgrade for an existing file it can't delete that existing file, and the import fails. It used to be able to delete files fine, nothing's changed in how the Docker template is setup, and the exact same settings with Sonarr don't cause an issue (both container template settings and Media Management settings in-app). Even weirder - I didn't notice it for a while because it seems to work again if the container is restarted (although not always, it can take a few restarts), until eventually it gums up once more. Radarr is also fine creating entirely new directories and moving fresh files into them at all times. Here's an example log from today: 2022-05-20 11:20:33.9|Warn|ImportApprovedMovie|Couldn't import movie /data/completed/[filename].mkv [v4.1.0.6175] System.UnauthorizedAccessException: Access to the path '/trash/[movie name]' is denied. ---> System.IO.IOException: Permission denied --- End of inner exception stack trace --- at System.IO.FileSystem.CreateDirectory(String fullPath) at System.IO.Directory.CreateDirectory(String path) at NzbDrone.Common.Disk.DiskProviderBase.CreateFolder(String path) in D:\a\1\s\src\NzbDrone.Common\Disk\DiskProviderBase.cs:line 189 at NzbDrone.Core.MediaFiles.RecycleBinProvider.DeleteFile(String path, String subfolder) in D:\a\1\s\src\NzbDrone.Core\MediaFiles\RecycleBinProvider.cs:line 94 at NzbDrone.Core.MediaFiles.UpgradeMediaFileService.UpgradeMovieFile(MovieFile movieFile, LocalMovie localMovie, Boolean copyOnly) in D:\a\1\s\src\NzbDrone.Core\MediaFiles\UpgradeMediaFileService.cs:line 62 at NzbDrone.Core.MediaFiles.MovieImport.ImportApprovedMovie.Import(List`1 decisions, Boolean newDownload, DownloadClientItem downloadClientItem, ImportMode importMode) in D:\a\1\s\src\NzbDrone.Core\MediaFiles\MovieImport\ImportApprovedMovie.cs:line 123 Any ideas?