KYThrill

I am having a similar problem. I was using an old version of the plug in from December today, cleaning up old files. Everything was working fine. Fix Common Problems kept bugging me with a pop up, and it was because I had several plugins out of date. Recycle Bin was one of them. After the update to the 2/10 version, Recycle Bin doesn't seem to work at all. No entries are being made in the log file. If I delete a file (anything from 200 KB to 5 GB I've tried) it is immediately deleted. I can watch the available space on the drive increase instantly. Before it didn't increase unless I emptied the bin. I tried uninstalling and reinstalling, but that did nothing. Which I wasn't able to reboot between uninstall and reinstall, because I am 8 hours into a 24 hour preclear. I will be able to do more tomorrow after that is finished. But updating from a December build to 2/10 build seems to have completely broken Recycle Bin for me. Also, I tried deleting the .Recycle.Bin folder in one of my shares and then deleting a file out of it. It did not recreate the folder.

Well, I think I figured out the issue, and it has nothing to do with the docker. I tested the network connection up to 75 Mbs connection from the server to player, so no reason to think it is a network bottleneck. The max possible bit rate for any type of Blu-ray is 54 Mbs. But what is happening is that Plex is direct streaming the video (no transcode), but it is transcoding the audio on the fly. It doesn't appear that my Sempron's have enough juice to handle the audio transcoding. Most of these Blu-ray rips have DTS-HD or TrueHD 5.1/7.1 audio. Both players are just connected to 2.0 audio devices, so Plex is trying to transcode before streaming and then probably trying to do some sort of sync betwen direct video and transcoded audio. However, the Dune and Kodi accept the full audio stream, and their hardware would mux down to 2.0 to pass to the TV. So the server doesn't need to handle this task. I guess unless I up the CPU's or add a GPU to the system to help transcoding, Plex is out as an option. I guess I can investigate Emby... Apparently you can disable transcoding on Emby.

It's offered through unRAID's Community Applications, so why is it included if unRAID community doesn't want to discuss it?

This is actually a question about the Plexinc docker for Plex Media Server, but I can't find a support topic for that version, just this one. I wanted to know if there are any settings that would reduce buffering and micro-stuttering? I think I have it set to play the original stream, and the info on playback says it is original (1080p blu-ray rips to MKV). So no transcoding or anything like that happening. For background, I've been running multiple unRAID servers for 10 years now. They feed Dune Media Players and I have really had zero complaints using those for a decade now. But Dune is pretty much obsolete and DFI is unsupported. I've had to make several patches now to DFI code just to keep API's scraping. So I want to move to something more modern. So as a test case, I have setup my PC and one Nvidia Shield 4K with both Plex and Kodi. I installed Plex Media Server on my unRAID via docker. The two Kodi installs are just using separate local indexes for the time being. The two boxes are getting Plex data from the media server. Both use Gigabit Ethernet, not Wi-Fi. All media files are on the same server as the Plex docker. My problem is that Plex buffers every minute or two, and has these 2-3 second microskips (playback just skips ahead) when it is playing. It probably buffers for nearly a full minute at the start of a movie, before even attempting to start playback. Content is pretty much unwatchable. However, the same content played back with Kodi is perfect. The Kodi playback starts pretty much instantly (just the HDD spin up time, if required). This is happening on both the PC and the Shield TV. I know too many people use Plex for this to be a problem for everyone. Is Plex, even if not transcoding, heavily dependent on unRAID CPU? For low power consumption, I use some lower end CPU's in unRAID (Sempron 145's). But this has never been a problem for the Dune's and doesn't seem to matter for Kodi either. I will also add that memory consumption goes to 90% when playing back through Plex, with the media server running. Hoevers at 81% with Plex running, but no stream playing. With the server off, memory is about 50% used when playing a Kodi stream. However, I also get flawless Kodi playback the Plex Media Server running (about 86% RAM usage). My playback issues seem to be a Plex problem, but I have no idea what it could be. Can anyone help? Other than these playback issues, Plex is great for management, but I will have to toss it if playback is going to buffer.

