Jump to content

KYThrill

Members
  • Content Count

    305
  • Joined

  • Last visited

Community Reputation

0 Neutral

About KYThrill

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed
  1. 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.
  2. It's offered through unRAID's Community Applications, so why is it included if unRAID community doesn't want to discuss it?
  3. 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.
  4. 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.
  5. 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.
  6. 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?
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 1 pass of memtest and 0 errors. I know, just one pass, but...
  13. 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.
  14. 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.
  15. 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.