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 ?

[ddoodm]

Thanks heaps @Tomato6966 - can confirm that fixed it for me with a 3 hour stream

[varun-s22]

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?

Thanks it surely helped.. although can you explain what are highWaterMark and liveBuffer options

[eugabrielsilva]

@varun-s22 even with this settings, the problem still occurs :( hopely waiting for a fix from @fent

[varun-s22]

@varun-s22 even with this settings, the problem still occurs :( hopely waiting for a fix from @fent

hey @eugabrielsilva, it works fine for like a hour or something.. so its kind of a temporary solution, so :)

[0xAnakin]

I use this plugin to broadcast the audio to an ice-cast server. This is what worked for me (no more aborted error).

this.yt_download = yt_download(song.data.url, {
    filter: 'audioonly',
    fmt: 'mp3',
    highWaterMark: 1 << 30,
    liveBuffer: 20000,
    dlChunkSize: 4096,
    bitrate: 128,
    quality: 'lowestaudio'
}).once('error', (err) => {

    console.error(`[${this.name}]:`, err.message, '\n', err.stack);

    if (err.message.includes('410')) {
        this.removeItem(song);
    }

    this.next();

}).once('end', () => {

    console.log(`[${this.name}]: Downloaded song ${song.data.title}`);

}).pipe(this.ffmpeg.stdin);

[eugabrielsilva]

@varun-s22 even with this settings, the problem still occurs :( hopely waiting for a fix from @fent

hey @eugabrielsilva, it works fine for like a hour or something.. so its kind of a temporary solution, so :)

Weird thing is that, in my case, it still plays for about 15 seconds and then the stream aborts...

[eugabrielsilva]

@0xAnakin where is the "this.ffmpeg.stdin" coming from? How can I implement this?

[0xAnakin]

@0xAnakin where is the "this.ffmpeg.stdin" coming from? How can I implement this?

@eugabrielsilva this has nothing to do with the fix. The "fix" in my case were the options object passed. This one:

{
    filter: 'audioonly',
    fmt: 'mp3',
    highWaterMark: 1 << 30,
    liveBuffer: 20000,
    dlChunkSize: 4096,
    bitrate: 128,
    quality: 'lowestaudio'
}

In my case I wanted to pass the download to ffmpeg for further processing, This is not something you should worry about. I just copied the code from my script. just try the settings I pasted above. Also as a side note I should mention that I didnt get any "Aborted" errors when i was running my app locally, the issues started once I uploaded it on VPS server. After lots of trial and error and testing these settings worked for me. Hope it helps...

[BlackusPL]

@0xAnakin where is the "this.ffmpeg.stdin" coming from? How can I implement this?

@eugabrielsilva this has nothing to do with the fix. The "fix" in my case were the options object passed. This one:

{
    filter: 'audioonly',
    fmt: 'mp3',
    highWaterMark: 1 << 30,
    liveBuffer: 20000,
    dlChunkSize: 4096,
    bitrate: 128,
    quality: 'lowestaudio'
}

In my case I wanted to pass the download to ffmpeg for further processing, This is not something you should worry about. I just copied the code from my script. just try the settings I pasted above. Also as a side note I should mention that I didnt get any "Aborted" errors when i was running my app locally, the issues started once I uploaded it on VPS server. After lots of trial and error and testing these settings worked for me. Hope it helps...

For me everything works fine for 1 minute. After song stops, no console error and no Aborted. Any solution?

[Denveous]

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

[eugabrielsilva]

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.

[Denveous]

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!

[ELJoOker2004]

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?

Thanks it surely helped.. although can you explain what are highWaterMark and liveBuffer options

I want to know too what are highWaterMark and liveBuffer options, and when should I increase or decrease them

[Tomato6966]

highWaterMark is a limit (threshhold), which limits the amount of data which is cacheable by the internal (audio playback) stream. E.g. you could buffer 1s, or 60 s. On default it's 1 << 4, which equals to 16 and this means it stores 16 items in a buffer, before re-fetching the data to play again. If you set it to 1 << 64 is the maximum of data (1073741824 items ), like for normal videos we aim to buffer everything, to reduce likely issues because it either way fetches everything. If it's a 10hr video, it buffers like 2/10ths of it per internal fetch It makes loading maybe 1ms longer but it buffers the data and thus is less likely to fail.

Same for liveBuffer but that's just for live stream

note: the exact amount of buffering, is not really declareable due to nodejs

[ELJoOker2004]

highWaterMark is a limit (threshhold), which limits the amount of data which is cacheable by the internal (audio playback) stream. E.g. you could buffer 1s, or 60 s. On default it's 1 << 4, which equals to 16 and this means it stores 16 items in a buffer, before re-fetching the data to play again. If you set it to 1 << 64 is the maximum of data (1073741824 items ), like for normal videos we aim to buffer everything, to reduce likely issues because it either way fetches everything. If it's a 10hr video, it buffers like 2/10ths of it per internal fetch It makes loading maybe 1ms longer but it buffers the data and thus is less likely to fail.

Same for liveBuffer but that's just for live stream

note: the exact amount of buffering, is not really declareable due to nodejs

tysm for response, I got it now <3