Well, my unRAID apparently decided to make a liar out of me. After clearing the statistics yesterday, and having it sit for over 24 hours with no writes (at least that I initiated), all the drives still read 0 writes, except for one 4TB, which shows 36 MB of writes. It also shows 22 MB of reads, which is odd, because there is no file on that drive smaller than 1 GB. So it wasn't a file transfer. I'm preclearing a disk, but as soon as that is done, I'm going to do a parity check just to see if it says anything.

I should add that I have added some plugins that I didn't use before. Could any of them be consuming drive space, without adding a file to the directories. Community Applications Dynamix Cache Directories Dynamix SSD Trim Fix Common Problems Statistics Docker is disabled. I just reset statistics, so I will see what happens in the next hour.

Does anyone have any idea if unRAID 6.4 could suffer from parasitic drive writing bug? For example, I have some drives in my array that I rarely ever write to. The remaining capacity on one had been 204 GB for over a year. Then I switched to unRAID 6.4 a week ago. Now I consistently see these small writes to the drive, 4 MB here, 4 MB there The free capacity on the drive is down to 196 GB now (so 8 GB of data written to it in a week, since switching to 6.4). However, there are no new folders, and no new files on the drive. This seems to be occurring on every drive, and not just one. I cleared the stats on my drives, and over night, every drive showed at east 80MB of writes, with some showing more. I rebooting about an hour ago. Every drive created at 4 MB of writes immediately upon the reboot, with some as high as 18 MB. Since then, the drives showing 4 MB of writes are now showing 16 MB of writes (the highest showing 41 MB), yet I have made sure that not a single thing was written to unRAID during that one hour period. What could this be? Is unRAID somehow using some sort of disk caching now to run the OS? All my drives just seem to be loosing storage space while just sitting, with no new files being added? In my 8 years with unRAID, I have never noticed this behavior, but it seems to be constantly occurring after a switch to 6.4. Any ideas? What could cause this behavior?

Didn't even think to look at parity check history. Averages around 13.5 hours at around 82 MB/s on average. Don't have any numbers from 5.X. Was probably faster back then, because I switched to 6.1.6 to add 4TB drives. So all 5.X checks would have been against all 2TB drives, and recent numbers from history are a mix of 2 and 4 TB drives. That 80+ MB/s range is what I was seeing in 5.X too.

I'm also looking at getting an Athlon X4 615e, which is 4-core and still 45W like the Sempron. That should be more than enough to run MariaDB and a headless Kodi, if I go that route.

I really didn't time any parity checks and it has been a couple of years since I switched from 5 to 6.1.6. I usually start my parity checks at night before I go to bed, and when I get home from work the next day, it's finished. So fast enough for me. I want to think the time estimate is normally around 14-16 hours, but I don't remember exactly. It's 19, 2 and 4 TB drives. Almost ready to put in my first 8TB parity and 8TB data disk, so I expect parity check times to be increasing soon.

