Recherche avancée

Sur d’autres sites (4597)

• Anomalie #3398 (Nouveau) : Date du thread modifiée lorsqu’un message de forum est soumis, sans ten...

  6 mars 2015, par Pascal Verrier

  Bonjour,

  Configuration : un SPIP neuf 3.0.17 avec le plugin Comments 3.3.2 permettant l’affichage en thread (et donc de répondre à un message, ce qui n’est pas possible avec le core seul).
  Concerné : plugin-dist forum.

  Je constate sur SPIP 3.0.17 ce fonctionnement curieux :
  - j’ai configuré dans un premier temps le forum d’un article en modération à postériori
  - j’ai posté un premier message puis y ai fait une réponse : je constate bien le changement de la date du thread qui se recale sur la date du dernier posté (et donc publié)
  - j’ai modifié la configuration pour passer en modération à priori
  - j’ai ajouté dans le même thread un troisième message (qui donc cette fois n’est pas publié, car modéré)
  - dans la base de données je constate que la date_thread s’est de nouveau calée sur le dernier message, alors qu’il n’est pas publié (statut "prop")

  Cela ne me semble pas normal ; sur mon site de production (http://www.harmoweb.cnrs.fr/spip.php?rubrique28) intégrant l’affichage de la liste des threads, du plus récent au plus ancien (en se basant sur date_thread) cela a pour effet de "faire remonter" des messages anciens sur lesquels des messages viennent d’être posté même s’ils ne sont pas publiés (dans notre cas des spams interceptés par nospam, nous n’avons pas de modération à priori, mais le mécanisme posant problème est le même).

  Dans mes recherches je suis également tombé sur cette correction d’anomalie https://core.spip.net/issues/852 où le problème de base était similaire mais si j’ai bien compris ne concernait que les mises à jour de statut de messages publiés à priori ; l’évolution de date_thread est normale dans ce cas, contrairement à la situation où le message n’est pas publié d’office, la date de thread ne tenant donc pas compte du statut du message fraîchement posté : lors de l’enregistrement d’un nouveau message, date_thread ne devrait être changé sur tous les messages du fil que si ce message est publié, et non dans les autres cas.

• Why is "ffmpeg : command not found" in heroku, even with proper buildpack/config ?

  14 novembre 2022, par Jim

  In a node.js app hosted on heroku, ffmpeg is used by spawning processes, but is throwing errors anytime an ffmpeg command runs

  


  the error ffmpeg: command not found is thrown both in cli test heroku run ffmpeg as well as production logs

  


  Ive considered :

  


  

  • buildpack order

  


  • buildpack clearing/re-adding/redeploying

  


  • buildpack required env vars

  


  • heroku-stack-20 conflicts with buildpack#1 somehow ?

  


  


  Buildpack order :

  


  

  1. https://github.com/jonathanong/heroku-buildpack-ffmpeg-latest.git

  


  2. https://github.com/heroku/heroku-buildpack-awscli.git

  


  3. https://github.com/timanovsky/subdir-heroku-buildpack.git

  


  4. heroku/nodejs

  


  


  Buildpack configs - from watching build logs, even though i havent set ffmpeg path, a default is found.

  


  beginning build logs (completes successfully, runs successfully - minus ffmpeg) :

  


  -----> Building on the Heroku-20 stack
-----> Using buildpacks:
       1. https://github.com/jonathanong/heroku-buildpack-ffmpeg-latest.git
       2. https://github.com/xrisk/heroku-opus.git
       3. https://github.com/heroku/heroku-buildpack-awscli.git
       4. https://github.com/timanovsky/subdir-heroku-buildpack.git
       5. heroku/nodejs
-----> ffmpeg app detected
-----> Installing ffmpeg
       Variable FFMPEG_DOWNLOAD_URL isn't set, using default value
       Downloading https://johnvansickle.com/ffmpeg/builds/ffmpeg-git-amd64-static.tar.xz
       Unpacking the archive
       Installation successful
-----> heroku-opus app detected
       exporting PATH and LIBRARY_PATH
-----> Building in /tmp/build_51b5ac83/opus
-----> Starting opus compilation
       Downloading opus-1.3.1.tar.gz
       Unpacking opus
       Running configure
       Running make install
-----> AWS CLI app detected
-----> Downloading AWS CLI
-----> Installing AWS CLI
       You can now run: /app/.awscli/bin/aws --version
       aws-cli/2.8.12 Python/3.9.11 Linux/4.4.0-1104-aws exe/x86_64.ubuntu.20 prompt/off
-----> Successfully installed AWS CLI
-----> Subdir buildpack app detected
-----> Subdir buildpack in server
       creating cache: /tmp/codon/tmp/cache
       created tmp dir: /tmp/codon/tmp/cache/subdirBuBFb
       moving working dir: server to /tmp/codon/tmp/cache/subdirBuBFb
       cleaning build dir /tmp/build_51b5ac83
       copying preserved work dir from cache /tmp/codon/tmp/cache/subdirBuBFb to build dir /tmp/build_51b5ac83
       cleaning tmp dir /tmp/codon/tmp/cache/subdirBuBFb
-----> Node.js app detected


  


  Any suggestions to further debug this ?

  


• NodeJS fluent-ffmpeg error : Output stream closed

  30 décembre 2020, par Japser36

  We are running a NodeJS server that does some audio processing. Specifically, we have audio data returned by google's text to speech API, which we have in the form of a Buffer.

  


  In our application, we have to send this audio data through FFMPEG to format it and extract audio duration. We do this by first converting it into a stream, piping it into ffmpeg, and then storing the data in an output buffer :

  


  const toWav = function (input: Buffer): Promise<buffer> {&#xA;    return new Promise((res, rej): void => {&#xA;        const bufs = [];&#xA;        const myReadable = new Readable();&#xA;        myReadable._read = (): void => {}; // we already have all data in memory, so no-op this function;&#xA;        myReadable.push(input); // stream all data in the buffer to the stream&#xA;        myReadable.push(null); // end the stream&#xA;        const output = ffmpeg(myReadable)&#xA;            .inputFormat(&#x27;mp3&#x27;)&#xA;            .toFormat(&#x27;wav&#x27;)&#xA;            .on(&#x27;start&#x27;, function (commandLine) {&#xA;                console.log(&#x27;SPAWNED ARG: &#x27; &#x2B; commandLine);&#xA;            })&#xA;            .on(&#x27;error&#x27;, (err: object): void => {&#xA;                console.error(&#x27;FFMPEG error on wav transform&#x27;);&#xA;                rej(err);&#xA;            })&#xA;            .on(&#x27;end&#x27;, (): void => {&#xA;                console.debug(&#x27;FFMPEG finished wav transform&#x27;);&#xA;                res(Buffer.concat(bufs));&#xA;            })&#xA;            .pipe();&#xA;        output.on(&#x27;data&#x27;, (d: object): void => {&#xA;            bufs.push(d);&#xA;        });&#xA;    });&#xA;};&#xA;</buffer>

  


  This code is one of our functions that does the formatting, that our data gets passed through. Most of the time, this code works fine, but sometimes an error is thrown :

  


  Looking up this error on google, I found an issue on the FFMPEG library we use, that seems to suggest that using an input and output stream just isn't recommended and doesn't work. Rather, one of the two needs to be a file resource.

  


  Some more about this error, it seems to happen consistently when it does happen, but it doesn't happen consistently overall. For me, I got this error every time the code ran, I went and took lunch, and when I came back it was gone.

  


  For us it is important that this error won't pop up randomly in production, so the question is, does anyone have any suggestions on how we can be the most certain this error won't happen ?

  


  For completeness in how this function is being invoked to result in the error in the screenshot, the structure of the code where the error is caught is like so :

  


  await Promise.all(
    myArray.map(async (item, idx) => {
        // ...
        const wavBuffer = await toWav(myBuffer); // toWav is invoked at this level
    })
)
.then(() => {/* ... */})
.catch((e) => {
    // ...
    logger.error('[LOOP CRASH] Error at main promise:', e);
    // ...
});


  


  Any help would be appreciated, thank you ! Please let me know if I can provide more details, though I cannot share a repo or full source code or anything since this is a private repo.