Use WebTorrent instead of deluge?
maple3142 opened this issue · 21 comments
This is good for making less complicated dependencies to installation but how can I monitor the downloading queue. I've tried webtorrent $magnet --vlc
but it's too slow and webtorrent $magnet
but it can't close terminal session.
The same issue happens if use aria2
(node wrapping). That's why I use deluged
and deluge-console
. If any node module can do both functions, I would happy to change deluge
by that.
I also have a plan to write a server-client that server is daemon (any magnet client) and client is cli (or webUI or both).
or open another option API this like:
$ dmhy --webtorrent -d[--dest] $HOME
?
I think use a command template is better. It is easy to integrate with other downloader.
Example(may be need to use exec
rather that spawn
):
deluge-console add $link$ #default
webtorrent $link$ -o anime/$title$
# And others...
And use detached
option can let main process close without closing child process.
const {spawn}=require('child_process')
const p=spawn('webtorrent.cmd',process.argv.slice(2),{
detached: true,
stdio: 'ignore'
})
p.unref()
process.exit()
I prefer $$title
keep the same to magnet setting. It can be another option also but miner priority.
I'll write the option API --webtorrent
to call child process. The default destination can use downloads-folder
but optional with -d/--dest
.
The most annoying thing in this change is README. 😂😂
cc @maple3142
I tested webtorrent
and some wired bugs happened.
If a magnet stuck, that detached process will wait forever and no one can handle until user kill
it. In the worst case, the stuck magnets will spawn A LOT of process (especially use cron
or debugging) and no one manage them. But deluged
can handle those not finished magnets even restart deluged
.
I'll try to support aria2
as a similar tool instead of webtorrent
later.
@FlandreDaisuki
I think create a wrapper script which pipe stdin,stdout between `webtorrent' command, and add some protection.
Then spawn it from main process?(detached)
Update: It works after add shell:true
in spawnOpt
I'm not familiar on child_process
, and here is a workaround and some bug
After I call $ dmhy --client aria2c -d /tmp dl LHK-05
, then ps aux | grep aria2c
instantly, but I can't find running process. I also print the command which pass to spawn
and work if execute in terminal directly.
It is because spawn(command: string,args: string[],options: object)
.
In this case, I think exec(command: string,options: object)
is better.
Reference: Child Process
commit/1220ce44 is a alpha version of support aria2c
. (not from npm)
Let's try for a while. 😂
目前有幾種 option 但我不確定要全兜在一起可不可行:
- deluged(server) + deluge-console(RPC) + deluge(UI) 這最沒問題
- aria2c(server) + aria2crpc(RPC) + webui-aria2(UI) 架構會跟上面一樣,依賴也差不多麻煩
- shell call 系列
- webtorrent: 卡住就無解了,無法設定做種時間 (要手動 kill process)
- aria2c: 有 timeout,有 seed-time 來讓 process 自動結束但卡住還是無解
aria2c可以算shell call
aria2crpc也不難,不過需要用額外的option
webui之類的不用處理吧,它們就我的理解不都是使用jsonrpc去取得aria2c服務的資訊嗎?
webtorrent直接在downloader/webtorrent.js裡用require('webtorrent')去用就好了吧
最困難的就是這個 webtorrent 不會自己結束的問題 🙈
要是走射後不理的 detached 路線,卡住要手動 kill (之前說過如果搭配 cron 排程有可能開好幾十甚至上百個 process)
要是走跟著 parent process 路線(你 fork 改的那種),手動下指令要是卡住還可以 ^c
來終止,要是自動排程同理會生出一大堆無法結束的 process,此外有多個 threads(帖) 的情況也會塞車
所以我還是偏好完全放棄 shell call 系列,去支援上面兩個
因為如果用 aria2c 的 shell call, 就必須下 --seed-time
參數,這也決定了 process 存活時間 (也跟排程頻率有關),直接下 --seed-time=0
技術上沒問題但破壞整個 BT 生態系 🤔
不會自己結束的是 webtorrent-cli
webtorrent
在 client.on('close',cb)
時結束process就好
而aria2c的 --seed-time
我覺得直接做成選項就好吧,讓使用者自己覺得
webtorrent 在 client.on('close',cb) 時結束 process 就好
我是在Docs有看到 client.destroy(callback)
但你要在什麼條件下執行他?假設 client.torrents[] 中就是有一個只有 10% 而且 no peers
如果是平行下載你要在什麼條件下結束他?
如果是順序下載那個 10% 就是卡在第一個下載不下來後面全卡住?
這樣是不是連 main process 也要跟著設 timeout... 🤔
aria2c 的 RPC 版本我可能會想辦法設計的好看一點,包含 timeout 那些設定
架構不是對於每個下載就execFile
一次嗎,因此會有多個downloader/webtorrent.js
的process
而在裡面每個都有一個client,每個client只會下載一個torrent
而下載queue的控制應該放在Database
裡面
不過這又會面臨到main process不能exit
aria2c
也有這問題
execFile 我沒用過我不確定這樣的想法(main#execFile → downloader/*.js)會不會有什麼雷就是了ww
不過 execFile 有 timeout 可以設應該是還行,看來全域 timeout 不可避了 🙈
有空再來改好了... (不知道為什麼沒有人寫 JS 的 torrent 帶 UI + API 的管理器... 💀)
不需要在db.download放timeout吧,都由downloader自己控制,db.download只負責呼叫downloader而已
他不是管理器,他原本的目的也和一般的 torrent client 不一樣
所以用 webtorrent 來載 BT 感覺真的很奇怪...
webtorrent
和aria2c
(非RPC模式)都是用來做單次下載用的,不像有個後台服務
我覺得最終解還是另外寫一個 dmhy-subscribe-server
把整個 aria2 包進去
然後這個 cli 就是送 RPC request 給 server
server 部份還可以架在 pm2
上
我當初不是想做單次下載使用的,是給排程檢查用的,檢查完就關掉,所以才這樣設計