Looking into ScaneRSS Enhancements

  • In addition to my azondownload plugin for triggering events when a download is complete, I am looking into making 3 modifications to the ScaneRSS plugin.  These are:

    1) All the user to specify the initial state and insertion position of any new torrent originating from an RSS Scan.  The initial state would default to Queued by the user can select force download or stopped as the initial state.  The position can be selected as "Last" (default), "First" or x% where x is a percent position in the Download Position list.  I.e., if x is 50, and there are currently 10 downloads, the new download will be inserted at position 5.

    2) Add a PluginAttribute to newly inserted torrents that captures the meta-data associated with the RSS feed, such as Name, URL, Description, Category, Sub-Category and Contributor.  The idea here would be to create a special attribute by the name of "RSSAttributes" which would contain a map of each of the RSS meta-data key-value pairs.

    3) Allow the user to use meta-data when constructing the download path.  For example, allow the user to specify a download path for a given torrent as: "C:\My Downloads\<programme name>\<season number>\<episode name>\<format>\<contributor>\<website>\", where the angle-brackets form replacement string that will be replaced by the appropriate meta-data associated with the torrent through the RSS feed, parsing the name, and the Torrent itself.

    Those are the 3 proposed changes I have.  Number 2 will work with my azondownload plugin so that, if not implemented by the ScaneRSS, it can be implemented via azondownload.

    I will summarize these as 3 distinct feature requests that I will attempt to implement myself and contribute any working patches to the authors.

    • Well the first one it is already in the current beta except the position thing.

      As for the second one, since meta-data is mostly feed specific you may run into alot of problems there.
      If you want it working for all feeds, and that is what is required for the feature to make it into
      the official build. Or do you want to just save the whole RSSItem as meta-data and let the user
      figure out how to use it?

      This may sound a bit hard but I just felt I will tell you before you invest too much time in something
      that might not be used.

      Well for the third one we can work on implementing the some of the variables you suggest like season, filter name
      but as I said above I would not use non standardized meta-info.

      Thats my 2 cents.

    • I was thinking of doing something similar to your concept of "whole RSSItem as meta-data" approach, but to do a bit more parsing so that each of the sub-fields could be individually pulled from a map.  Take for instance this Demonoid RSSItem:

      Title: The Daily Show - 2007.04.24 - Sen. John McCain (TVRip.SoS)
      URL: http://www.demonoid.com/files/details/xxxxxxxx/yyyyyyyy/
      Description: Category: TV <br />
      Subcategory: Comedy<br />
      Quality: TV quality<br />
      Language: English<br />
      Uploaded by: zzzzzzzzzz<br />
      Size: 174.18 MB<br />

      If this item was downloaded, the RSSAttribute attribute of the created download would contain a map of:

      Key          Value
      Title        The Daily Show - 2007.04.24 - Sen. John McCain (TVRip.SoS)
      URL          http://www.demonoid.com/files/details/xxxxxxxx/yyyyyyyy/
      Category     TV
      Subcategory  Comedy
      Quality      TV Quality
      Language     English
      Uploaded by  zzzzzzzzzz
      size         174.18 MB

      The RSS reader does not need to know the meaning of any of these fields, just how they are delimited.  I would then suggest that in addition to standard lookups, for the directory matching, it could match the RSSItem meta-data using simple string matching.  E.g. <RSSAttribute.Uploaded by> would first retrieve the RSSAttribute from the download, then query the key named "Uploaded by".  If either of those don't exist, replace with some default, i.e. "".

      In this way, arbitrary directory fields can be created.

    • coreying

      I really like the idea of 1. I was actually just coming here to suggest that the feature is implemented into the next version of ScaneRSS. The positioning would be nice, but if the initial state is already implemented, that would be enough for me. There are somethings which should always start immediately, so having the option to set them to 'forced' from ScaneRSS is great.