Opened 12 years ago

Closed 11 years ago

#2718 closed Enhancement (wontfix)

Support "blocklist-updates-enabled" feature in transmission-daemon

Reported by: jyoder Owned by: charles
Priority: Normal Milestone: None Set
Component: libtransmission Version: 1.76
Severity: Normal Keywords: patch-needed feature-disparity
Cc: eric@…

Description

Doesn't seem like this would be terribly hard to add support to since I know the GTK client supports it already.

Attachments (1)

patch-auto-update-blocklist.patch (8.4 KB) - added by lembregtse 12 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 12 years ago by charles

  • Keywords patch-needed added

There's an RPC call for this already ("blocklist-update") so the actual code should be pretty easy... if there's someone looking to get started on Transmission's internals, I think this would be a great place to get your feet wet before diving in the deep end. :)

comment:2 Changed 12 years ago by charles

  • Summary changed from Daemon doesn't support blocklist-updates-enabled to Support "blocklist-updates-enabled" feature in transmission-daemon

Changed 12 years ago by lembregtse

comment:3 follow-up: Changed 12 years ago by lembregtse

I've started working on something.

It's a raw version of an auto-blocklist-updater build in the session.

"blocklist-update-enabled": true, "blocklist-update-time": 12,

are set it should automatically update the blocklist from the transmission server, load it and keep a backup in ~blocklists directory.

Although the blocklist file is over 12 megabytes when not compressed so I would suggest something like a hash file on the transmission server so the client will not fetch the blocklist file when there is no update. And probably the compressed file should be used instead.

Currently default updating time is 12 hours (minimum).

See the patch.

More info following soon!

Kind regards,

Eric

comment:4 Changed 12 years ago by lembregtse

  • Cc eric@… added
  • Component changed from Daemon to libtransmission
  • Owner set to charles
  • Priority changed from Normal to Low
  • Version changed from 1.76 to 1.83+

comment:5 Changed 12 years ago by lembregtse

  • Priority changed from Low to Normal

comment:6 in reply to: ↑ 3 Changed 12 years ago by charles

  • Version changed from 1.83+ to 1.76

Replying to lembregtse:

Hi Eric!

This patch is a good start. Thanks for digging into libtransmission. :)

Although the blocklist file is over 12 megabytes when not compressed so I would suggest something like a hash file on the transmission server so the client will not fetch the blocklist file when there is no update. And probably the compressed file should be used instead.

I don't want to add a libz/libbz2 dependency to libtransmission, so there's not a good way of uncompressing the file. Also if the system's libcurl libraries are built with compression support, then the download will be compressed on the fly anyway.

Currently default updating time is 12 hours (minimum).

This is far, far too low. The default should be more like a week. The blocklist doesn't change quickly enough to warrant a 12 hour update.

See the patch.

I'm a little concerned that this code reinvents code already in place for "blocklist-update" in rpcimpl.c. There's not a C API for that, so possibly (1) this patch could become the C API for that, and the blocklist-update code in rpcimpl.c could be removed and call this patch code instead, or (2) this patch could form a simple JSON request and pass it to tr_rpc_request_exec_json()... ugly. ;)

comment:7 follow-up: Changed 12 years ago by lembregtse

Hi Charles,

Yeah it's my first time into this source so it's a little bit new for me. I had no idea how much the file changed so I picked a random value, I'll set it to a week, considering the time span the 12 MB shouldn't be to bad so that's ok.

I agree that it is the same as rpcimpl.c, but I found it not right to do a JSON request inside from the session.c to rpcimpl.c. So I prefer your number 1 solution for this.

Where should I, at best, put the "C API" code?

Anyhow, I'll look into it!

comment:8 in reply to: ↑ 7 Changed 12 years ago by charles

Replying to lembregtse:

Where should I, at best, put the "C API" code?

session.c, perhaps.

comment:9 Changed 12 years ago by charles

  • Keywords feature-disparity added

comment:10 Changed 11 years ago by jordan

  • Resolution set to wontfix
  • Status changed from new to closed

This has idled for a year now, and nobody else has seconded this feature request, so I'm going to close this ticket for now.

lembregtse, please reopen the ticket if you finish the patch. Thank you!

Note: See TracTickets for help on using tickets.