Well, for better or worse, I changed two things... I have not seen a CRC error on Teracopy yet, so fingers crossed (but it hasn't been a week yet, and I was seeing 1-2 errors per week). Reviewing Linux kernel bug logs, I found many past issues with Samsung SSD's. Apparently they are not a good choice for a Linux device. However, there were many fixes for Samsung SSD's, spread over various kernel versions. One thing not working correctly was TRIM. So the first thing I did was update to unRAID 6.4 (from 6.1.6), just to get the newest version of the kernel as possible. I also installed the Dynamix TRIM plugin and set a daily schedule for that. The second thing I did, at the same time (I know, once change at a time is best) is change the SSD formatting to XFS. I had found numerous reports of data corruption using BTRFS or EXT4 on Samsung 850 SSD's. They don't seem to play well together, likely because of Samsung's Linux bugs in firmware. Often, when a user was getting data corruption with either of these, they would switch to EXT3, and everything would be fine. My theory on this is that EXT3 doesn't support TRIM, but EXT4 has TRIM support. Samsung acknowledged a buggy TRIM support for Linux (but works in Windows), which lead to kernel fixes to work around Samsung's implementation. So TRIM doesn't play well on Samsung SSD's, depending on file system. XFS looks like it supports TRIM (fstrim/discard), but I read some more info that indicates that may be misleading. The reason is that with XFS, TRIM is disabled by default. The preferred method for TRIM with XFS is to call it, which you can schedule with cron (which is what I think the Dynamix plugin is doing). So everything appears to be working, but I would not advise anyone to put a Samsung SSD (or M.2) into an unRAID machine. It seems like using this combo together could be risky. But since I already have one, since this is just the cache drive, and since XFS/Dynamix plugin seems to workaround the problem, I don't have much at risk.

Yes, I've been running it since 5.0.2, but no problems with unRAID 6.1.X. I just updated to 6.4, but didn't see a workload increase because of that (CPU still around 4% and RAM around 20% utilized). However, I did enable Docker (first time) and added MariaDB. Memory is up to 56% and 22% CPU while idling. I doubt I have much capacity to do anything else and keep some overhead. I will need to see what happens to system resources if I have to serve up files to 3-4 clients. Docker/MariaDB may have to go, or system be updated. Fortunately, I think my MB will accept up to an 8-core Phenom, and is only using 1 stick of RAM, so tons of room to expand on that front, at the cost of power consumption. In the past, serving up files to 3-4 clients with a 54TB server has averaged less than 100 Wh power consumption. At idle it is around 20 wH. I'll miss the power consumption as I update.

1 pass of memtest and 0 errors. I know, just one pass, but...

Does either docker add much overhead to the hardware? Curernt only use 24% of 2GB and CPU is hardly ever over 4%. May go up around 20% when a couple of people watch something. But it is just a single core CPU... so don't know how much I can expect unRAID to do.

The only advantage that I see to the shared DB is the ability to pause on one machine and resume the same spot on another. Or is that only something Emby can do? To throw another wrench into things, my current Dune/unRAID configuration is offline. It is on a standalone sub-net in my house. I keep it isolated from all other PC's and outside influences to prevent ransom ware, file theft, etc. I have a dual NIC PC. About once per week, I connect a physical cable to my second NIC on my PC. I copy over new files and scrape DFI data, run goodsync to sync the DFI data to all my Dunes, and then pull the plug on the ethernet cable. That brief 30-60 minute period once per week is the only time there is any potential threat exposure to my unRAID. Trying to figure out a similar process to work with Kodi.

Also, may be important: Jan 1 21:55:34 TOWER kernel: ata5.00: supports DRM functions and may not be fully accessible Jan 1 21:55:34 TOWER kernel: sd 1:0:0:0: Attached scsi generic sg1 type 0 Jan 1 21:55:34 TOWER kernel: ata4.00: configured for UDMA/133 Jan 1 21:55:34 TOWER kernel: ata5.00: disabling queued TRIM support Jan 1 21:55:34 TOWER kernel: ata5.00: ATA-9: Samsung SSD 850 PRO 256GB, S39KNX0JA32484E, EXM04B6Q, max UDMA/133 Jan 1 21:55:34 TOWER kernel: ata5.00: 500118192 sectors, multi 1: LBA48 NCQ (depth 31/32) Jan 1 21:55:34 TOWER kernel: ata5.00: supports DRM functions and may not be fully accessible Jan 1 21:55:34 TOWER kernel: ata5.00: disabling queued TRIM support Jan 1 21:55:34 TOWER kernel: ata5.00: configured for UDMA/133 ATA5 seems to be the SSD drive. After the first mover csum errror, this happened: Jan 4 21:26:42 TOWER kernel: ata5.00: exception Emask 0x10 SAct 0x7ffeffff SErr 0x400000 action 0x6 frozen Jan 4 21:26:42 TOWER kernel: ata5.00: irq_stat 0x08000000, interface fatal error Jan 4 21:26:42 TOWER kernel: ata5: SError: { Handshk } Jan 4 21:26:42 TOWER kernel: ata5.00: failed command: WRITE FPDMA QUEUED Jan 4 21:26:42 TOWER kernel: ata5.00: cmd 61/40:00:88:f7:79/05:00:00:00:00/40 tag 0 ncq 688128 out Jan 4 21:26:42 TOWER kernel: res 40/00:90:48:b3:79/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Jan 4 21:26:42 TOWER kernel: ata5.00: status: { DRDY } Jan 4 21:26:42 TOWER kernel: ata5.00: failed command: WRITE FPDMA QUEUED Jan 4 21:26:42 TOWER kernel: ata5.00: cmd 61/40:08:c8:fc:79/05:00:00:00:00/40 tag 1 ncq 688128 out Jan 4 21:26:42 TOWER kernel: res 40/00:90:48:b3:79/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Jan 4 21:26:42 TOWER kernel: ata5.00: status: { DRDY } the failed command portion (yellow and three lines after) is repeated 30 times or so, and ends with: Jan 4 21:26:42 TOWER kernel: ata5: hard resetting link Jan 4 21:26:43 TOWER kernel: ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Jan 4 21:26:43 TOWER kernel: ata5.00: supports DRM functions and may not be fully accessible Jan 4 21:26:43 TOWER kernel: ata5.00: disabling queued TRIM support Jan 4 21:26:43 TOWER kernel: ata5.00: supports DRM functions and may not be fully accessible Jan 4 21:26:43 TOWER kernel: ata5.00: disabling queued TRIM support Jan 4 21:26:43 TOWER kernel: ata5.00: configured for UDMA/133 Jan 4 21:26:43 TOWER kernel: ata5: EH complete And after checking the log, the mover csum error hasn't happened as much as I thought. It has happened 3 times in 16 days, and only one of those three times was a file that Teracopy also failed. The other two were files Teracopy moved with no errors. And all the Teracopy files that error, only one had a mover error. Weird.

For 8 years, I used a regular Samsung HDD for a cache drive. I transfer all the files to my Dune using Teracopy, with checksum verification. I recently decided to replace the HDD with a Samsung 850 PRO SSD. It is btrfs (I don't remember if the HDD was, I think it may have been xfs). I've had it in for about two weeks now, and probably have had a dozen times where Teracopy gave me an error because checksum failed verification (copying from my PC to unRAID). I've had to try copying a file as many as 3 times, before eventually passing checksum. I've never had to do that before. Checking my logs, I am seeing several times a week where Mover is also giving checksum errors and repeatedly needing to copy a file. Jan 15 03:44:54 TOWER kernel: BTRFS warning (device sdf1): csum failed ino 520 off 4287762432 csum 2562197151 expected csum 1350497962 Jan 15 03:44:54 TOWER kernel: BTRFS warning (device sdf1): csum failed ino 520 off 4287762432 csum 2562197151 expected csum 1350497962 Jan 15 03:44:54 TOWER kernel: BTRFS warning (device sdf1): csum failed ino 520 off 4287762432 csum 2562197151 expected csum 1350497962 I get errors like this (sdf1 is the cache drive) during the mover process, and it will try again. If eventually unable to move without csum error, it just errors out, leaves the file, and moves on to the next. I've never seen this kind of error in 8 years (admittedly, don't check every night, but never saw one). Lot's of people use SSD cache drives. What could be wrong? Should I witch to XFS, like the old HDD? When I check the SMART data, I only have 1 UDMA CRC error count. I think if I had bad cabling, this number would be higher (386 hours powered on). There are no other errors of any type indicated in the SMART data. My only other thought is that I have some bad RAM. I have had a stick go bad in the past, which caused a failed CRC check on every file transfer. Just seems odd that this started happening the first day after installing the SSD (SSD is physically far away from RAM, so shouldn't be any type of electrical noise issue). The other wrench in that though, is that about 10% of my transfers from PC to unRAID are not to cache drive, but directly to array HDD. In the same 2 weeks, none of those transfers have had a checksum failure. Obviously, mover doesn't move those, so no data point there. It seems like if it were RAM failing, at least one of those would end up with an error too. Any ideas?

