tenchiken

Looking forward to this

Still my favorite role for him.

Good work! Love seeing a fellow seeder on here!

Da good stuff

lol I love how these always do the “We’ll get them all this time for sure!”

Awesome, so that’s good news. Disks probably just fine.

My next thoughts are on the service itself then… Your service providing the share might be getting throttled or not getting direct access to kernel hooks for performance.

Simplest test I would think is set up Samba or NFS in the host itself, not a container. Try a large transfer there. If speed isn’t an issue that way, then something at the container level is hindering you.

Hmm, at a glance those all look to be CMR.

To rule this out ideally, a tool like iostat (part of sysstat tools) can help. While moving data, and with the problem happening, if you run something like “iostat 1 -mx” and watch for a bit, you might be able to find an outlier or see evidence of if the drives are overloaded or of data is queueing up etc.

Notably watch the %util on the right side.

https://www.golinuxcloud.com/iostat-command-in-linux/ can help here a bit.

The %util is how busy the communication to the drive is… if maxed out, but the written per second is junk, then you may have a single bad disk. If many are doing it, you may have a design issue.

If %util doesn’t stay pegged, and you just see small bursts, then you know the disks are NOT the issue and can then focus on more complex diagnosis with networking etc.

What drives? If they are shingled, your performance will be terrible and the array runs a high risk of failing.

CMR is the way to go.

SMR behavior is about like what you describe… Fast until the drive cache is filled then plummets to nothing.

Nice share. I had several of these little machines back in the day and it was cool to see this effort. Thanks!

Yeah, my personal experience was similar but it’s all volunteers in the community doing the interviews.

I kept my queue window open and just chilled nearby and it came sooner than they estimated by a bit. Been worth it for me though.

I am not in it, but there’s a similar site called Orpheus that might be easier time wise to interview for, but I don’t have much experience with them.

Redacted has a pretty good amount of DVD rips, DSD etc. not all encompassing but definitely not rare there.

Don’t you threaten me with a good time!

I’m interested, primarily in the idea that some parts could be useful longer term… I’m an old school Internet janitor, and appreciate the idea that enshittification is a moving target.

I’d ask up front though if you’ve seen or considered Veilid? It might be wise to evaluate working with that as a baseline so a stronger fight against the shit can be had.

https://veilid.com/

Let’s fuck up some fascists.

Are there specific issues noted, or just asking based on the time last updated?

I’ve thought about looking over to see what might need cleaned up, but many of my personal use cases or methods might not fully align with the general consensus.

Along the same lines, is there anything you’d like to see added?

I fear we are well on the path as was described by Robert Heinlein a while back:

https://en.m.wikipedia.org/wiki/"If_This_Goes_On—"

Unfortunately I don’t expect things to go well I’m the states. I really hope I’m wrong in that…

“However, this may prove challenging” … That sentence doing a lot of lifting, lol

Second the suggestion for *Arr here! It’s clever enough to rename to exactly what jellyfin wants as well as in place hardlinks if you are Linux, so that the original names persist in qbit while jellyfin sees the good stuff.

There’s other benefits like tracking quality you have on disk for if you are wanting something better down the line, but allowing it to handle naming and sorting is a huge life saver.

Drive failures have almost nothing to do with access if they are mechanical. Most failures are from bearing or solder interconnect failures over time.

Also, most seeding is in smaller chunks that are read and cached if popular… Meaning less drive hits than 1-1 read vs upload.

You will almost always have drives fail from other aspects like heat or power or old age before wear from seeding would ever be enough to matter.

I have drives in the excess of 10+ years, with several seeds that have been active for many years of those, that are still running just fine.

Actually there’s a better reason for the encryption! You are correct that they use torrent clients to connect and record swarm nodes.

It prevents an ISP from traffic shaping against known torrent traffic!

Many ISP will watch for certain unencrypted headers and if it sees torrent will throttle it to nearly nothing. With the encryption, it all just looks like SSL.

It was one of a few stupid things and I wound up just telling him to leave.

Kinda wish it was more dramatic and/or gory, but I usually am just too tired to turn to violence.

Besides, I’d never admit to owning that chipper shredder anyway.