Michael_P

It's pretty much just stopping the array, disabling VM and Docker services, starting array, changing any shares to Array only, running mover, make sure all files moved, stopping and shutting down to install new ssd, add the new SSD as cache, then reversing the steps to get everything back onto the new cache drive

ChatGPT is pretty good at making simple scripts like this, I shoved this prompt in I need a simple script that changes the file extension for files in a folder named "Input" to file extension .mp4, and then copy that file to a folder named "Video Output", and then uses ffmpeg to convert the file to an mp3 in a folder named "Audio Output" and it spit out import os import shutil import subprocess # Folder paths input_folder = "Input" video_output_folder = "Video Output" audio_output_folder = "Audio Output" # Create output folders if they don't exist os.makedirs(video_output_folder, exist_ok=True) os.makedirs(audio_output_folder, exist_ok=True) # Process files in Input for filename in os.listdir(input_folder): input_path = os.path.join(input_folder, filename) if os.path.isfile(input_path): base_name = os.path.splitext(filename)[0] mp4_filename = base_name + ".mp4" mp4_path = os.path.join(input_folder, mp4_filename) # Rename to .mp4 os.rename(input_path, mp4_path) # Copy to Video Output video_output_path = os.path.join(video_output_folder, mp4_filename) shutil.copy(mp4_path, video_output_path) # Convert to MP3 using ffmpeg mp3_output_path = os.path.join(audio_output_folder, base_name + ".mp3") subprocess.run(["ffmpeg", "-y", "-i", video_output_path, mp3_output_path]) print("All files processed.") Don't know if it works or not, but it should give you a good place to start

Carve it into sections, start with files that have been added around the time the issue started and move them out of your library in blocks until the problem goes away then narrow down in that block and so on.

Nah, especially since they've already run memtest looks like a broken file crashing the scanner/transcoder, especially if it's the same ffprobe process causing the segfaults. turn off plex for a few days or so and see if it goes away - you can also try deleting the codecs folder in your plex container so it re-builds. if it happens only when plex is running, you'll have to find the file causing the problem

Yeah, I'm not sure that was really an issue - only another extended test would be sure. Personally, even if it passed I'd send it to backup duty due the reallocated sectors.

It's showing up now at least - there's 25 re-allocated sectors on it so at a minimum I'd run a long SMART test on it, but if it was under warranty I'd have it replaced.

Looks like it dropped offline, check the cable/connections, reboot and post new diagnostics

The spinners look good

Plex already has both, as do most media related containers

The manual shows one on the mobo too

Make sure nothing's touching the power button on the mobo

In a docker container

It hasn't technically failed a SMART attribute or test, which is why there's no warning. I've had an SSD fail so that it would just go readonly on every write, and SMART said everything was fine, so it's not perfect.

It's showing 67 errors on the drive, the last few shown were un-correctable sectors. Here's the bit from your log where the system threw it out Jun 21 03:07:20 TomiServer kernel: I/O error, dev sdb, sector 22369448 op 0x0:(READ) flags 0x80700 phys_seg 2 prio class 0 Jun 21 03:07:20 TomiServer kernel: ata1: EH complete Jun 21 03:07:20 TomiServer kernel: BTRFS error (device sdb1 state A): Transaction aborted (error -5) Jun 21 03:07:20 TomiServer kernel: BTRFS: error (device sdb1 state A) in btrfs_finish_one_ordered:3244: errno=-5 IO failure ### [PREVIOUS LINE REPEATED 1 TIMES] ### Jun 21 03:07:20 TomiServer kernel: BTRFS info (device sdb1 state EA): forced readonly Up to you on what to do with it.

They run pretty loose in their definition of healthy lol, mine usually say 100% health too, until the power blinks and it shuts off the rack.

Hardware gremlins are the hardest to track down. And just a thought, make sure your batteries are still good in the UPS, too

In sys previous, there's the 3 entries at the end not related to startup, and nothing in there to suggest it was software related

the one in your OP starts at Jun 22 21:35:51 as the system was booting

Looks like both of those were after the reboot from the crash and don't contain anything during or before, best advice I can give at the moment is to try running it as a NAS for a few days, run memtest to rule out RAM, then start throwing parts at it starting with the PSU.

Post those

Need one more recent than 2022 lol, it'd need to be one from a 'crash' In my experience it's just as likely to be a coincidence. Random shutdowns/reboots are usually hardware related, and if nothing's logged I'd start with the power supply

Mirror the syslog to flash, without logs it's just spitballing. You can try just running it as a basic NAS for a few days to see if it continues to spontaneously shut down. And never rule out a power supply just deciding to knock off, either.

Looks like duplicati ran the host OOM on the 20th, see if you can change whatever cache location it uses to disk instead of RAM. You also may want to consider adding more RAM to the system, 8GB is a little light these days if you want to do anything other than use it as a NAS. You can reboot to clear the log and FCP will stop warning you

The SSD is failing, looks like it's got about a year on it so see if its under warranty. I don't know anything about Verbatim's SSDs so I don't know their level of quality, but I'd think you'd be better off replacing with WD or Samsung For the flash drive, try a different port, one that's USB 2.0 if available as they seem to be more reliable

Your ssd is what was failing, now it looks like it's booked the USB flash drive too