node-ytdl-core: Error: imput stream: aborted

const ytdl = require("ytdl-core");

const stream = ytdl("song-url", {
     filter: "audioonly",
     fmt: "mp3",
     highWaterMark: 1 << 62,
     liveBuffer: 1 << 62,
     dlChunkSize: 0, //disabling chunking is recommended in discord bot
     bitrate: 128,
     quality: "lowestaudio",
});

Using such settings from ytdl-core allows you playing songs over 60 mins with easy and no abortion error at all

1 << 62 gives the biggest number

Why bitrate 128?

Discord can not transfer audio with an higher bitrate! (unless 3 boost levels and bitrate is at 396kbps) Valid bitrates: 32, 40, 48, 56, 64, 80, 96, 112, 128, 160, 192, 224, 256 and 320 kBit/s Why quality lowestaudio, you won’t hear that much of a difference?

Can reproduce on Windows and Linux on Node.js v16 (16.5.0), but this issue does not exist on v14 (14.17.3). Using ytdl-core and piping it to fs.createWriteStream does not have any issue, only if ytdl-core + Discord.js has this issue, probably related to discordjs/discord.js#5214, and probably has something to do with highWatermark, will update the situation later

Confirmed, setting ytdl-core highWatermark option to 32MiB on Node.js v16 (16.5.0) fixes the problem, so the workarounds are use Node v14.x or play with the highWatermark settings, not sure if this will apply to everyone

Here are my options.

Still broken.

A substitute package: https://www.npmjs.com/package/play-dl

This solve my problem, unfortunately ytdl still broken given an issue with miniget

#EDIT

If you wanna replace ytdl as well have a look in the example bellow, here I replace my ytdl stream with play-dl stream

##Before:

import ytdl from "ytdl-core";

const stream = ytdl(song.url, {
      filter: "audioonly",
      highWaterMark: 32768,
    });

##After:

import play from "play-dl";

const { stream } = await play.stream(song.url, {
      discordPlayerCompatibility: true,
    });

Been getting this issue after playing for a while. then it errors out.

Error: aborted

at connResetException (node:internal/errors:691:14)
at TLSSocket.socketCloseListener (node:_http_client:407:19)
at TLSSocket.emit (node:events:406:35)
at node:net:672:12
at TCP.done (node:_tls_wrap:580:7) {
    code: 'ECONNRESET'
}

Node: 16.6.1 ytdl-core: 4.9.1

So im running a small discord bot called Tinker I run development on my laptop and production on my raspberry pi. The issue does not seem to occur when in development. The only differences are, of course the OS, and the nodejs version. The code is the exact same Here are the stats of the two:

Development (no issues) Windows Home (latest updates) node index.js run directly in terminal (Command Prompt) nodejs: v14.16.1

Production (fairly regular “Input Stream Aborted” errors) Raspbian (latest updates) pm2 start tinker pm2 process manager, configured with the correct nodejs runtime nodejs: v16.0.0

Edit

I have just done a further test, running my production with all the same settings and system but with nodejs v 14.16.1 and no errors whatsoever. Nodejs version appears to be the culprit (at least in my instance). I hope this helps some people with issues and the devs with fixing the error. Love the package and keep up the good work!

Still broken.

A substitute package: https://www.npmjs.com/package/play-dl

Recently I came up with idea with fragmental downloads. and everything works well for me by downloading tiny fragments that are each as small as 1MB and piping them into one stream. for example:

export function createYTStream(info:ytdl.videoInfo, format:ytdl.videoFormat, options:ytdl.downloadOptions, chunkSize:number = 512 * 1024 /*stream size of each partial stream*/){
  const stream = new PassThrough();
  let current = -1;
  const contentLength = Number(format.contentLength);
  if(contentLength < chunkSize){
    // stream is tiny so unnecessary to split
    ytdl.downloadFromInfo(info, {format, ...options}).pipe(stream);
  }else{
    // stream is big so necessary to split
    const pipeNextStream = () => {
      current++;
      let end = chunkSize * (current + 1) - 1;
      if(end >= contentLength) end = undefined;
      const nextStream = ytdl.downloadFromInfo(info, {format, ...options, range: {
        start: chunkSize * current, end
      }});
      nextStream.pipe(stream, {end: end === undefined});
      if(end !== undefined){
        // schedule to pipe next partial stream
        nextStream.on("end", () => {
          pipeNextStream();
        });
      }
    };
    pipeNextStream();
  }
  return stream;
}

I hope this will help. P.S. the tricky solution that I wrote in this issue before doesn’t work well now in current version of discord.js. It will work in discord.js v13.1.0 only.

Still no valid solutions? 2024 and still this issue persists in discord/js bots. The one provided above by 0xAnakin doesn’t work.

I captured network traffic using Wireshark. I found that a remote server sends a “TCP [RST]” packet (to close the connection) after the node.js sends “TCP ZeroWindow” packets some times. Also I’ve noticed a “TCP Window Update” packet is successfully sent some times. However I couldn’t found any invalid network packet likely to cause connection reset. It looks like all working properly. (I might have overlooked because I’m a newbie of analyzing of network)

Anyway, if you want to use discord.js v13, I noticed you can provisionally use discord.js v13 with Node.js v14 or less. In order to run discord.js v13 on Node.js v14 or less, (a tricky way though) install AbortController npm package and write code below before calling the discord.js module. This makes discord.js work properly.

global.AbortController = require("AbortController");

Of course this solution might become unusable depending on updates since this is not a solution to the actual cause and right way to use discord.js v13. This works currently properly in my environment. sorry for my bad english

P.S. It will work in discord.js v13.1.0 only. In higher versions this won’t work well.

I am having tha same issue. I got a direct video url (like https://r8--***.googlevideo.com/videoplayback?***) via youtube-dl and tried playing directly with the url using miniget, but aborted error still occurred. Though this is not what prove the issue is of miniget, I think it might be the helpful information. highWaterMark option won’t solve the actual cause of the issue because it only makes the time to the error an error occurs longer.

node: v16.6.1 discord.js: v13.1.0 @discordjs/voice: v0.6.0 ytdl-core: v4.9.1 miniget: v4.2.1

Still no valid solutions? 2024 and still this issue persists in discord/js bots. The one provided above by 0xAnakin doesn’t work.

I just gave up of this package. Switched over @distubejs/ytdl-core. Working perfectly for this situation.

Well if I could hug you I would, I had to force it to update to the latest version of discord/js (npm i @discordjs/voice@latest) and switched to the core you use and I’m in business again. Appreciate the quick response!

Still no valid solutions? 2024 and still this issue persists in discord/js bots. The one provided above by 0xAnakin doesn’t work.

I just gave up of this package. Switched over @distubejs/ytdl-core. Working perfectly for this situation.

I’m sorry I don’t have any telegram account so I didn’t test it.

OK lol.

I love this solution 😄

I’m sorry I don’t have any telegram account so I didn’t test it.

OK lol.

I have this error show up quite frequently. I’ve run the ytdl-core tests by cloning the repo etc and no issues there The issue seems to arise after some time of playing, at which point it will crash and throw the error mentioned earlier.

I am running discord js 12.5.1 and ytdl-core 4.5.0 This has been occurring across multiple versions of ytdl-core for me.

Node: 15.5.1 Running on Ubuntu I can provide more info if needed