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
[Feature Request] Torrent Tagging / Categories #79
Comments
Transmission's OSX client actually does have groups.. and it's a pretty nice feature. But unfortunately it's not in the transmission cli or gtk client. |
Well. I was forced to switch to Deluge, because my torrent library was literally unmanagable. |
A patch was submitted 7 years ago: https://trac.transmissionbt.com/ticket/2175. It has never been merged. |
some digging into 2175, the patch's author's branch on github has a more modern version of it here: Elbandi/transmission@8592efc#diff-4ec4671edea00d8f7429feeb7becf854 |
Hello, Any ETA on this enhancement being added? |
Don't hold your breath. It's been like 7 years. Compile it in yourself! |
@grantrules is there a tech/roadmap reason to not merge it ? |
I second this stuff. Is there a reason why it hasn't been merged? |
The avoidance of feature creep, most likely. |
Then why is it in the other versions and not the GTK one? This doesn’t seem like feature creep; this is basic functionality. |
Eh, I misread this and then responded incorrectly.. No idea why it's not in the GTK client. But below is the reason it's not in the web client. It could probably be added to the GTK client. Old response: Because the tagging in the GTK client is implemented in that frontend only. You could do this with the web client by storing things things in localStorage or whatever, but I think most people would want the web client to retain the tagging info on the server side so you can access those tags from a different browser/device, which means adding tagging to the transmission daemon, which I believe is out of scope of the project. At least that's my take from following this issue for years, I have no direct involvement in transmission. If you want the feature, you can have it, just build the fork. |
Another upvote. How would I apply this patch to the current master branch? As 2.93 or 2.94 solved an issue about memory consumption I need a current version of transmission and I would love to have categories. if the feature was in transmission iself, the webclient would not need to store the information in the browser - which would break the basic idea of webUI anyway..... |
@JustMyGithub try building this: https://github.com/grantrules/transmission/tree/labels I forked the transmission repo and applied the most recent changes from Elbandi's label branch. I was not able to build it to some openssl issues on my system, so I haven't tested it, and I don't care enough to fix it at the moment. This just provides tagging in the Transmission daemon, it does not provide any sort of frontend for it. Personally, I switched to Deluge years ago and never looked back. |
thanks. I try https://github.com/ronggang/transmission-web-control now ( an alternate Web UI). |
I started working on this feature (picked up where @grantrules left off) And I have dev build of popular front end with initial support for labels here |
@qu1ck |
@cfpp2p thanks for pointing me towards existing work already made by others. Unfortunately that implementation is not equivalent to labels implementation that I'm expanding on. Main difference is that in #137 a torrent can be in only one group. I want to be able to apply multiple arbitrary labels to a torrent. Because a torrent can be "video", "action", "watch next" and "Mel Gibson before he wasn't cool anymore" at the same time. If I want to get a list of stuff to watch next, I filter by that. If I want to get rid of some old video torrents I click on "video" and sort by date. Et cetera. It's impossible to fit that use case in narrow definition of "each torrent is in one group from predefined list of groups". Ideally I would be able to sort by more than one label and if possible with different combinations like "torrents with ALL these labels, torrents with ANY of these labels". But I have not figured out gui for that yet. |
I don't think there are many alternatives to a text box where the user can
type some kind of queries in it, and possibly name and save his favorites
custom queries, like QuodLibet does.
Unfortunately that is probably too advanced for most users, and I am not
sure maintainers would be willing to merge such a complex feature if it
requires server side and API support.
Em ter, 22 de jan de 2019 02:08, qu1ck <notifications@github.com escreveu:
… @cfpp2p <https://github.com/cfpp2p> thanks for pointing me towards
existing work already made by others. Unfortunately that implementation is
not equivalent to labels implementation that I'm expanding on.
Main difference is that in #137
<#137> a torrent can be
in only one group.
I want to be able to apply multiple arbitrary labels to a torrent. Because
a torrent can be "video", "action", "watch next" and "Mel Gibson before he
wasn't cool anymore" at the same time. If I want to get a list of stuff to
watch next, I filter by that. If I want to get rid of some old video
torrents I click on "video" and sort by date. Et cetera.
It's impossible to fit that use case in narrow definition of "each torrent
is in one group from predefined list of groups".
Ideally I would be able to sort by more than one label and if possible
with different combinations like "torrents with ALL these labels, torrents
with ANY of these labels". But I have not figured out gui for that yet.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#79 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA-jtvazwA-aS6HwKjaR0gxZF2hfVAjoks5vFo6kgaJpZM4Kqs3l>
.
|
#822 is merged, labels are now supported server side and in transmission-remote. I won't work on any of official GUI clients because I don't use any of them but it should be much easier for someone to pick this up. RPC protocol change is documented and it's a relatively straightforward feature. I'll work on adding labels support in transmission-remote-gui project. |
duplicate of #38 ? |
Labels have now been released alongside v3.0, so I think this issue can be closed. Edit: In retrospect, even though transmission has labels, it doesn't seem like all the interfaces do yet so we should probably keep this issue open. The web interface doesn't seem to have a way to modify labels yet. |
It seems that since 3.x we can obtain and set labels on existing torrents, but none of my labels set from the Mac client are visible when I query the RPC server for labels. In particular, I send a request l such as {
"arguments": {
"fields": ["id", "labels"]
},
"method": "torrent-get",
"tag": 4649
} Then every single entry from the server has an empty EDIT It seems qu1ck's latest comment answers my question, which in case, does anyone know some concrete steps for modifying the Mac client to make labels synonymous with groups? |
@kakuhen The Mac app has its own ‘groups’, separate from everything else. |
From my just-filed "filesystem-level tag support" request, I think that functionality would also serve the purposes of this issue quite well. Having parity between tags/labels applied in-app and on-disk would permit easy use of these indicators in both the app and via Finder or other file management utility. |
I'm Leeching and Seeding hundreds of torrents at the same time, so it's obvious I have to sort them in one way or another.
Unfortunately Transmission seems to don't have any Tagging functionality that would allow me to give my Torrents additional names like: Movie, Music, Sorted, Not-Sorted, To Fix, Fixed etc. which improves workflow by alot.
For now I have to scroll through all the torrents and check their directory to somehow guess which ones are sorted and which ones aren't.
I bet it's a hard thing to implement, looking at how old Transmission is and still doesn't have such basic options.
My setup:
Arch Linux Server Machine
transmission-cli 2.92-5
Torrents managed through Web Interface
The text was updated successfully, but these errors were encountered: