Error: imput stream: aborted

[VoidDave]

Today i wrote simple play command for discord bot. But after some time of music plaing i get this error My code for music play is:

const { Permissions:{FLAGS} } = require ("discord.js")
const ytdl = require('ytdl-core')
const fs = require('fs')

module.exports={
    name: "play",
    description: "Puszczanie muzyki",
    args: true,
    usage: "<tytuł/url>",
    guildOnly: true,
    cooldown: 10,
    aliases: ["p"],
    botPermissions: [FLAGS.CONNECT,FLAGS.SPEAK],

    async run(message, args) {

        //console.log(args)
        const voiceChannel = message.member.voice.channel
      if(!voiceChannel) return message.channel.send("Potrzebujesz być na kanale głosowym by to zrobić")

      try {
          var connection = await voiceChannel.join()
          } catch (error) {
              console.log(`There was an error connecting to the voice channel: ${error}`)
          }

          const dispatcher = connection.play(ytdl(args[0],{Quality: 'highestaudio'},{filter:'audiooly'},{highWaterMark: 1<<23},{dlChunkSize:0}))
          .on('finish',() => {
             voiceChannel.leave()
          })
          .on('error', error => {
             console.log(error)
          })
          dispatcher.setVolumeLogarithmic(5 / 5)
    }
}

Any ideas how to fix it ?

[fent]

does calling ytdl by itself show this error too? or only with discordjs? what's your version? a similar bug was recently fixed.

[VoidDave]

I dont know . And im using the newest version of discord js and ytdl How similar bug was fixed ?

[super1zero]

Question: how can i get the transcript from the youtube url?

[TheSheff93]

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

[InanisOmnia]

I am having this issue as well I can play about 3 or 4 songs and then this issue occurs> Interestingly it is not at the beginning or end of a video but can be anywhere randomly

I too am using Discord.js and this error is called from the Discord Voice Dispatcher however it is clearly in relation to the input stream, which in our case is ytdl-core

Raspberry Pi (Raspbian - latest) nodejs @15.x.x

ytdl-core @4.5.0 ffmpeg-static @4.2.8 discord.js @12.5.1 @discord.js/opus @0.3.3

[VoidDave]

Today i runed test that author submit in the his code and got this error : (logs below) 0 verbose cli [ 0 verbose cli 'D:\\nodejs\\node.exe', 0 verbose cli 'D:\\nodejs\\node_modules\\npm\\bin\\npm-cli.js', 0 verbose cli 'run', 0 verbose cli 'test:irl' 0 verbose cli ] 1 info using npm@7.5.1 2 info using node@v15.8.0 3 timing config:load:defaults Completed in 1ms 4 timing config:load:file:D:\nodejs\node_modules\npm\npmrc Completed in 3ms 5 timing config:load:builtin Completed in 3ms 6 timing config:load:cli Completed in 1ms 7 timing config:load:env Completed in 0ms 8 timing config:load:file:C:\Users\polsk\Downloads\node-ytdl-core-master\node-ytdl-core-master\.npmrc Completed in 0ms 9 timing config:load:project Completed in 1ms 10 timing config:load:file:C:\Users\polsk\.npmrc Completed in 0ms 11 timing config:load:user Completed in 0ms 12 timing config:load:file:C:\Users\polsk\AppData\Roaming\npm\etc\npmrc Completed in 0ms 13 timing config:load:global Completed in 0ms 14 timing config:load:cafile Completed in 0ms 15 timing config:load:validate Completed in 0ms 16 timing config:load:setUserAgent Completed in 1ms 17 timing config:load:setEnvs Completed in 0ms 18 timing config:load Completed in 7ms 19 verbose npm-session 588df15ba9a49949 20 timing npm:load Completed in 14ms 21 timing command:run-script Completed in 7681ms 22 verbose stack Error: command failed 22 verbose stack at ChildProcess.<anonymous> (D:\nodejs\node_modules\npm\node_modules\@npmcli\promise-spawn\index.js:64:27) 22 verbose stack at ChildProcess.emit (node:events:378:20) 22 verbose stack at maybeClose (node:internal/child_process:1067:16) 22 verbose stack at Process.ChildProcess._handle.onexit (node:internal/child_process:301:5) 23 verbose pkgid ytdl-core@0.0.0-development 24 verbose cwd C:\Users\polsk\Downloads\node-ytdl-core-master\node-ytdl-core-master 25 verbose Windows_NT 10.0.19042 26 verbose argv "D:\\nodejs\\node.exe" "D:\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "run" "test:irl" 27 verbose node v15.8.0 28 verbose npm v7.5.1 29 error code 4 30 error path C:\Users\polsk\Downloads\node-ytdl-core-master\node-ytdl-core-master 31 error command failed 32 error command C:\Windows\system32\cmd.exe /d /s /c mocha --timeout 16000 test/irl-test.js 33 verbose exit 4

