January 29th, 2025

New

Improved

Fixed

v6.2

Since we re-did RSS feeds, we also had to redo queued downloads as those were also becoming a problem, especially with the increase in new queued downloads (over 1 million), and at the beginning I (Wamy) did not foresee millions of records in a single table, so there became many issues which sprung about due to not being optimized for said millions of records. Luckily the fixes were somewhat simple, and the new features easy to add.

Website

  • Adds the ability for different types of queued downloads to show up. This includes Usenet and even web downloads being able to be queued. Previously these would simply error, now they can be queued and used just as before.

Service

  • Queued downloads will be added on time (every hour), as before they would get delayed by minutes, hours and even days, which is not a good experience, especially if you have open slots you want to use.

SDK

API

  • BREAKING CHANGE: Removes the queued downloads routes at /torrents/controlqueued, and /torrents/getqueued. This was due to queued items needing their own route, rather than only being limited to the torrents endpoint. The routes are practically the same with a little more options, so if you are using these endpoints (basically nobody), then you can simply change the route and it will be all good!

  • Introduces a new route, /queued, which is where queued endpoints will now live. This is to allow future expansion, and stop any possible confusion when wanting to use queued Usenet downloads or web downloads for example. API DOCS.

  • Adds the “as_queued” parameter when creating a Usenet download. This way you can keep it in your queued and the system will add it eventually (gets checked every hour). API DOCS.

  • Adds the “as_queued” parameter when creating a web download. This way you can queue up lots of limited hosters for example, and the system will add each one in time (gets checked every hour). API DOCS.