I've been using unRAID for a number of years to run a couple of servers. One of them is simply a media server that feeds MKV content to 5 Dune Media Players. The writing is on the wall that the life of this Dune network is limited. I've ordered a Pi3 and plan to install LibreElec to run Kodi. My unRAID is pretty vanilla. I don't run any Dockers. I don't run any VM's. Hardware is only a Sempron 145 with 2GB RAM to minimize power consumption. But I'm sure there are some folks out there serving up content to standalone Kodi boxes. What am I looking at to set this up? Is it a mySQL docker? MariaDB? Emby? I see lots of threads for troubleshooting people's setups, but couldn't find a primer for getting started with unRAID. Any help would be appreciated. Thanks!

I am a bit confused about why you are turning off autoneg. As I was looking into this parameter, I seemed to get the sense that this is the automatic negotiation of the NIC connect speed. Am I totally confused or is there some other issue that I am not aware of? This is autonegotiation of flow control. There are many autonegotitations. If you are connected to a switch that has flow control you can't disable, then if you don't turn autoneg off, flow control will automatically turn back on the instant you turn it off (so it will look like rx off does nothing).

So, are you getting more throughput? And as a second piece of information, how did you disable the flow control? Reason for Edit: Removed reply from within Quote. It's hard to say on the speed. The top speed is not any faster. However, when I charted data transfers previously, the charts almost looked like a sine wave (I guess from the pauses). Now they are running at the same top speed, but the speed is staying consistent. So I think you would have to be transferring more data in a given period of time. Copying to my cache drive doesn't feel a whole lot faster, but copying directly to a disk in the array definitely feels a lot faster. First you should check to see if flow control is your problem (See the link I posted earlier). The best way to disable it is to turn it off at the switch/router (if possible). Enabling QOS on your router will also disable flow control. If that doesn't work, you can manually turn it off with: ethtool -A ethX autoneg off rx off Instead of ethX, use whatever your adapter is in you system (eth0 in mine). ethtool -a ethx will show your NIC's current status. Up to 410+ million received packets and still just 1 drop.

