rnestler / attractorr Goto Github PK

It would be nice to not have everything hard coded 😉
See https://github.com/docopt/docopt.rs

Server seems to have changed: https://git.torrents-csv.com/heretic/torrents-csv-server/commit/2768483b940c9c02264f6d8bb13f6eb9fd35296f

[2024-01-03T15:38:30.620Z INFO  attractorr::search_providers::torrent_csv_search] Searching on Torrent-CSV
[2024-01-03T15:38:30.628Z ERROR attractorr] TC error: client error (Connect)
No results were found

This would improve search performance a lot and would easy the implementation of a responsive GUI.

Currently the command line output just uses the derived Debug trait implementation to print the torrents. A nicely formatted output would be appreciated.
Maybe look at term or rust-ansi-term. The later seems better documented.

• Add a term crate to Cargo.toml
• Add a function that formats a single torrent in color to src/torrent/mod.rs
• Use this function to print the output in src/main.rs

If you wanted, I could add the ability to search for L337X data by using the torrent_search crate.

Currently the torrents will be displayed in the order they where received. In the case of a single provider they're mostly already sorted by the number of seeders, but with multiple providers this fails.

Tipps:

• Take a look at Vec<T>::sort and Vec<T>::sort_by
• Implement some compare functions like this

impl Torrent {
    fn compare_seeders(other: &Torrent) -> Ordering
}

See this example.

• Sort by seeders by default
• Maybe add a command line argument to sort by other attributes

so I can do cargo install torrent-search

To avoid long delays while developing it would be useful to have local unit tests.

https://github.com/qbittorrent/search-plugins/wiki/Unofficial-search-plugins

In my testing the best of these sources seems to be

• torrents-csv (#122)
• limetorrents
• torrentproject2

Currently we use two simple functions. Ideally we would use a trait SearchProvider which defines a function search(keyword: &str) -> Vec<Torrent>. This would then be implemented for a struct PirateBaySearch{}.
For someone to get started:

• Change code to use a fn search(&str) ->Vec<Torrent> function which creates the search URL (see strings)
• Add SearchProvider trait (see traits)
• Add PirateBaySearch struct containing the hyper connection

Example:

❯ attractorr "dshajfksdlhajdfklhdsjaklfhdjsaklhfjka"
[2023-02-06T20:41:37.231Z ERROR attractorr] L337X error: No search results
No results were found

This behavior isn't present for the other search providers, so I'm assuming it's a bug.

How would you feel about always using the latest non-breaking version of all dependencies. For example, using every release of percent-encoding version 2 instead of one specific release, or the same with tokio 0.2

This is just a brain dump for me regarding some open points of the project.

Magnet links

Currently we create them with just the "Exact Topic" / BitTorrent info hash. While this works (which is quite awesome) we may consider to include:

• Display Name
• eXact Length
• Address TRacker

Probably we also want to add support for BitTorrent info hash v2 (BTMH)

Displaying torrents in the terminal

Currently we only show:

• Seeders / Leechers
• Name
• magnet URL

It may be interesting to add

• Source (pirate-bay, yts, ...)
• size (in human readable form) (#168)
• ...

Also it is not clear how to best format the output to be usable. As long as the magnet links are clickable it should be OK though.

Interactive mode

Currently we collect all torrents and then display them. This is a bit inefficient, since the most interesting results may already be available while we still wait for a slower source (For example: I mostly disable l337x, since it is rather slow).

I experimented a long time ago with a GTK frontend (#10), which would work asynchronously. We could also use a TUI which would display results in a table interactively.

Providing a CLI interface is nice, but some users may prefer a GUI.

• Refactor code to support multiple binaries
• Implement a simple Gtk GUI

I cloned the project, install openssl accordingly and ran cargo.
it did not build/compile; however when I attempted it on MacBook pro 2018 it worked.

adjusted request

Actual:

> torrent-search --sort=seeders asdasdasdasdasdasdlkalsdkasld
[2021-10-23T19:19:09.934Z ERROR torrent_search] L337X error: No search results
S:0/L:0 - No results returned
magnet:?xt=urn:btih:0000000000000000000000000000000000000000

> echo "$?"
0

Expected:

> torrent-search --sort=seeders asdasdasdasdasdasdlkalsdkasld
> echo "$?"
0

Perhaps with stderr output of:

no results were found

So direct users can know what happened.

original issue

> torrent-search --sort=seeders asdasdasdasdasdasdlkalsdkasld
[2021-10-23T19:19:09.934Z ERROR torrent_search] L337X error: No search results
S:0/L:0 - No results returned
magnet:?xt=urn:btih:0000000000000000000000000000000000000000

> echo "$?"
0

> torrent-search --sort=seeders asdasdasdasdasdasdlkalsdkasld
[2021-10-23T19:19:09.934Z ERROR torrent_search] L337X error: No search results
S:0/L:0 - No results returned
magnet:?xt=urn:btih:0000000000000000000000000000000000000000

> echo "$?"
1