Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

qBittorrent-nox v4.2.5 does not detect bad torrent files or advise user torrent file is invalid. #12650

Open
sunrisepi opened this issue Apr 25, 2020 · 9 comments
Labels
Confirmed bug An issue confirmed by project team to be considered as a bug Search engine Issues related to the search engine/search plugins functionality WebAPI WebAPI-related issues/changes WebUI WebUI-related issues/changes

Comments

@sunrisepi
Copy link

sunrisepi commented Apr 25, 2020

Please provide the following information

qBittorrent version and Operating System

qBittorrent-nox v4.2.5, raspbian (buster)

If on linux, libtorrent-rasterbar and Qt version

  • libtorrent-1_2_6
  • Qt believed to be version 5.11.3 (per qtdiag). Ran at prompt:
    /usr/lib/qt5/bin/qmake -v
    QMake version 3.1
    Using Qt version 5.11.3 in /usr/lib/arm-linux-gnueabihf

What is the problem

Noticing an issue with qBittorrent-nox v4.2.5 in raspbian (buster build).
It does not detect invalid/corrupt torrent files. Please advise?

What is the expected behavior

qBittorrent-nox v4.2.5 should detect bad torrent file and advise user

Steps to reproduce

After some more research, it seems qBittorrent-nox does not report that the torrent file is invalid. I figured this out after comparing to 2 other bittorrent clients.

Now if I try qBittorrent v4.2.2 in Windows, it detects the bad torrent file:

Now checking transmission v2.9.2 (14714) in raspbian (buster/Linux), it also detects the bad torrent file:

Extra info(if any)

It's a bit disappointing to see qBittorrent-nox not working as expected, after all the effort to compile and install it. Is this a known issue with not detecting bad torrent files? How do we fix this? Thanks.

@FranciscoPombal
Copy link
Member

I managed to reproduce this on 4.2.5.
Looks like a bug both in the plugin and in qBittorrent.

On the plugin side, the Download link and description page URLs both point to the description page. This is wrong, at least for this plugin.

On the qBittorrent side, when using the GUI, qBittorrent manages to get the magnet link correctly (somehow), while it silently fails to do so with the WebUI.

Even after the plugin is fixed, this silent failure should also be fixed.

@Piccirello @glassez

@FranciscoPombal FranciscoPombal added Confirmed bug An issue confirmed by project team to be considered as a bug Search engine Issues related to the search engine/search plugins functionality WebAPI WebAPI-related issues/changes WebUI WebUI-related issues/changes labels Apr 25, 2020
@Piccirello
Copy link
Member

The web UI/API's silent failure bubbles back up to #10960. We just don't have good, standardized error handling for our API endpoints.

@sunrisepi
Copy link
Author

Thanks for the info. When a version update/bugfix is released, I'll see if that fixes the issue. In the meantime, I'll be more watchful of the torrents I add, since qBittorrent itself cannot advise me if the torrent is invalid.

@FranciscoPombal
Copy link
Member

I'll be more watchful of the torrents I add, since qBittorrent itself cannot advise me if the torrent is invalid.

It can, except on the WebUI/API where there is some kind of bug.

@sunrisepi
Copy link
Author

Thanks. Unfortunately I am using qBittorrent via WebUI on my raspberry pi (which is running headless), so I'm not sure how to avoid the issue until the bug is fixed. ☺️

@Piccirello
Copy link
Member

On the qBittorrent side, when using the GUI, qBittorrent manages to get the magnet link correctly (somehow), while it silently fails to do so with the WebUI.

@FranciscoPombal I've been trying to look into this issue. Did the GUI in fact get the correct magnet link, or did it just throw an error because the link was invalid? The GUI and Web UI now seem to use identical logic (AFAICT) for downloading links.

@FranciscoPombal
Copy link
Member

@Piccirello The GUI somehow gets the correct magnet. Could it be that the GUI and WebAPI use different parts of the plugin API for this action?

@FranciscoPombal
Copy link
Member

@Anteus
Copy link

Anteus commented Apr 1, 2021

This is how the WebUI /torrent/add work:

partialSuccess |= BitTorrent::Session::instance()->addTorrent(url, addTorrentParams);

And this is how it works in the normal UI:

SearchDownloadHandler *downloadHandler = m_searchHandler->manager()->downloadTorrent(siteUrl, torrentUrl);

Could maybe add something like this to the TorrentsController::addAction?

        SearchDownloadHandler *downloadHandler = m_searchHandler->manager()->downloadTorrent(siteUrl, torrentUrl);
        connect(downloadHandler, &SearchDownloadHandler::downloadFinished, this, &SearchJobWidget::addTorrentToSession);
        connect(downloadHandler, &SearchDownloadHandler::downloadFinished, downloadHandler, &SearchDownloadHandler::deleteLater);

In the UI you also just get the description page link if you right click on a search result and copy download link.

Some linked issues
#11150
qbittorrent/search-plugins#160

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Confirmed bug An issue confirmed by project team to be considered as a bug Search engine Issues related to the search engine/search plugins functionality WebAPI WebAPI-related issues/changes WebUI WebUI-related issues/changes
Projects
None yet
Development

No branches or pull requests

4 participants