Skip to content

Releases: bitmagnet-io/bitmagnet

v0.9.5

17 Jul 15:26
3467224
Compare
Choose a tag to compare

Allow rate limit "burst" for TMDB API when using the default API key, allowing the limit to average to 1 second with a lot less blocking, which became more important as the default queue concurrency was reduced to 1.

What's Changed

  • Increase rate limit burst when using default TMDB API key by @mgdigital in #296

Full Changelog: v0.9.4...v0.9.5

v0.9.4

04 Jul 12:08
6cf825b
Compare
Choose a tag to compare

This release includes 2 optimizations that should reduce the load that queue jobs place on the database, including for the 0.9.0 upgrade job.

It should also reduce instances of ERROR: canceling statement due to user request in the Postgres logs, but note that Bitmagnet does cancel some database queries because it sometimes tries 2 query strategies in a race and cancels the slowest one, so this message doesn't indicate a problem.

What's Changed

Full Changelog: v0.9.3...v0.9.4

v0.9.3

19 Jun 07:41
b05e5d1
Compare
Choose a tag to compare

This release reduces the default processor.concurrency config to 1 following user feedback that concurrency of 3 causes slowdowns on some systems. If your system can handle it, you may want to configure a higher value.

What's Changed

Full Changelog: v0.9.2...v0.9.3

v0.9.2

14 Jun 09:51
3968c8b
Compare
Choose a tag to compare

Some users have reported a slowdown in the app that is probably due to the 0.9.0 reindex. Adding a configuration option to dial down the queue concurrency for torrent processing.

If you're affected, try setting the value to 1, either as an environment variable, e.g. PROCESSOR_CONCURRENCY=1, or in your config file:

processor:
  concurrency: 1

What's Changed

Full Changelog: v0.9.1...v0.9.2

v0.9.1

13 Jun 15:27
bbd8a10
Compare
Choose a tag to compare

This release includes an optimization may improve reprocess performance on more modest hardware.

What's Changed

Full Changelog: v0.9.0...v0.9.1

v0.9.0

08 Jun 10:55
251a19f
Compare
Choose a tag to compare
  • The main improvement for v0.9.0 is ordering of results in the web UI and GraphQL API
  • An --apisDisabled flag was added to the reprocess command to allow significantly faster reprocessing/classifying without any API calls (i.e. TMDB), without disabling this globally.
  • Optimisations were made to the web UI that significantly improve responsiveness; the default pagination limit has therefore been increased to 20
  • Reprocessing is now done fully within the queue (so you'll no longer see a progress bar when running bitmagnet reprocess, this is handled by the new process_torrent_batch task)

IMPORTANT: Some refactoring of the database was needed to allow for performant ordering. On first run, a database migration will be applied that should take no longer than a few minutes, and tasks will be added to the queue to reindex all torrents. The reindex tasks must complete before ordering will work correctly; if you have millions of torrents in your index this may take a day or more, but is significantly faster in this release than prior versions. Please ensure you have no pending items in your queue (at the /metrics endpoint) before opening any issues about incorrect ordering.

What's Changed

New Contributors

Full Changelog: v0.8.0...v0.9.0

v0.8.0

30 Apr 17:52
b711325
Compare
Choose a tag to compare

Classifier reimplementation

The classifier has been re-implemented and now uses a DSL allowing for full customisation. Several bugs have also been fixed, and a preparatory database migration for search ordering has been added.

The classifier documentation can be found at https://bitmagnet.io/tutorials/classifier.html.

Build reimplementation

The build has been re-implemented using https://github.com/goreleaser/goreleaser, thanks to @KyleSanderson. A number of new platform-specific build artifacts are now available.

Seeders/Leechers bug

There has somehow been a bug present, since day 1, whereby seeders and leechers were being swapped by the DHT crawler! This is fixed in 0.8.x. The first beta included a migration that would fix existing data, but the query just takes too long (for larger indexes), and so it has been removed from the migration.

Until now, no-one noticed - but If you care and would like to fix this in your index, you can run the following query, replacing the time with the time at which you did the 0.8.x upgrade. Be warned, this query may take a while for larger indexes! In time, much of the data will naturally fix itself anyway as the S/L numbers get re-scraped by the crawler when the torrent is re-discovered.

update torrents_torrent_sources set seeders = leechers, leechers = seeders where source = 'dht' and  updated_at < '2024-04-30 00:00:00+00';

What's Changed

New Contributors

Full Changelog: v0.7.14...v0.8.0

v0.8.0-beta.7

30 Apr 17:20
d9ad409
Compare
Choose a tag to compare
v0.8.0-beta.7 Pre-release
Pre-release

What's Changed

New Contributors

Full Changelog: v0.7.14...v0.8.0-beta.7

v0.8.0-beta.6

30 Apr 13:15
Compare
Choose a tag to compare
v0.8.0-beta.6 Pre-release
Pre-release

What's Changed

New Contributors

Full Changelog: v0.7.14...v0.8.0-beta.6

v0.8.0-beta.5

30 Apr 13:10
Compare
Choose a tag to compare
v0.8.0-beta.5 Pre-release
Pre-release

What's Changed

New Contributors

Full Changelog: v0.7.14...v0.8.0-beta.5