Skip Navigation

Posts
18
Comments
692
Joined
3 yr. ago

🇨🇦

  • 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

  • No.

    Here's the LegalEagle explaining why.

    TLDW; punishment can include the death penalty. It's also a system designed to punish disobedience immediately and only much much later provide an opportunity to prove the orders you disobeyed were unlawful and thus the punishment you already suffered was wrong. That's a very very high bar to pass as well.

  • 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.

  • 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

  • Talking at me =/= talking to me.

    Get my attention, then say whatever you've gotta say.

  • It's strange, but not a terrible use for the excess heat a pc gives off I guess.

    Seems like the kind of thing you'd find as a random 5.25" bay accessory though (where a dvd drive would go).

  • Sure; but even then you need variation on the dimensions/sizes.

  • Odd... I was wondering how so.

    I'd used exactly that link to read the whole article myself.

    I opened it again, was looking at the page with it open probably 30-45seconds; when Wireds 'you need to subscribe' popup finally showed up...

    I've never seen that on any of the various web archives.


    Anyway, here's the full text of the article:

    On Wednesday, the first day of the US government shutdown, employees at the Department of Education (DOE) set their automatic out-of-office email responses to inform recipients that they would be unable to respond until after the shutdown. Hours later, many DOE employees realized their response message had been altered to contain partisan language without their consent. The automatic reply now blamed Senate Democrats for the entire shutdown.

    It’s not clear who made the change to email accounts, which was first posted about on Bluesky by journalist Marisa Kabas. “It’s disturbing,” says a DOE employee who asked to remain anonymous because they were not authorized to speak to the press. Some employees changed their responses back to the more neutral language, only to have it changed yet again to the partisan response, multiple sources tell WIRED.

    As government employees began to log off in preparation for a shutdown, many agencies sent out guidance, including suggested language for their out-of-office message. While some agencies offered employees neutral language, simply explaining they would not be able to reply until the shutdown concluded, employees at the Small Business Administration and, according to sources and screenshots reviewed by WIRED, the Department of Labor, received suggested language that blamed Democrats for the shutdown.

    At the DOE, human resources sent employees standard language ahead of the shutdown, and many employees used this as their OOO text. Originally, the suggested language given to DOE employees read, “Thank you for your email. There is a temporary shutdown of the US government due to a lapse in appropriations. I will respond to your message as soon as possible after the temporary shutdown ends. Please visit Ed.gov for the latest information on the Department’s operational status.” Many employees set this neutral language as their OOO status.

    The new, changed message reads:

    “Thank you for contacting me. On September 19, 2025, the House of Representatives passed HR 5371, a clean continuing resolution. Unfortunately, Democrat Senators are blocking passage of HR 5371 in the Senate which has led to a lapse in appropriations. Due to the lapse in appropriations I am currently in furlough status. I will respond to emails once government functions resume.”

    “The Department unilaterally, and without staff knowledge or consent, went in and changed the messages to include partisan language,” claims another DOE employee, who also spoke on the condition of anonymity.

    This is particularly problematic, because experts have alleged that the partisan language could be a violation of the Hatch Act, which sets limits to the kinds of political activity government employees can engage in. Violating the Hatch Act, which is not subject to a statute of limitations, could cause a federal employee to face fines or lose their job entirely.

    “I've never heard of any US government at the federal level or the state or local level requiring employees to use partisan language in their communication with the public,” says Don Moynihan, a professor of public policy at the University of Michigan. “Beyond the legality, this feels incredibly coercive and invasive. We hire these public servants who are supposed to serve everyone.”

    In response to a request for comment from WIRED, the Department of Education’s press line returned the same OOO message that was forced on employee’s email responses:

    “Thank you for contacting the press team. On September 19, 2025, the House of Representatives passed H.R. 5371, a clean continuing resolution. Unfortunately, Democrat Senators are blocking passage of H.R. 5371 in the Senate which has led to a lapse in appropriations. Due to the lapse in appropriations, we are currently in furlough status. We will respond to emails once government functions resume.”

  • https://github.com/nicolargo/glances

    I have a dashboard as well (Homepage), but this is a nice look at system resource usage and what's running, at a glance.

    Uptime-kuma emails me when services or critical LAN devices are unreachable for whatever reason.