Well, So far out of 186+ million packets received, I have had 1 drop. So I believe what was happening before was receiver buffer would fill up. With flow control, a pause command would be issued until the network card got its regularly scheduled CPU time to flush the buffer. This pause causes a certain number of packets (probably ones in transit or software, but not yet buffered) to be dropped. But now, when the buffer fills, the NIC uses an IRQ to take immediate control of the CPU (at the expense of other programs) to flush the buffer. So more CPU usage, but no dropped packets, which is fine for me since I'm only using 20% of my CPU anyway.

All right, I figured out my Dropped RX packets... 98% of them were caused by flow control. On earlier versions of the Linux kernel, flow control was disabled on Intel NIC's. Then it was enabled. So upgrading unRAID results in a kernel with flow control active. My stupid router doesn't allow flow control to be disabled and doesn't have QOS (which disables flow control). But I disabled it at the NIC, and 98% of dropped packets went away. I was still getting a few and the rest were resolved by increasing the size of the RX buffer (default 256 and changed to 1024). The rest were being caused by multicast packets that somehow weren't being routed correctly. I don't use multicast anyway, so I disabled multicast on the router, and the errors completely stopped! Now to transfer another 100 GB of data and see how it compares...

And here is a similar problem with Fedora. One version no dropped packets, update and poof, dropped packets. http://forums.fedoraforum.org/showthread.php?t=297243 But apparently they are not real dropped packets. I'm trying to read through, understand what was done, and apply it to troubleshooting on my server. His problems were flow control (flow control was now being counted as dropped packets) and DHCP requests (VLAN related). And for perspective, Fedora 18 was 3.6.X kernel and Fedora 20 was 3.11.X kernel. unRAID 5.0.6 was kernel 3.9.X. Every stable release of 6 and higher have been in kernel 4.X. So base don this users report, and my experience, something changed after 3.9.X.