[flojo007]

Hi,

I'm getting this error too

ytdl-core@4.8.0 ffmpeg-static@4.3.0 discord.js@12.5.3 @discord.js/opus@0.3.3 I can provide more info if needed

[TimeForANinja]

🤔 it would be cool to do some modifications to discord.js to check for ffmpeg errors

other than that this is pretty unfixable in the current situation... we'd need a way to reproduce this error without discord.js... or at least narrow down if it is actually discord.js or ytdl-core...

[InanisOmnia]

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!

[Topiya]

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!

@LordFarquhar Did you find any solution yet ? I am facing a same issue.

[InanisOmnia]

Changing that node version seemed to solve it all for me

[Topiya]

Changing that node version seemed to solve it all for me

@LordFarquhar Thank you for the reply. Can you let me know which version of node and pm2 did you use in production?

[Hazmi35]

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

[InanisOmnia]

Node LTS, pm2 latest update DiscordJS is at the latest stable update

[Hazmi35]

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

[rojvv]

I've the same problem. I'm streaming to Telegram.

[rojvv]

Here are my options.

[rojvv]

Oh and here's my Node version.

[rojvv]

thinking it would be cool to do some modifications to discord.js to check for ffmpeg errors

other than that this is pretty unfixable in the current situation... we'd need a way to reproduce this error without discord.js... or at least narrow down if it is actually discord.js or ytdl-core...

Here I get it without Discord.js, @TimeForANinja. :)

I'm using ytdl-core-telegram, gram-tgcalls and GramJS.

[GaryCraft]

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

[redbrain]

@GaryCraft Try using a stable version of Node (ie the v14 LTS) and see if that fixes it?

[GaryCraft]

@redbrain the thing is that I need to use Node v 16+

[ARR4NN]

I am having the same issue with it aborting playing.

[mtripg6666tdr]

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

[mtripg6666tdr]

I can reproduce the issue only with node(v16.6.1), ytdl-core(v4.9.1), prism-media(v1.3.2) and node-opus(v0.3.3). I don't know if this is helpful but the complete source code is here: https://github.com/mtripg6666tdr/ytdl-test/blob/master/src/index.js

[kane50613]

I've noticed that this error happens every time when a song plays to 30 minutes

[mtripg6666tdr]

Maybe the time when this error occur related to highWaterMark and actual size of the stream. When I played a stream, it occurred in sometimes 44 minutes, at other times in 28 minutes (highWaterMark was set default). When I played an other stream, it occurred in 57 seconds.

[kane50613]

is this looks like related problem fent/node-feedsub#60

[mtripg6666tdr]

is this looks like the same problem fent/node-feedsub#60

This error occurs nodejs v15 or more only, same as the issue you mentioned. So this issue might be solved by updating miniget version. (unverified yet) I will try it!

[kane50613]

is this looks like the same problem fent/node-feedsub#60

This error occurs nodejs v15 or more only, same as the issue you mentioned. So this issue might be solved by updating miniget version. (unverified yet) I will try it!

