You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have checked the existing issues to avoid duplicates (as much as I can!)
I have redacted any info hashes and content metadata from any logs or screenshots attached to this issue
Is your feature request related to a problem? Please describe
Bitmagnet uses up a lot of disk space over time. Much of that is for low value content that cannot be downloaded due to having insufficient seeders/leechers.
Describe the solution you'd like
It would be great to be able to purge content based on there being no seeder activity. The ideal version of this looks something like... if a torrent has been known about by a Bitmagnet install for >N days, and has had no seeders for >N days, then delete it.
In more detail, it looks like the classifier system would be a good foundation for this, as it provides a full rules system, and the option to delete torrents. This would allow users to extend it with more complex rules such as keeping movies for longer than music.
Does deletion in the classifiers still retain sufficient context (e.g. a hash?) to prevent re-downloading of the torrent metadata if it is rediscovered in the future?
Should the default classification config include a configuration with this? Say, deleting anything with no seeders after 30 days?
Classification after some timespan has passed (not on torrent first discovery) require reprocessing, which looks like it's currently a bit of a power-user feature. Perhaps an easy path could be provided for this feature, if implemented via classification. Alternatively documenting a reasonable default command to run (no APIs, rematch)
Describe alternatives you've considered
I've had a look through docs and not seen anything relating to this. The description of the disk space usage, plus the ingest of zero-seeder torrents suggests this is not currently a feature.
I've also looked into where seeders/leechers data is stored in the database, and I think it's a bit more complicated than just a number in a field somewhere? Otherwise I'd consider doing this purely by database query. Perhaps this could be implemented as a database function instead, as it doesn't match the classification problem entirely.
The text was updated successfully, but these errors were encountered:
You can achieve this with classifier - I can provide a sample when next at my laptop. I only keep torrents that have minimum 5 seeders or are tv shows that are in defined list
Is your feature request related to a problem? Please describe
Bitmagnet uses up a lot of disk space over time. Much of that is for low value content that cannot be downloaded due to having insufficient seeders/leechers.
Describe the solution you'd like
It would be great to be able to purge content based on there being no seeder activity. The ideal version of this looks something like... if a torrent has been known about by a Bitmagnet install for >N days, and has had no seeders for >N days, then delete it.
In more detail, it looks like the classifier system would be a good foundation for this, as it provides a full rules system, and the option to delete torrents. This would allow users to extend it with more complex rules such as keeping movies for longer than music.
Does deletion in the classifiers still retain sufficient context (e.g. a hash?) to prevent re-downloading of the torrent metadata if it is rediscovered in the future?
Should the default classification config include a configuration with this? Say, deleting anything with no seeders after 30 days?
Classification after some timespan has passed (not on torrent first discovery) require reprocessing, which looks like it's currently a bit of a power-user feature. Perhaps an easy path could be provided for this feature, if implemented via classification. Alternatively documenting a reasonable default command to run (no APIs, rematch)
Describe alternatives you've considered
I've had a look through docs and not seen anything relating to this. The description of the disk space usage, plus the ingest of zero-seeder torrents suggests this is not currently a feature.
I've also looked into where seeders/leechers data is stored in the database, and I think it's a bit more complicated than just a number in a field somewhere? Otherwise I'd consider doing this purely by database query. Perhaps this could be implemented as a database function instead, as it doesn't match the classification problem entirely.
The text was updated successfully, but these errors were encountered: