jipaix / xdccjs Goto Github PK

Hello again, sorry for writing directly 2 tickets in a row.

Maybe I'm doing something wrong or just don't understand it right.
Right now I wanted to test the resume functionality of an aborted or failed download.

I tried the following usecases through code-flow and through cli-flow. Both failed on me.

Step 1:
npx xdccJS --host irc.rizon.net --bot "CR-HOLLAND|NEW" --nickname climan --channel #subsplease --download 2679 --path __dirname

Step 2:
Abort download after 2-3 seconds.
(On unix - terminals you can abort the running command with command+c)
In code-flow I just wrote
setTimeout(() => { job.cancel() }, 3000)

Step 3:
Now I'm just restarting the download from step 1 again.

Result:

connected to : irc.rizon.net
joined: [ #subsplease ]
> sending command: /MSG CR-HOLLAND|NEW xdcc send 2679
[X] couldn't connect to 89.149.202.221:12345
[X] couldn't connect to 89.149.202.221:12345
[i] retrying: 1/1
[X] couldn't connect to 89.149.202.221:12345
[X] couldn't connect to 89.149.202.221:12345
[X] skipped pack: 2679
[X] couldn't download pack: 2679 from cr-holland|new

The only solution right now is to delete the file from the folder specified in the path-variable from step 1 completely.
Only then the download will restart again.

Any ideas how this can be fixed?

Describe the bug
Some communities require the user to join multiple channels in order to download. For example: #MOVIEGODS requires users to also join #mg-chat, otherwise the bots will simply ignore the users requests. While the CLI option --channel [chan...] does exist, it does not seem to function correctly. xdccJS only seems to join the first channel.

To Reproduce
xdccJS --host irc.abjects.net --bot "some_bot" --download "#123" --channel "#MOVIEGODS" "#mg-chat"

Expected behavior
Join both channels before DMing the bot.

Actual behavior
Only #MOVIEGODS is being joined before DMing the bot. The bot then ignores the request, because the user is not in #mg-chat.

Context:

• OS: Linux Mint v20.3
• Version: v4.5.0

Server creation must be done here:

adding something like this (just an idea):

const client;
const server;
if (fileInfo.port === 0) {
  server = net.createServer(c => {
  // timeout(()=>{})
  client = c
  })
}

Then here:

add server and client to function passiveToFile :

passiveToFile(file, fileInfo, timeout, resp.nick, server, client) {
 if(server && client) {
   //=> DCC RESUME MSG
  } else {
   // Not a resume, setup a server as before.
 }
// server and client events
// server.listening(ip, port)
}

Describe the bug
wrong documentation statement on front page as advised user to use -- server
which provides [ error: unknown option '--server' ]

To Reproduce
just following save profile section user will get a error about --server

Expected behavior
to save profile, user has to use --host instead

Screenshots

Context:

• OS: Windows
• Version: 64bit

Additional context
just a small correction on front page .

Originally posted by @omgbox in #229 (comment)
Solution: #239 (comment)

keep downloading file even if vlc socket is closed . its not really important but would be nice as not to restart the same download.

What's a weebwee?

It's a Web User Interface, by definition « a control panel in a device presented to the user via the Web browser »

but what for ?

command-line is so 70's, wouldn't you rather use xdccJS with a nice graphical interface you can interact with?

Click to vote:

Describe the bug
I used the example template from the readme page, changed the server address to irc.freenode.net and ran that, but node will just run for a second or two and then shut down without any info. I expect it to run all the time until I shut it down?
Am I supposed to do something different? Am I missing error messages anywhere? I also tried using the irc-frameworks raw event but there nothing gets output as well. Is this also maybe not designed for continuous running?

To Reproduce
Steps to reproduce the behavior:

1. Use the template from the readme page
2. exchange the server url for e.g. freenode
3. change the 'ready' function to do a log
4. node index.js

Expected behavior
The server would run, do the log and then just stay alive.

Context:

• OS: macOS Monterey
• Version: 4.4.19

Describe the solution you'd like

• Auto-resuming file if the filename's the same

Describe the bug
user installed 64bit VLC there is a difference in path which is under C:\Program Files (x86)\VideoLAN\VLC\vlc.exe

To Reproduce
install 64bit and check path

Expected behavior
global path maybe to include 64 and 32 paths for vlc and maybe mpv path

Screenshots

Context:

• OS: windows
• Version: 64

Additional context
maybe include both 64 and 32 pathways for binary. optional to include mpv , allow user to save player pathway when saving profile.

Describe the solution you'd like

• formatted, consistent and colorful messages
• currently downloads have a lesser level of logging if they are piped

Firstly, thank you for making this! It was one of the few tools I could find that actually worked on all the servers I tested it on 😀

Some servers give a wait time before you can download, this has been sorted with the --wait time argument, however most servers will remove this waiting time if you identify with NickServ with a registered nickname (/msg NickServ IDENTIFY <pass>). Being able to provide xdccJS a password to do this would shave of the waiting time and would be extremely useful.

Is your feature request related to a problem? Please describe.
It would be awesome to make available the ETA also in the downloading event

Describe the solution you'd like
It could be the forth parameter of the downloading event handler

Describe alternatives you've considered
Calculate it by myself

Additional context
In order to have better informations about the download in progress, ETA is a crucial information in my opinion

Describe the bug
when a download error occures and xdccJS.path is set to false xdccJS should emit a download-err instead of a pipe-err

should be :

 this.emit('pipe-err', err, fileInfo) 

issue

[...]

Nevertheless, I was still not getting my download started. Upon further investigation, I think that this might have something to do with the bot queuing my request, but xdccJS aborting the download after a fixed 30 second timeout. Unfortunately, the timeout is currently not configurable through the CLI (moviegods is very highly frequented and queuing times > 10min do regularly happen).

This currently leads me to a couple of "feature requests" and a bug report:

• A CLI option to configure the request timeout (to accomodate queues)
• A CLI option to log private bot messages to the console (to debug if the bot has a problem with my request or is queueing it)

[...]

Originally posted by @mikeputh in #500 (comment)

requirements

• Add Job.on('message') to listen to bot's message
• When verbose is true, bot message should always be displayed.
• 🚫 Add queueTimeout (or similar name) to XDCC constructor PARMAS
• 🚫 Add --queue-timeout (or similar name) to XDCC CLI options.
• 🚫 use that instead of the fixed 30s
• add queue parameter which is a regex
  • cancel timeout if bot sends a message matching queue
  • implement this for the CLI

Describe the bug
terminal weird font character

To Reproduce
npm install xdccjs -g

Expected behavior
show normal fonts

Screenshots

Context:

• windows 64bit
• Version: latest US language Windows

Additional context
green, white, blue weird [?] symbol

Hello, yesterday I tried to implement a couple of things with your library.
I decided to go by the typescript flow.

The problem is, neither the XDCC-class, nor the Job-class expose listener methods.

The only way right now to listen for "download" or "downloading" events is to go through the .irc object.

README.md includes this line:

xdccJS includes (and extends) @kiwiirc/irc-framework, if you need more advanced (IRC) features check their documentation and some examples on how its used with xdccJS

This line was correct until commit 2ca67d9, after that the XDCC class was refactored to extend not Client but CtcpParser, then, on commit 82d45d9, this class was changed to extend EventEmitter.

Now the IRC client can be accessed by the irc property, but it's not noted in the documentation.

issue

• A small fix in XdccJSbin.writeMSG and XdccJSbin.clearMSG to also work in non-TTY environments (xdccJS is currently crashing when run in a non-TTY environment like nohup xdccJS ... & - more details here)

Originally posted by @mikeputh in #500 (comment)

requirements

• dependency free solution OR highly maintained package

Describe the bug
TLS connections do not work

To Reproduce
Steps to reproduce the behavior:

1. Create an XDCC client with the following options:
   tls: { enable: true, rejectUnauthorized: true }
2. Run the program
3. No output, program just ends.

Expected behavior
Client should establish a connection.

Context:

• OS: Windows 11
• Node: 16.19.0
• Typescript: 4.9.4

Sample code to replicate

import XDCC from 'xdccjs'

const xdccJS = new XDCC({
  host: 'irc.server.net',
  chan: ['#channel'],
  nickname: 'Nickname',
  tls: {
    enable: true,
    rejectUnauthorized: false
  }, 
  path: './tmp/',
  verbose: true
})

xdccJS.on('ready', () => {
    console.log("XDCC client ready")
})

This code was written with typescript if that matters.

"XDCC client ready" does not get logged. The program just ends with no output. However, removing the TLS option does connect to the host. Also, host does work with TLS connections as connecting via "HexChat" client with the TLS option works.

Is your feature request related to a problem? Please describe.

I have an automated downloader running on my server that will start to download files whenever they're available. This can be at arbitrary times, but ends up choking my network for larger files. Since there is no way to cap the download speed, my only option is to stop the download and retry at a later time, or not stream any videos for the duration of the download.

Describe the solution you'd like

Ideally, I'd like to set the maximum download speed for a single or all jobs. This limit should be adjustable dynamically by calling something like job.throttle(2048*1000) in order to update the maximum download speed to 2 MB/s.

Describe alternatives you've considered

I've previously used solutions like wondershaper, but that limits the whole network adaptor and not just a single node program. I'm sure there would be ways to limit the network bandwidth of the node program using a secondary tool, but I think adding a download speed limit would be fitting for a downloader library like this.

Additional context

There are some packages on npm that can limit streams, like speed-limiter or throttled-reader. However, I'm not sure if they will actually impact TCP's flow control, of if the download will use the same bandwidth, caching the data before sending it through the throttled stream.

Would love to discuss this with you!

I noticed a problem, that my downloads keep getting aborted at random points now, which I have not encountered before. I am still investigating if it's due to a shaky internet connection or if the download gets aborted when a Bot message comes in (e.g. new pack announcement). I suspect the latter, but don't know for sure.

Log:

> connected to : <NETWORK>
  > joined: [ #CHANNEL1 #CHANNEL2 ]
    > sending command: /MSG <BOT NAME> xdcc send <PACKAGE NUMBER>
        @<BOT NAME>: ** Sending you pack #<PACKAGE NUMBER> ("<PACKAGE NAME>") ...
     [i] downloading : <PACKAGE NAME>
      | [=============       ] ETA: 3 minutes 8s @ 14.98 MB/s - 68%[X] Connection error: read ECONNRESET
     [X] Connection error: read ECONNRESET
      [i] retrying: 1/1
[X] Connection error: read ECONNRESET
     [X] Connection error: read ECONNRESET
      [X] skipped pack: <PACKAGE NUMBER>
      [X] couldn't download pack: <PACKAGE NUMBER> from <BOT NAME>

Originally posted by @mikeputh in #500 (comment)

it appears there might be some issue with setting up profiles, it seems to save the profile but it does not detect it
I have removed and reinstalled xdccjs with the same issue. streaming now works on vlc.

Originally posted by @omgbox in #229 (comment)

Describe the bug
Omitting passivePort in the constructor results in this error : unexpected type of 'passivePort': an array of numbers was expected

To Reproduce

const XDCC = require('xdccjs').default
let opts = {
    host: 'IRC.rizon.NET',
    nick: 'xipai',
    chan: ['horriblesubs'],
    path: 'downloads',
    port: 6667,
    verbose: true,
    randomizeNick: true,
}
const xdccJS = new XDCC(opts)

Expected behavior

• No errors
• When omitted, passivePort must be automaticaly set to it's default value : [5001]