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

RSS plugin should use guid for history management #2637

Open
4 tasks done
de666 opened this issue Feb 26, 2024 · 6 comments
Open
4 tasks done

RSS plugin should use guid for history management #2637

de666 opened this issue Feb 26, 2024 · 6 comments

Comments

@de666
Copy link

de666 commented Feb 26, 2024

Please complete the following tasks.

  • Web browser cache cleared
  • Link provided to install script if applicable
  • Not using broken rtinst install script
  • Web browser, ruTorrent, PHP and OS version provided

Tell us about your environment

ruTorrent: v4.2.9

Tell us how you installed ruTorrent

using
https://github.com/crazy-max/docker-rtorrent-rutorrent/releases/tag/4.2.9-0.9.8_2-0.13.8_2-r0

Describe the bug

Using rss plugin with feed which sometimes changes final link maintaining the same guid (like Jackett does), history is not managed the correct way because it refers to final download url (link element) instead of guid which (if present and valid) shuold be used as history reference because is unique and it doesn't change.

Steps to reproduce

  1. add rss feed from jackett
  2. load some torrent -> torrent are loaded and marked as loaded in the UI
  3. wait a couple of hours
  4. reload feed
  5. torrent previous loaded not marked as loaded anymore since link element has changed (for the same torrents already loaded)

Expected behavior

rss plgin shuold handle correctly the torrent already loaded.
This bug causes also rssmanager is not working properly because if the torrent has been already loaded, completed and removed from active torrent list, it is loaded again.

Additional context

No response

@TrimmingFool
Copy link
Contributor

@de666 Thanks for this!

Currently, the <link> is used to identify a rss item.
However, according to the spec, using the <guid> as the item-identifer instead, seems to be correct:
https://www.rssboard.org/rss-specification#hrelementsOfLtitemgt

I am not sure if only changing rRSSHistory will be enough, though:

class rRSSHistory

If no one else wants to take this on, I think, I would, eventually.

@stickz
Copy link
Collaborator

stickz commented Mar 24, 2024

@TrimmingFool Version 4.3 will be released in the near future. Would you like to sneak this important change in?

@ranirahn
Copy link
Contributor

ss (2024-04-26 at 01 13 18)
Is this related to this problem that same torrent gets added over and over again? This stops only when this torrent falls out of RSS feed finally.

@de666
Copy link
Author

de666 commented Apr 29, 2024

Is this related to this problem that same torrent gets added over and over again?

I think so, that was the same issue I had and I came up to the conclusion that was the reason.
Indeed it make sense when you have an RSS with links which change every time even if pointing to the same torrent hash.

@ranirahn
Copy link
Contributor

Is this related to this problem that same torrent gets added over and over again?

I think so, that was the same issue I had and I came up to the conclusion that was the reason. Indeed it make sense when you have an RSS with links which change every time even if pointing to the same torrent hash.

I looked at my RSS feed closer and only thing I saw changing was the time. You had RSS that links changed, but i think that is not the only possibility. Most RSS feeds dont change the time for torrents, but this one does. Exact same torrent, but <pubdate> is new on every RSS update and it downloads it again. That ofcourse makes sense that if you have multiple torrents with the same name, but date is different then its possible that they are not the same, but hash is the same so i am not sure if that will fix my issue too if torrents get identified by guid. Will wait the fix for this and see if its fixed for me too.

@ranirahn
Copy link
Contributor

I have looked this issue and I think change from link to guid will not fix my issue. Currently link, hash and timestamp is checked and if one of them is not the same then torrent is downloaded again. Some feeds have new timestamp in every feed update and torrents that have already been deleted will be downloaded again because time is changed. Even if torrents get identified by guid. Hash should be enough to indentify the content of the torrent and i dont think time or link needs to be checked again because data have not changed. It probably download torrents again and again even if torrent and data is not deleted but that does not show because torrent is already in torrents table and it gets merged into one. This also should not happen just because timestamp or link is different. Most importent thing is the content of the torrent and that is defined by hash. So i tried to think what would be the downside to get ride of link and timestamp from checking torrents history? I could not think of any. Hash should be enough to identify torrents that is already loaded and should not be downloaded again. Am i wrong?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants