Andiroo2

Same thing happening here. Quick Sync HW transcode has stopped working on 4k HDR when Tone Mapping is enabled. I can HW transcode 4K and 1080p without issue, but HDR transcode (tone mapping) has stopped working. Disabling Tone Mapping in Plex settings fixes the issue. I am on Unraid v6.9.2, v1.22.2.4282 of Plex and using an i7 10700k CPU. I have this in the Plex container log at startup...not sure if it's related: https://downloads.plex.tv/plex-media-server-new/opencl/debian/plexmediaserver_opencl_amd64.deb: 2021-04-14 11:09:21 ERROR 404: Not Found.

To be clear, my SMB share still works perfectly. I am transferring data to this remote share as part of a backup process weekly and it's working as expected. I am just getting these errors spamming my Unraid logs.

Update: still getting the error messages in the log, starting about 10 minutes later: Apr 12 09:23:05 Tower unassigned.devices: Mount SMB share '//MACMINI-581918/DATA' using SMB3 protocol. Apr 12 09:23:05 Tower unassigned.devices: Mount SMB command: /sbin/mount -t cifs -o rw,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777,uid=99,gid=100,vers=3.0,credentials='/tmp/unassigned.devices/credentials_DATA' '//MACMINI-581918/DATA' '/mnt/remotes/MACMINI-581918_DATA' Apr 12 09:23:05 Tower kernel: CIFS: Attempting to mount //MACMINI-581918/DATA Apr 12 09:23:06 Tower unassigned.devices: Successfully mounted '//MACMINI-581918/DATA' on '/mnt/remotes/MACMINI-581918_DATA'. Apr 12 09:23:06 Tower unassigned.devices: Adding SMB share 'MACMINI-581918_DATA'. Apr 12 09:24:44 Tower emhttpd: read SMART /dev/sdh Apr 12 09:25:44 Tower emhttpd: read SMART /dev/sdk Apr 12 09:25:53 Tower emhttpd: read SMART /dev/sdj Apr 12 09:28:13 Tower kernel: CIFS: VFS: \\MACMINI-581918 Cancelling wait for mid 487243 cmd: 5 Apr 12 09:28:13 Tower kernel: CIFS: VFS: \\MACMINI-581918 Cancelling wait for mid 487244 cmd: 14 Apr 12 09:28:13 Tower kernel: CIFS: VFS: \\MACMINI-581918\DATA Close unmatched open for MID:76f4b Apr 12 09:30:44 Tower kernel: CIFS: VFS: \\MACMINI-581918 Cancelling wait for mid 725165 cmd: 14 Apr 12 09:33:15 Tower kernel: CIFS: VFS: \\MACMINI-581918 Cancelling wait for mid 959576 cmd: 6

Thanks!! I've completed the steps. I will report back on the log status.

It’s a Mac mini. I’ve got a SMB connection from the Unraid server to the Mac via the UD plugin.

Confirmed on my UniFi equipment that nothing has jumbo frames enabled.

I wonder if the Speedtest API has changed…

Having issues with the SpeedtestforInfluxDB docker today. I can't get it to load (after a year of reliable use). Logs show this error immediately upon starting the container: Loading Configuration File config.ini Configuration Successfully Loaded Traceback (most recent call last): File "/src/influxspeedtest.py", line 8, in <module> collector.run() File "/src/influxspeedtest/InfluxdbSpeedtest.py", line 176, in run self.run_speed_test(server) File "/src/influxspeedtest/InfluxdbSpeedtest.py", line 121, in run_speed_test self.setup_speedtest(server) File "/src/influxspeedtest/InfluxdbSpeedtest.py", line 71, in setup_speedtest self.speedtest = speedtest.Speedtest() File "/usr/local/lib/python3.7/site-packages/speedtest.py", line 1091, in __init__ self.get_config() File "/usr/local/lib/python3.7/site-packages/speedtest.py", line 1174, in get_config map(int, server_config['ignoreids'].split(',')) ValueError: invalid literal for int() with base 10: '' I am on InfluxDB v1.8. Anyone else having issue with this container? Thanks!