i just tried to fork this repo and update miniget to v4.2.1 and still gets the problem

[mtripg6666tdr]

Unfortunately I also got the problems with miniget@4.2.0 just same as you in 14 minutes.

[mtripg6666tdr]

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.

[rojvv]

cmon speak for telegram too, telegram is a thing too hehe

[mtripg6666tdr]

cmon speak for telegram too, telegram is a thing too hehe

Does telegram bots need Node.js v15 or later?

[rojvv]

cmon speak for telegram too, telegram is a thing too hehe

Does telegram bots need Node.js v15 or later?

Depends on what lib you use, normal Telegram bots can’t speak in voice chats. You should use a userbot with an MTProto lib to join a call and a Telegram WebRTC library to stream.

I’m using GramJS as the MTProto library, GramTGCalls and grammY for the bot.

My source code is here.

[mtripg6666tdr]

cmon speak for telegram too, telegram is a thing too hehe

Does telegram bots need Node.js v15 or later?

Depends on what lib you use, normal Telegram bots can’t speak in voice chats. You should use a userbot with an MTProto lib to join a call and a Telegram WebRTC library to stream.

I’m using GramJS as the MTProto library, GramTGCalls and grammY for the bot.

My source code is here.

I cloned it and tried removing engines lines in package.json and executing npm install --engine-strict but no error displayed So if the source code of the bot doesn't contain any code that can be work only with Node.js v15 or later, the bot might work in Node.js v14 or less. Could you try to run npm i node@v14-lts and execute npx node dist

My node.js and npm versions are: Node: v14.16.0 npm: 7.21.0

[rojvv]

cmon speak for telegram too, telegram is a thing too hehe

Does telegram bots need Node.js v15 or later?

Depends on what lib you use, normal Telegram bots can’t speak in voice chats. You should use a userbot with an MTProto lib to join a call and a Telegram WebRTC library to stream. I’m using GramJS as the MTProto library, GramTGCalls and grammY for the bot. My source code is here.

I cloned it and tried removing engines lines in package.json and executing npm install --engine-strict but no error displayed So if the source code of the bot doesn't contain any code that can be work only with Node.js v15 or later, the bot might work in Node.js v14 or less. Could you try to run npm i node@v14-lts and execute npx node dist

My node.js and npm versions are: Node: v14.16.0 npm: 7.21.0

Did you try playing a live YouTube video?

[mtripg6666tdr]

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

[rojvv]

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

OK lol.

[mtripg6666tdr]

So I wrote

Could you try to run npm i node@v14-lts and execute npx node dist

[x5engine]

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

OK lol.

I love this solution :D

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[rojvv]

Sad.

[mtripg6666tdr]

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.

[ppodds]

Still broken.

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

[luisAzcuaga]

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

Thanks a lot! I did that highWaterMark solution and fixed at least for an almost 4 minutes long song ("Something About Us"), also tested with "All Nightmare Long" and "The Day that Never Comes" (both ~8 mins)

I'm currently using Node v16.14.0 And here are my other module versions :)

    "@discordjs/opus": "^0.7.0",
    "discord.js": "^12",
    "dotenv": "^16.0.0",
    "ffmpeg": "^0.0.4",
    "ffmpeg-static": "^4.4.1",
    "fluent-ffmpeg": "^2.1.2",
    "ytdl-core": "^4.11.0"

Update

"The Day that Never Comes" led to the same issue. Maybe we should catch "really long songs" before atempting to playig them? I'm not very skillfull when it comes to javascript streams foundations, but I think play-dl would suffer from the same if a really long song is atempted to play, right?

[mtripg6666tdr]

I heard play-dl won't cause the issue. At least at the current you can let highWaterMark much higher, use my above fragmental download approach, downgrade Node.js to v15 or lower, or play-dl to prevent from the issue.

[maximosdrr]

Is there any solution yet ?

[maximosdrr]

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,
    });

[Tomato6966]

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?