Yes, 4+ million dropped packets in the last 5 hours out of 106 million packets, so about 4% are dropped. Using the same CT card you have. If I install an older Intel PRO/1000 GT, I would get about 8000 an hour instead of 800,000. With my onboard Realtek 8211, I would have had double the amount of dropped packets. Odd thing is I run a 2nd unRAID on the exact same network, using the same RAM and CPU, and version of unRAID. It has a Realtek 8168 and it has 0 dropped packets in over 100 days! This leads me to believe it isn't switch, router, etc. Problem remains, even if I swap ports. I also run the card in promiscuous mode, and still get dropped packets. So I think they are actual dropped packets. Using these same NIC's on unRAID 5.0.6, I had zero dropped packets in years. So I definitely think it is something to do with the kernel and drivers that are built into unRAID, and 6.1.X is less friendly to NIC's. If you google the 'problem' of dropped packets I think you will find that the consensus is that they are not a problem in and by themselves. (At least, that is what I found when I did it.) If you don't have some other problem, they are harmless. There is no doubt that things have been changed in the kernel (look at the version numbers) and in how the kernel was compiled for unRAID to make it more 'friendly' to both Dockers and VM's. Did these changes have effects in other areas? Undoubtedly! But it they break anything? That is the question... What I think was happening in earlier version was that all the packets were being accepted and the 'extra' ones tossed away without any notice of the action. Now, for whatever reason, they are being tossed up at the NIC level and the count of these 'extra' ones is "dropped packets'. I also suspect that the change which was made to change how the interrupts were handled affected this problem. (You can go looking back in the 6.1 beta series change notices to find which one it was done in.) That's the reason I've ran in promiscuous mode. It ignores all the "extra ones" that are supposed to be dropped, and should only be reporting genuine dropped packets. So I don't agree with your conclusion that this is normal. I think something is broken. I do agree that new Linux kernels to treat more things as dropped packets (IP6 when you aren't configured, etc.), so seeing an increase in dropped pockets may be normal. But once those are all filtered out, and this many drops are reported, then there is a problem. Essentially 4% drop of valid packets means 4% needs to be resent (and then some of the resent get dropped, etc.). But you are basically talking about a 4% slowdown in network transfers in my case (about 9.5% with the Realtek 8211). Over 5 hours I transferred 120+ GB of data to unRAID and had 4 million dropped packets. On my other unRAID, which is on the same network, I transfer 6 GB/hour 24/7 to the unRAID. That is 144 GB per day, and that server has been running over 100 days without a single dropped packet. Now, I don't know that it is an unRAID problem per se. It may be more of a Linux/hardware problem, and in their desire to upgrade, unRAID stepped on the landmine. I don't know. If you look at change log, one of the updates to UnRAID notes that new firmware for Realtek NIC's was added to correct issues. So is this why my one Realtek NIC works error free? Some firmware fix to the NIC that unRAID distributes? I believe that the 8168 in my working server is one that had a firmware update, and an updated driver too. However, unRAID doesn't detect my Realtek 8211 as a Realtek NIC (in the trouble server), so it loads the forcedeth generic driver. However, it also loaded the forcedeth driver in 5.0.6, and I had zero drops on that platform. So something else is going on, but I don't know what. Also, if you look at the Intel CT, there are numerous reports of dropped packets with linux in general, and there have been several driver and firmware modifications made to the NIC. Unfortunately, the last report I have of it working error free on linux was pack in Linux 2.X something. But that doesn't mean further changes to Linux didn't break it (I think there is a newer driver for Linux that I don't believe unRAID is using). I guess my general complaint here is that I don't think unRAID looks enough to the past when they do their upgrades. Everyone here has unRAID boxes built from an older mishmash of equipment, that is stable for them. But unRAID wants to add some new doodad like Docker, and they upgrade drivers, Linux kernel, etc to accommodate. Then old, stable platforms get broken (I guess we should never upgrade, and I'm kicking myself a little for moving off 5.0.6 now). unRAID would actually work better as a hardware/software platform. If Limetech controlled the hardware, they would know that only three MB's were used, three different NIC's, one brand of RAM, etc. Then when it came time to upgrade the software, they would have 48 pieces (just an example) of hardware to test, and once it was all working in Beta, it could be released to everyone, with zero problems (more or less). And just for more info on changes to dropped packets:

Yes, 4+ million dropped packets in the last 5 hours out of 106 million packets, so about 4% are dropped. Using the same CT card you have. If I install an older Intel PRO/1000 GT, I would get about 8000 an hour instead of 800,000. With my onboard Realtek 8211, I would have had double the amount of dropped packets. Odd thing is I run a 2nd unRAID on the exact same network, using the same RAM and CPU, and version of unRAID. It has a Realtek 8168 and it has 0 dropped packets in over 100 days! This leads me to believe it isn't switch, router, etc. Problem remains, even if I swap ports. I also run the card in promiscuous mode, and still get dropped packets. So I think they are actual dropped packets. Using these same NIC's on unRAID 5.0.6, I had zero dropped packets in years. So I definitely think it is something to do with the kernel and drivers that are built into unRAID, and 6.1.X is less friendly to NIC's.