homelab/manifests/media/jdownloader.md

Sending links to JDownloader

jdownloader (manifests/media/jdownloader.yaml) runs a cnl-bridge sidecar that accepts a URL over HTTP and writes it as a .crawljob for JDownloader's FolderWatch extension to pick up. This exists because all containers in the pod share one network namespace, so JDownloader's own built-in Click'n'Load2 listener (which also defaults to port 9666) can't be reached independently from outside the pod for this purpose.

Endpoint

POST https://jdownloader.home.arpa/add
Content-Type: application/x-www-form-urlencoded

urls=<the download URL>

Example:

curl -X POST https://jdownloader.home.arpa/add \
  --data-urlencode "urls=https://ash-speed.hetzner.com/100MB.bin"

A 200 Ok. response means the bridge wrote the .crawljob file. JDownloader's FolderWatch extension polls every ~10s, picks it up, and adds it directly to the Downloads list — both autoStart and autoConfirm are set, so it starts downloading without needing manual confirmation in the LinkGrabber tab.

Package naming

The package name is derived automatically from the URL: the last path segment, with everything from the first . onward stripped — so multi-extension names collapse to the base identifier.

URL	Package name
https://ash-speed.hetzner.com/100MB.bin	100MB
https://example.com/abcdefg/1234567.mp4.html	1234567

Falls back to subyshare if the URL has no usable path segment.

Notes

• Only the first urls value in the POST body is used — one link per request.
• The bridge listens on container port 9667 internally; the Service exposes it externally as port 9666 (targetPort: 9667), so callers of /add are unaffected by the internal port. The indirection exists because JDownloader's own CNL2 listener already binds 9666 inside the shared pod network namespace.
• Source: the inline Python script in the cnl-bridge container of manifests/media/jdownloader.yaml.