March 19, 20188 yr I recently got into a situation where most of my media files keep increasing in size on their own making them unable to play. For instance, a 1.6GB movie file suddenly becomes a 3.5 GB file. If I try to open the file on Windows Media Player, it'll say "Windows Media Player encountered a problem while playing the file." When I try to stream on Plex, the content becomes "unavailable" I tried to google for solution but have walked into a dead end here. I tried running a malware scan thinking that it could be a bug, but it found nothing. Should I try to manually take my drives out and put them back in? Any suggestions please, I really don’t wipe my entire computer and start over. Also, whenever sabnzbd and sickbeard grab new episodes of the shows, it’ll work and play normally until the next day, then the files become “unavailable” or corrupted. The files that are corrupted have been the ones downloaded from the last month. The content/files before February are still in good condition. Any solutions?
March 19, 20188 yr Post your diagnostics. Go to Tools > Diagnostics > Download and upload it here. Does this only happen in one share? Does this only happen to files accessed by Plex? Does this only happen to movie files? What file extensions do you experience it with in that case? (MKV, MP4 etc) Does any other apps, dockers, VMs or computers have access to the share?
March 20, 20188 yr Author https://www.dropbox.com/s/f1zsynp6nv3zpsl/garunriot-diagnostics-20180320-0220.zip?dl=0 That's my diagnostics. It happens only within my server. This only occurs with files within the server tower I have hosted within Limetech. Only movies/TV files to know my knowledge and both mkv, mp4, avi are all affected. I literally just updated my limetech to 6.5.0. I will update you if the files are still corrupted after the update.
March 20, 20188 yr Community Expert The fact that this happens overnight suggests that maybe the files are landing OK on your cache disk, and something is going wrong when mover runs overnight to move them to array disks. Have you tried running file system checks on all your drives to make sure none of them have file system level corruption? One thing I notice is that your cache disk and several of your data disks are using ReiserFS. As this is now end-of-life with virtually no support at the Linux developer level so you might want to consider migrating them to XFS as that will give better performance and long term support.
March 20, 20188 yr Community Expert Likely unrelated, but disk2 has a SMART failing now attribute, still this attribute failing might cause data corruption and the disk should be replaced. ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 184 End-to-End_Error -O--CK 097 097 099 NOW 3
March 20, 20188 yr Author Yeah, I upgraded to limetech V6.5. It did nothing, the files are still corrupted overnight.
March 20, 20188 yr 15 hours ago, gigga45 said: It happens only within my server. This only occurs with files within the server tower I have hosted within Limetech. Only movies/TV files to know my knowledge and both mkv, mp4, avi are all affected. I literally just updated my limetech to 6.5.0. I will update you if the files are still corrupted after the update. What dockers other than Plex has access to where you store your media? Do you manually move downloads from sabnzbd and Sickbeard or do they handle moving the files? If it's not file system corruption or mover issues as itimpi suggests, it could be Sickbeard messing up the files. Try download or put a known good video file in your library and stop Sickbeard for a day or two and see if it gets corrupted as well.
March 21, 20188 yr Author 2 hours ago, SelfSD said: What dockers other than Plex has access to where you store your media? Do you manually move downloads from sabnzbd and Sickbeard or do they handle moving the files? If it's not file system corruption or mover issues as itimpi suggests, it could be Sickbeard messing up the files. Try download or put a known good video file in your library and stop Sickbeard for a day or two and see if it gets corrupted as well. No other dockers have access to my server, only Plex. It’s not Sickbeard but yes i have sickbeard and sabnzbd organizing my shows and movies automatically. Torrent files I downloaded through deluge webUI and utorrent also get corrupted overnight. I have a feeling it’s a failed drive issue then?
March 21, 20188 yr 2 minutes ago, gigga45 said: I have a feeling it’s a failed drive issue then? It could be but your SMART data seems okay, other than the 3 end-to-end and sata downshift errors on Disk 2. If the onboard cache on disk 2 is bad though, that could be why you're seeing these bloated and corrupted files. Do you know what disk the damaged files are stored at?
March 21, 20188 yr Author I'm not sure how to locate whether which files are on which disks? Can you tell me how?
March 21, 20188 yr In the web UI, click on the Shares tab. On the far right of the share column you'll see a folder symbol. If you click it, you can browse the share and on the right you can see what disks the files and folders are located at.
March 21, 20188 yr Author I just did a thorough check. All the bad files are located randomly in the disk 3 and cache drive. Also, here's a screenshot of my dockers. I misunderstood you earlier. Edited March 21, 20188 yr by gigga45
March 21, 20188 yr Hm... That makes it a pure guessing game. Going further off itimpi's idea about the file getting corrupted during the mover, go to Settings > Scheduler and scroll down to the Mover settings and enable Mover logging. If you have a share using the cache, put a file there and manually run the mover once it's transferred. You can do this from the settings menu if you are still in the same window or at the bottom of the Main tab. Once the mover has completed, check the file and open the Log tab in Unraid. You should see something like this in the log window: Mar 21 03:11:19 UnRaid root: move: file /mnt/disk2/isos/ubuntu-16.04.1-server-amd64.iso If it moved without any errors and it's corrupted when the mover is completed, it could be a file system error and checking that requires some harder steps to fix.
March 21, 20188 yr Author Quote Mar 20 22:57:01 GarunRiot kernel: CPU1: Package temperature/speed normal Mar 20 22:57:01 GarunRiot kernel: CPU3: Package temperature/speed normal Mar 20 22:57:01 GarunRiot kernel: CPU2: Package temperature/speed normal Mar 20 22:57:14 GarunRiot root: move: file /mnt/cache/Downloads/_Plex/TV/Riverdale/Riverdale - 2x15 - Chapter Twenty-Eight There Will Be Blood.mkv Mar 20 22:57:14 GarunRiot root: move: file /mnt/cache/Downloads/_Plex/TV/The Walking Dead/The Walking Dead - 8x12 - The Key.mkv Mar 20 22:57:14 GarunRiot root: move: file /mnt/cache/Downloads/_Plex/TV/Here and Now (2018)/Here and Now (2018) - 1x06 - Fight, Death.mkv Mar 20 22:57:14 GarunRiot root: move: file /mnt/cache/Downloads/_Plex/TV/Bob's Burgers/Bob's Burgers - 8x10 - The Secret Ceramics Room of Secrets.mkv Mar 20 22:57:14 GarunRiot root: move: file /mnt/cache/Downloads/_Plex/TV/Schitt's Creek/Schitt's Creek - 4x08 - The Jazzaguy.mkv Mar 20 22:57:14 GarunRiot root: move: file /mnt/cache/Downloads/_Plex/TV/Schitt's Creek/Schitt's Creek - 4x07 - The Barbecue.mkv Mar 20 22:57:14 GarunRiot root: move: file /mnt/cache/Downloads/_Plex/TV/The Real Housewives of Atlanta/The Real Housewives of Atlanta - 10x16 - Driving Miss Kim.mkv Mar 20 22:57:14 GarunRiot root: move: file /mnt/cache/Downloads/_Plex/TV/How to Get Away with Murder/How to Get Away with Murder - 4x15 - Nobody Else Is Dying.nfo-orig Mar 20 22:57:14 GarunRiot root: move: file /mnt/cache/Downloads/_Plex/TV/How to Get Away with Murder/How to Get Away with Murder - 4x15 - Nobody Else Is Dying.mkv Mar 20 22:57:14 GarunRiot root: move: file /mnt/cache/Downloads/_Plex/TV/How to Get Away with Murder/How to Get Away with Murder - 4x15 - Nobody Else Is Dying.nzb Mar 20 22:57:14 GarunRiot root: move: file /mnt/cache/Downloads/_Plex/TV/How to Get Away with Murder/How to Get Away with Murder - 4x15 - Nobody Else Is Dying.srr Mar 20 22:57:14 GarunRiot root: move: file /mnt/cache/Downloads/_Plex/TV/Scandal (2012)/Scandal (2012) - 7x14 - The List.mkv Mar 20 22:57:14 GarunRiot root: move: file /mnt/cache/Downloads/_Plex/TV/Scandal (2012)/Scandal (2012) - 7x14 - The List.nzb Mar 20 22:57:14 GarunRiot root: move: file /mnt/cache/Downloads/_Plex/TV/Scandal (2012)/Scandal (2012) - 7x14 - The List.srr Mar 20 22:57:14 GarunRiot root: move: file /mnt/cache/Downloads/_Plex/TV/Scandal (2012)/Scandal (2012) - 7x14 - The List.nfo-orig Mar 20 23:11:27 GarunRiot kernel: mdcmd (83): spindown 2 Mar 20 23:12:15 GarunRiot kernel: mdcmd (84): spindown 1 Mar 20 23:14:54 GarunRiot kernel: mdcmd (85): spindown 29 That's the log after the mover is completed. https://www.dropbox.com/s/xxd3k6inpurmyx5/garunriot-diagnostics-20180320-2320.zip?dl=0 That's also an update diagnostic. Interesting. I copy the file of an episode of a TV Show to my desktop. The file on my desktop is fine, but the one in the disk 3 is corrupted.
March 21, 20188 yr 14 minutes ago, gigga45 said: That's also an update diagnostic. Interesting. I copy the file of an episode of a TV Show to my desktop. The file on my desktop is fine, but the one in the disk 3 is corrupted. So the file is corrupted when you play it over the network share but works when you copy it locally?
March 21, 20188 yr Author No. The copy of it is fine. The original within disk 3 of the server is corrupted.
March 21, 20188 yr I think a file system check of disk 3 may be in order even if there's no errors in the log. It's a bit tricky as it requires the terminal and some careful typing. Note that this can take a while so grab something to drink if you got time today or wait until tomorrow and do this then. Also note that I have never had to use this myself so I'm going purely by the wiki page. Since disk 3 is running XFS we'll be using the XFS Repair tool. If it by any chance should not be XFS, do not follow this post and let me know. First, read the whole "Running xfs_repair" section at https://lime-technology.com/wiki/Check_Disk_Filesystems#Drives_formatted_with_XFS so you know what you are getting into. This is important even if you don't understand it. Also read this whole post once in case you have any questions. It's better to ask before you start. Second, stop the array. You'll find this option on the Main tab below your cache disk and boot device. Once it's stopped, below the Start button a check box named "Maintenance mode" will appear. Check it and start the array. You will not be able to use the server while it is in maintenance mode so don't be scared that your Dockers, VM's and network shares doesn't appear. Third, open the Terminal. You'll find the button for it located in the top right of your server and it will pop up a window. You will see "Linux 4.14.26-unRAID" and "root@ServerName:~#". Now this is the scary step, actually typing the commands. As stated in the Check File Systems page, you have to run the xfs_repair command. Since your disk 3 is acting up, the command would be xfs_repair -v /dev/md3 I repeat: xfs_repair -v /dev/md3 That's X F S underscore REPAIR space minus V space slash DEV slash MD3 in all lowercase. Once you have typed that into the terminal, triple check that it's correct and hit enter. DO NOT run this command when the array is offline/stopped or not in maintenance mode! The repair tool will run it's course and try to correct any errors on the drive. Do not close this window and note that you are not able to copy text from the web terminal, so don't hit Ctrl + C in it as that will cancel the operation! I would imagine it is saving the results to the Unraid log but as I have never done it before, take a screenshot of it once it's completed just in case and download the diagnostics. Once it's complete, you will see the result and a new blank line starting with "root@ServerName:~#" again. You can then stop the array, uncheck maintenance mode and start it up again. Try to put another file on the share and run the mover. If it still gets corrupted... I would suggest trying to move everything off the cache drive and format it as XFS or BTRFS while in maintenance mode as well, but that's a task for another reply. Hopefully the repair solves the issue! Edited March 21, 20188 yr by SelfSD Never mind all that.
March 21, 20188 yr Community Expert @SelfSDIs there any specific reason that you are suggesting the file system check should be run from the command line rather than via the GUI? I would normally recommend running it while in Maintenance mode by clicking on the drive and selecting to run the check from the resulting dialog as that avoids the end-user having to know the syntax and possibly run the command incorrectly.
March 21, 20188 yr Author Quote Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. That's the log after the run to check on disk 3. Smart report is attached. https://www.dropbox.com/s/3t1dzqxio50fjy9/garunriot-smart-20180321-1627.zip?dl=0
March 22, 20188 yr From what I can see from that result there's nothing wrong with the file system on disk 3. Could you try to stop Plex, Deluge, SABnzbd and SickBeard, copy a file to the share again and then run the mover? Maybe, just maybe one of the dockers for some reason is doing modifications to the file that the mover can't detect.
March 22, 20188 yr Author 1 hour ago, SelfSD said: From what I can see from that result there's nothing wrong with the file system on disk 3. Could you try to stop Plex, Deluge, SABnzbd and SickBeard, copy a file to the share again and then run the mover? Maybe, just maybe one of the dockers for some reason is doing modifications to the file that the mover can't detect. How do i stop those dockers?
March 22, 20188 yr Click on the icon next to the name and a menu appears. Select "Stop" and wait until the green arrow on the icon turns into a red square.
March 22, 20188 yr Author 2 hours ago, SelfSD said: From what I can see from that result there's nothing wrong with the file system on disk 3. Could you try to stop Plex, Deluge, SABnzbd and SickBeard, copy a file to the share again and then run the mover? Maybe, just maybe one of the dockers for some reason is doing modifications to the file that the mover can't detect. Mar 22 00:32:47 GarunRiot kernel: docker0: port 2(vethae21040) entered disabled state Mar 22 00:32:48 GarunRiot avahi-daemon[14748]: Interface vethae21040.IPv6 no longer relevant for mDNS. Mar 22 00:32:48 GarunRiot avahi-daemon[14748]: Leaving mDNS multicast group on interface vethae21040.IPv6 with address fe80::882a:7eff:feee:2376. Mar 22 00:32:48 GarunRiot kernel: docker0: port 2(vethae21040) entered disabled state Mar 22 00:32:48 GarunRiot kernel: device vethae21040 left promiscuous mode Mar 22 00:32:48 GarunRiot kernel: docker0: port 2(vethae21040) entered disabled state Mar 22 00:32:48 GarunRiot avahi-daemon[14748]: Withdrawing address record for fe80::882a:7eff:feee:2376 on vethae21040. Mar 22 00:38:30 GarunRiot emhttpd: req (18): shareMoverSchedule=40+3+*+*+*&shareMoverLogging=yes&cmdStartMover=Move+now&csrf_token=**************** Mar 22 00:38:30 GarunRiot emhttpd: shcmd (449): /usr/local/sbin/mover |& logger & Mar 22 00:38:30 GarunRiot root: mover: started Mar 22 00:38:32 GarunRiot root: move: file /mnt/cache/Downloads/_Plex/TV/Schitt's Creek/Schitt's Creek - 4x08 - The Jazzaguy.mkv Mar 22 00:38:32 GarunRiot root: move: file /mnt/cache/Downloads/_Plex/TV/Schitt's Creek/Schitt's Creek - 4x07 - The Barbecue.mkv Mar 22 00:38:32 GarunRiot root: move: file /mnt/cache/Downloads/ToSickBeard/schitts creek s04e09 720p webrip hevc x265-rmteam/schitts.creek.s04e09.720p.webrip.hevc.x265.rmteam.mkv Mar 22 00:38:32 GarunRiot root: move: file /mnt/cache/Downloads/ToSickBeard/schitts creek s04e09 720p webrip hevc x265-rmteam/Anocha Restriction 000780893246970.nfo Mar 22 00:38:32 GarunRiot root: move: file /mnt/cache/nextcloud/garunriot/files/Photos/2018/03/18-03-20 16-49-19 7458.png Mar 22 00:38:32 GarunRiot root: move: file /mnt/cache/nextcloud/garunriot/files/Photos/2018/03/18-03-21 10-42-16 7460.png Mar 22 00:38:32 GarunRiot root: move: file /mnt/cache/nextcloud/garunriot/files/Photos/2018/03/18-03-20 16-54-41 7459.png Mar 22 00:41:32 GarunRiot root: mover: finished That's the log. and also attached is the diagnostics. https://www.dropbox.com/s/n5gzma7smyesac6/garunriot-diagnostics-20180322-0044.zip?dl=0
Archived
This topic is now archived and is closed to further replies.