I'm also hitting the "Cancelling wait for mid" issue on my Unassigned Disk remote SMB share connected to a Mac: Apr 7 14:35:03 Tower kernel: CIFS: VFS: \\MACMINI-581918\DATA Close unmatched open for MID:ad201 Apr 7 14:35:03 Tower kernel: CIFS: VFS: \\MACMINI-581918\DATA Close cancelled mid failed rc:-9 Apr 7 14:37:35 Tower kernel: CIFS: VFS: \\MACMINI-581918\DATA Close interrupted close Apr 7 14:42:37 Tower kernel: CIFS: VFS: \\MACMINI-581918 Cancelling wait for mid 1443535 cmd: 6 Apr 7 14:42:37 Tower kernel: CIFS: VFS: \\MACMINI-581918\DATA Close interrupted close Apr 7 14:42:37 Tower kernel: CIFS: VFS: \\MACMINI-581918\DATA Close cancelled mid failed rc:-9 Apr 7 14:45:08 Tower kernel: CIFS: VFS: \\MACMINI-581918 Cancelling wait for mid 1682517 cmd: 5 Apr 7 14:45:08 Tower kernel: CIFS: VFS: \\MACMINI-581918 Cancelling wait for mid 1682518 cmd: 14 Apr 7 14:45:08 Tower kernel: CIFS: VFS: \\MACMINI-581918\DATA Close unmatched open for MID:19ac55 This goes on and on in my log. Diagnostics attached...thanks! tower-diagnostics-20210407-1631.zip

My original issue was related to Plex RAM transcoding set up incorrectly. I was transcoding to /tmp, which allowed the Plex docker to eventually use all the available RAM in the system without properly freeing it up when it ran out. I changed to a fixed RAM disk instead, set to 12GB, and the system has worked perfectly ever since. When it approaches 12GB used for transcoding, it properly frees up RAM on the RAM disk and transcoding keeps on moving without impacting the rest of the server.

For me it's every hour. A SMART query fires and the drives spin up. Mar 3 07:06:51 Tower emhttpd: spinning down /dev/sdl Mar 3 07:20:01 Tower emhttpd: spinning down /dev/sdk Mar 3 07:20:01 Tower emhttpd: spinning down /dev/sdh Mar 3 07:23:05 Tower emhttpd: spinning down /dev/sdj Mar 3 07:32:17 Tower emhttpd: read SMART /dev/sdk Mar 3 07:32:27 Tower emhttpd: read SMART /dev/sdl Mar 3 07:36:38 Tower emhttpd: read SMART /dev/sdh Mar 3 07:37:00 Tower emhttpd: read SMART /dev/sdj Mar 3 07:48:59 Tower emhttpd: spinning down /dev/sdl Mar 3 07:51:40 Tower emhttpd: spinning down /dev/sdh Mar 3 07:52:02 Tower emhttpd: spinning down /dev/sdj Mar 3 07:58:33 Tower emhttpd: spinning down /dev/sdk Mar 3 08:31:20 Tower emhttpd: read SMART /dev/sdk Mar 3 08:46:22 Tower emhttpd: spinning down /dev/sdk Mar 3 08:48:31 Tower emhttpd: read SMART /dev/sdj Mar 3 08:48:43 Tower emhttpd: read SMART /dev/sdk Mar 3 08:48:56 Tower emhttpd: read SMART /dev/sdh Mar 3 09:04:03 Tower emhttpd: spinning down /dev/sdh Mar 3 09:04:16 Tower emhttpd: spinning down /dev/sdj Mar 3 09:06:16 Tower emhttpd: read SMART /dev/sdj Mar 3 09:10:36 Tower emhttpd: read SMART /dev/sdh Mar 3 09:21:19 Tower emhttpd: spinning down /dev/sdj Mar 3 09:26:00 Tower emhttpd: spinning down /dev/sdk Mar 3 09:30:29 Tower emhttpd: spinning down /dev/sdh Mar 3 09:32:28 Tower emhttpd: read SMART /dev/sdh Mar 3 09:53:16 Tower emhttpd: spinning down /dev/sdh Mar 3 10:00:11 Tower emhttpd: read SMART /dev/sdk Mar 3 10:02:57 Tower emhttpd: read SMART /dev/sdj Mar 3 10:02:59 Tower emhttpd: read SMART /dev/sdl Mar 3 10:04:35 Tower emhttpd: read SMART /dev/sdh Mar 3 10:19:39 Tower emhttpd: spinning down /dev/sdj Mar 3 10:34:30 Tower emhttpd: read SMART /dev/sdj

