Replies: 1 comment
|
Thought about this one and it's a deliberate no for now, reasoning is written up in the roadmap under "OpenBooks / IRC #ebooks integration". Short version: IRC DCC transfers are stateful and manual (@search, pick a result, message a bot), which doesn't fit Bindery's grab then queue then import pipeline that assumes a fetchable URL (NZB, torrent, magnet). The search results are also just filenames, no size, pub date, or IDs, so the ranker and custom format matching would fall back to substring guessing. And IRC bots and trigger syntax drift constantly, which is a lot of churn for a single maintainer to absorb. Best setup today is to run OpenBooks alongside Bindery for the one off IRC grabs. Different tool, different shape, and it does that job well. If someone builds a Torznab shim in front of an IRC source that emits real release metadata, wiring that into the indexer layer is fair game, that boundary is a proxy by design. |
Uh oh!
There was an error while loading. Please reload this page.
There used to be a readarr issue about this, imo would be useful
Readarr/Readarr#1364
All reactions