These permissions were never meant to be directly edited by staff. They should never have been added to the staff user edit page as it just caused confusion when the settings reset at the daily group change. I've now added these settings to the group directly and allow the settings on the user edit page to override the group settings. I refrained from fixing the can_download permission for now, because so many different things affect it and it will need at 3 separate permissions to control everything it does. Trying to fix it will take much more effort than what can be fixed today. Because of this, I removed the setting from the user edit page to reduce confusion from staff who don't realize it is controlled by the scheduler. Relevant issue: #1820.
- We dont need to auto update anymore. This is killer in loops. We already have a command that updates on weekends. We wrap the command in a if else that only executes if cache is present in case of redis restart.
- As seen in #3815 there are many selects missing for resources/views/components/partials/_torrent-icons.blade.php. It is pointless to add them all just to omit a few. There was no performance loss locally.
- closes#3815
fixup of 8c11521. It was unintentionally changed from varbinary to binary. The ip column must not be fixed length, since mysql will right pad the other 12 bytes of 4-byte ipv4 addresses with NUL (`\0`) bytes, which breaks `INET6_NTOA()`. The full 16 bytes are needed for ipv6 addresses however. Note that the commit this fixes isn't yet in stable, so anyone running the development branch in prod will have to update their schema manually.
The external tracker handles the upserts (`auto:upsert_peers`,
`auto:upsert_histories`, and `auto:upsert_announces`), handles
incrementing/decrementing the seeders/leeches/times_completed
(`auto:sync_peers`), and handles incrementing/decrementing the
balance (`auto:torrent_balance`).
The external tracker keeps track of leech slots internally, so
the leech slot caching isn't needed and as a result, shouldn't
be touched inside the `auto:flush_peers` command either.
There's no inaccurate stats issues that could happen if these
commands are run, but a normal 200 ms 3000-record upsert from
the external tracker takes 2-3 seconds if they happen at the
same time as the `auto:sync_peers` or `auto:torrent_balance`
commands are being run.
Roardom