Would this allow us to connect SSDs to a HBA Controller that doesn't support TRIM now?

Some info from my log right after I manually spin down the array: Mar 2 12:37:17 Tower emhttpd: spinning down /dev/sdl Mar 2 12:37:20 Tower emhttpd: spinning down /dev/sdk Mar 2 12:37:20 Tower emhttpd: spinning down /dev/sdh Mar 2 12:37:21 Tower emhttpd: spinning down /dev/sdj Mar 2 12:38:02 Tower kernel: sd 7:0:4:0: attempting task abort!scmd(0x000000007e3428ef), outstanding for 7017 ms & timeout 7000 ms Mar 2 12:38:02 Tower kernel: sd 7:0:4:0: [sdl] tag#3214 CDB: opcode=0x85 85 06 20 00 d8 00 00 00 00 00 4f 00 c2 00 b0 00 Mar 2 12:38:02 Tower kernel: scsi target7:0:4: handle(0x000d), sas_address(0x4433221105000000), phy(5) Mar 2 12:38:02 Tower kernel: scsi target7:0:4: enclosure logical id(0x5c81f660f5419d00), slot(6) Mar 2 12:38:02 Tower kernel: sd 7:0:4:0: task abort: SUCCESS scmd(0x000000007e3428ef) Mar 2 12:38:04 Tower emhttpd: read SMART /dev/sdl Mar 2 12:38:12 Tower kernel: sd 7:0:3:0: attempting task abort!scmd(0x00000000637eab23), outstanding for 7016 ms & timeout 7000 ms Mar 2 12:38:12 Tower kernel: sd 7:0:3:0: [sdk] tag#3223 CDB: opcode=0x85 85 06 20 00 d8 00 00 00 00 00 4f 00 c2 00 b0 00 Mar 2 12:38:12 Tower kernel: scsi target7:0:3: handle(0x000c), sas_address(0x4433221106000000), phy(6) Mar 2 12:38:12 Tower kernel: scsi target7:0:3: enclosure logical id(0x5c81f660f5419d00), slot(5) Mar 2 12:38:12 Tower kernel: sd 7:0:3:0: task abort: SUCCESS scmd(0x00000000637eab23) Mar 2 12:38:15 Tower emhttpd: read SMART /dev/sdk Mar 2 12:38:22 Tower kernel: sd 7:0:2:0: attempting task abort!scmd(0x000000005b9e412a), outstanding for 7063 ms & timeout 7000 ms Mar 2 12:38:22 Tower kernel: sd 7:0:2:0: [sdj] tag#3236 CDB: opcode=0x85 85 06 20 00 d8 00 00 00 00 00 4f 00 c2 00 b0 00 Mar 2 12:38:22 Tower kernel: scsi target7:0:2: handle(0x000b), sas_address(0x4433221101000000), phy(1) Mar 2 12:38:22 Tower kernel: scsi target7:0:2: enclosure logical id(0x5c81f660f5419d00), slot(2) Mar 2 12:38:22 Tower kernel: sd 7:0:2:0: task abort: SUCCESS scmd(0x000000005b9e412a) Mar 2 12:38:25 Tower emhttpd: read SMART /dev/sdj Mar 2 12:38:32 Tower kernel: sd 7:0:0:0: attempting task abort!scmd(0x0000000000b292e2), outstanding for 7069 ms & timeout 7000 ms Mar 2 12:38:32 Tower kernel: sd 7:0:0:0: [sdh] tag#3248 CDB: opcode=0x85 85 06 20 00 d8 00 00 00 00 00 4f 00 c2 00 b0 00 Mar 2 12:38:32 Tower kernel: scsi target7:0:0: handle(0x0009), sas_address(0x4433221100000000), phy(0) Mar 2 12:38:32 Tower kernel: scsi target7:0:0: enclosure logical id(0x5c81f660f5419d00), slot(3) Mar 2 12:38:32 Tower kernel: sd 7:0:0:0: task abort: SUCCESS scmd(0x0000000000b292e2) Mar 2 12:38:35 Tower emhttpd: read SMART /dev/sdh I have 4 array drives (3+parity) attached to a Dell perc h310 (flashed to LSI 9211-8i). I AM using telegraf but [inputs.smart] is disabled in the config files. SSDs are connected right to MB headers. UPDATE before I posted: I found a separate [inputs.hddtemp] in telegraf.conf and disabled it....it appears to have fixed my immediate spin-up issue.

