Anti-tamper.

I’ve seen them used to screw together toilet stalls in public bathrooms. Stops bored crackheads disassembling them.

Robertson on it’s own, yes. As long as you use the proper size driver before you round out the square.

When you start carving out space for additional drivers though, the screw head becomes much weaker. The combo Robertson/Slotted/Philips screw heads will not standup to the same forces.

A good portion of these are ‘security’/anti-tamper fasteners, which basically just means they’re intentionally weirdly shapped and uncommon so people aren’t likely to be carrying the screwdrivers to tamper with stuff.

Stops things like bored crackheads disassembling the toilet stall in a public bathroom.

who the fuck outside of Japan has a JIS driver lying around, then they strip real easy. Ask me how I know.

Funnily enough, I only know about these because I’ve got one of I Fix-It’s screwdriver sets with 70 driver bits.

I was wondering why there were two sets of what looked like Philips and went looking for info.

6-lobe, star, and Torx are all names for the same somewhat common screw type. Torx is a trademarked brand name however.

Separately there’s a 5-lobe screw called ‘pentalobe’ that’s looks just like the 6-lobe but with, well…, 5 lobes. It was developed by Apple iirc, to keep people out of their products and make repair harder.

Philips/Square/Slotted (all three combined) is really common in North American electrical. Switches, outlets, breakers; all commonly use them for terminal screws.

Great for lower torque applications; you certainly wouldn’t use them for like a deck/structural screw.

Philips are too easy to strip and Slotted screws are rage inducing trying to keep the driver aligned. :(

Not pictured here is also ‘JIS’ or Japanese Industry Standard screws.

They are very similar to Philips, but they’re slightly deeper with sharper corners. They have less tendency to ‘cam-out’ and strip the screw head.

Supposedly the camming out thing is actually intentional design in Philips screws, to prevent screw guns from over torquing screws in early automotive/aircraft assembly lines; but there’s not actually evidence to support that according to Wikipedia.

That will solve part of the problem, preventing downloads before an item has even released; but there’s still lots of potential to grab unwanted torrents and leave the arrs asking for intervention when they can’t import it.

Ideally the indexers would be filtering out this junk before users can even grab them, but failing that I think we’ve got a decent solution. Check out the edited OP

Check out the edited OP.

I’m taking a look at this. It looks like it’s the malware blocker portion that I’m interested in, but if I enable it and ‘delete known malware’, it just complains every minute that there are no blocklists enabled. (though the documents say it’s supposed to fetch one from a pages.dev url that has almost no content)

Do you have a specific malware blocklist configured? Enabling the specific service blocklists demands a url for one.

I can host/build a list over time for these to use if that’s what I’ve gotta do; just wondering if there’s a public collaboration on one already on the go.

/edit: found it

https://raw.githubusercontent.com/Cleanuparr/Cleanuparr/refs/heads/main/blacklist

That’s what I’d already done as per the OP, but it leaves Sonarr/Radarr wanting manual intervention for the ‘complete’ download that doesn’t have any files to import.

I just did some digging and found I do have some good quality content from them, but they were all grabbed via NZBGeek.

Every torrent I’ve gotten with that label has been garbage/malware.

This comment prompted me to look a little deeper at this. I looked at the history for each show where I’ve had failed downloads from those groups.

For SuccessfulCrab; any time a release has come from a torrent tracker (I only have free public torrent trackers) it’s been garbage. I have however had a number of perfectly fine downloads with that group label, whenever retrieved from NZBgeek. I’ve narrowed that filter to block the string ‘SuccessfulCrab’ on all torrent trackers, but allow NBZs. Perhaps there’s an impersonator trying to smear them or something, idk.

ELiTE on the other hand, I’ve only got history of grabbing their torrents and every one of them was trash. That’s going to stay blocked everywhere.

The block potentially dangerous setting is interesting, but what exactly is it looking for? The torrent client is already set to not download file types I don’t want, so will it recognize and remove torrents that are empty? (everything’s marked ‘do not download’) I’m having a hard time finding documentation for that.

Awesome. Thanks you two, I appreciate the help. :)

Awesome. Thanks you two, I appreciate the help. :)

Ok, I think I’ve got this right?

Settings > Profiles > Release Profiles.

Created one, setup ‘must not contain’ words, indexer ‘any’, enabled.

That should just apply globally? I’m not seeing anywhere else I’ve got to enable it in specific series, clients, or indexers.

To be perfectly honest, auto updates aren’t really necessary; I’m just lazy and like automation. One less thing I’ve gotta remember to do regularly.

I find it kind of fun to discover and explore new features on my own as they appear. If I need documentation, it’s (usually…) there, but I’d rather just explore. There are a few projects where I’m avidly following the forums/git pages so I’m at least aware of certain upcoming features, others update whenever they feel like it and I’ll see what’s new next time I happen to be messing with them.

Watchtower notifies me whenever it updates something so I’ve at least got a history log.

They’re well aware of the crisis; they just don’t care to support the people affected by it.

I’ve had Immich auto updating alongside around 36 other docker containers for at least a year now. I’ve very very rarely had issues, and just attach specific version tags to the things that have caused problems. Redis and postgres for example in both Immich and Paperless-NGX have fixed version tags because they take manual work to upgrade the old databases. The main projects though, have always auto updated just fine for me.

The reason I don’t really worry about it: Solid backups.

BorgBackup runs in the early AM, shortly before Watchtower updates almost all of my containers, making a backup of the entire system (not including bulk storage) first.

If I was to get up in the morning and find a service isn’t responding (Uptime-kuma notifies me via email if it can’t reach any container or service), I’ll mess with it and try to get the update working (I’ve only actually had to do this once so far, the rest has updated smoothly). Failing that, I can just extract yesterday’s data from the most recent backup and restore a previous version.

Because of Borgs compression and de-duplication, concurrent backups of the same system can be stored in an absurdly small amount of space. I currently have 22 backups of ~532gb each, going back a full year. They are stored in 474gb of disc space. Raw, that’d be 11.8TB