Recherche avancée

Sur d’autres sites (6981)

• Discord.js voice stop playing audio after 10 consecutive files

  29 avril 2021, par Spiralio

  I am trying to do the simple task of playing a single MP3 file when a command is run. The file is stored locally, and I have FFmpeg installed on my computer. The code below is part of my command's file :

  


  const Discord = require("discord.js");
const fs = require('fs');
const { Client, RichEmbed } = require('discord.js');
const config = require("../config.json");

let playing = undefined;
let connection = undefined;

module.exports.run = async (client, message, args, config) => {


  if (playing) playing.end()
  if (connection == undefined) await message.member.voice.channel.join().then((c) => {
    connection = c;
  })
  playing = connection.play('./sounds/sound.mp3')

}


  


  (note that this code is heavily narrowed down to single out the issue)

  


  When I run the command the first 9 times, it works perfectly - the file is played, and cuts off if it is already playing. I also want to note that the file is 2 minutes long. However, once I play the file for exactly the 10th time, the bot stops playing audio entirely - as long as all 10 times are overlapping (meaning I don't let the audio finish).

  


  What's more confusing is that if an error is passed after the bot stops playing audio, it appears in an entirely different format than the standard Discord.js errors. For example, this code does not test to see if the user is in a voice channel, so if I purposefully crash the bot by initiating the command without being in a voice channel (after running the command 10 times), the error looks like this :

  


  abort(RangeError: offset is out of bounds). Build with -s ASSERTIONS=1 for more info.
(Use `electron --trace-uncaught ...` to show where the exception was thrown)


  


  (Preceded by a bunch of unformatted code) This however, is not consistent. It seems to only appear after letting the files run entirely.

  


  The issue only fixes itself when the entire bot restarts. Any help would be appreciated.

  


• How Can I Configure Storybook to Use React-App-Rewired ?

  8 août 2022, par joseph

  I'm working on a project that implements react-app-rewired to send headers to the server in order to bypass ReferenceError: SharedArrayBuffer is not defined (I'm getting this error from using the @ffmpeg/ffmpeg library).

  


  // config-overrides.js
const {
  override,
  // disableEsLint,
  // addBabelPlugins,
  // overrideDevServer
} = require('customize-cra')

module.exports = {
  devServer(configFunction) {
    // eslint-disable-next-line func-names
    return function (proxy, allowedHost) {
      const config = configFunction(proxy, allowedHost)

      // Set loose allow origin header to prevent CORS issues
      config.headers = {
        'Access-Control-Allow-Origin': '*',
        'Cross-Origin-Opener-Policy': 'same-origin',
        'Cross-Origin-Embedder-Policy': 'require-corp',
        'Cross-Origin-Resource-Policy': 'cross-origin'
      }

      return config
    }
  }
}


  


  // package.json
"scripts": {
  "start": "react-app-rewired start",
  "build": "react-app-rewired build",
  "test": "react-app-rewired test  --transformIgnorePatterns \"node_modules/(?!siriwave)/\"",
  "eject": "react-scripts eject",
  "storybook": "start-storybook -p 6006 -s public",
  "build-storybook": "build-storybook -s public"
}


  


  Though this works when I run npm start, meaning the headers get sent to the server, it doesn't work when I run npm run storybook, and I still get the SharedArrayBuffer is not defined error. I'm assuming it's because npm run storybook still uses react-scripts as opposed to react-app-rewired under the hood, but I'm not sure where I can change the configurations for this. Any ideas ?

  


• flvdec : Honor the "flv_metadata" option for the "datastream" metadata field

  9 février 2024, par Martin Storsjö

  flvdec : Honor the "flv_metadata" option for the "datastream" metadata field
  By default the option "flv_metadata" (internally using the field
  
  name "trust_metadata") is set to 0, meaning that we don't allocate
  
  streams based on information in the metadata, only based on
  
  actual streams we encounter. However the "datastream" metadata field
  
  still would allocate a subtitle stream.
  When muxing, the "datastream" field is added if either a data stream
  
  or subtitle stream is present - but the same metadata field is used
  
  to preemtively create a subtitle stream only. Thus, if the field
  
  was added due to a data stream, not a subtitle stream, the demuxer
  
  would create a stream which won't get any actual packets.
  If there was such an extra, empty subtitle stream, running
  
  avformat_find_stream_info still used to terminate within reasonable
  
  time before 3749eede66c3774799766b1f246afae8a6ffc9bb. After that
  
  commit, it no longer would terminate until it reaches the max
  
  analyze duration, which is 90 seconds for flv streams (see
  
  e6a084641aada7a2e4672172f2ee26642800a361,
  
  24fdf7334d2bb9aab0abdbc878b8ae51eb57c86b and
  
  f58e011a1f30332ba824c155078ca701e29aef63).
  Before that commit (which removed the deprecated AVStream.codec), the
  
  "st->codecpar->codec_id = AV_CODEC_ID_TEXT", set within the demuxer,
  
  would get propagated into st->codec->codec_id by numerous
  
  avcodec_parameters_to_context(st->codec, st->codecpar), then further
  
  into st->internal->avctx->codec_id by update_stream_avctx within
  
  read_frame_internal in libavformat/utils.c (demux.c these days).
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavformat/flvdec.c