I just did a quick read on the first Google result for this. Should we be updating our existing cache pools to use this new feature in place of the SSD TRIM plugin? Not sure if this was available in beta/RC for others to chime in.

Same here...was on 6.9 RC2 with no spin down, and now on 6.9 stable I see the same...disks spin up immediately after manually spinning them down too. EDIT: I found the culprit: in Telegraf's config file (telegraf.conf) I had [inputs.hddtemp] enabled. Once I disabled this, my array stayed spun down like a good set of drives should.

"Don't make me tap the sign..."

Interesting, there are some shares listed in my /boot/config/shares that were long deleted from the system. Can I just delete the orphaned .cfg files from that shares file?

Hi all, Similar to user @chizll, I am seeing this message in my logs as well, every time mover runs: Feb 1 09:10:42 Tower root: /usr/local/emhttp/plugins/ca.mover.tuning/age_mover: line 171: [: no: integer expression expected Feb 1 09:10:42 Tower root: Mover not Needed. Feb 1 09:10:42 Tower root: Share Config: /boot/config/shares/Photos.cfg Feb 1 09:10:42 Tower root: Pool Pct Used: 5 % Feb 1 09:10:42 Tower root: Threshold Used: no Feb 1 09:10:42 Tower root: "0 Feb 1 09:10:42 Tower root: 0 Feb 1 09:10:42 Tower root: 80 Feb 1 09:10:42 Tower root: es Feb 1 09:10:42 Tower root: no Feb 1 09:10:42 Tower root: "1 Feb 1 09:10:42 Tower root: no Feb 1 09:10:42 Tower root: "1 Feb 1 09:10:42 Tower root: no Feb 1 09:10:42 Tower root: =" Feb 1 09:10:42 Tower root: no Feb 1 09:10:42 Tower root: =" Feb 1 09:10:42 Tower root: es Feb 1 09:10:42 Tower root: no Feb 1 09:10:42 Tower root: no Feb 1 09:10:42 Tower root: no Feb 1 09:10:42 Tower root: =" Feb 1 09:10:42 Tower root: es Feb 1 09:10:42 Tower root: 10 This same block of log messages displays for every share in my cache. If something IS moved from cache to array for that share, the "integer expression expected" message doesn't show up. The mover appears to be working correctly, so I just wanted to share in case this isn't expected. I am using cache % used (80%) and file age (10 days) in my Mover settings, and I am on RC2. Thanks!

Did you try to manually match a file in the WebUI yet? That’s where I was prompted to select the license file when I moved from Windows Filebot to Docker.

I set this docker up today and was pulling my hair out about why I couldn't get my apps set up correctly...the docker was complaining that the challenges were failing. I tried all kinds of things but noticed that while the docker settings showed ports 1880 and 18443 for the internal ports, the docker allocations section showed 8080 and 4443 instead. I changed my port forwards to those ports and BOOM, worked first try. Is this expected? Here are my docker settings, but 1880 and 18443 don't work for me:

OK, I can script something that will clean out that file regularly...thanks!

Is there a way to not use the amc-exclude-list.txt file? I'd like file to re-process even if they have been processed before.

I’ve created a 4GB Ramdisk folder for Plex transcoding and it’s working perfectly. It fills up and then Plex clears it out seamlessly. Thanks again for the reply.

Thanks. First line of the plugin is the appdata location. Duh.

This is a 6.9.x question. Not sure where I should put it. I have moved my appdata folder to a secondary cache pool. Will the plugin be updated to support this, or should i move it back to the main pool to use this plugin? Thanks!