Sur d’autres sites (4097)

• Anomalie #3675 (Nouveau) : fsockopen => lenteur dans inc/queue

  6 février 2016, par Gilles VINCENT

  Sur certains hébergeurs, l’utilisation de fsockopen() à la place de curl() ralentit beaucoup les pages.
  Certains utilisateurs désactivent le bloc dans queue_affichage_cron()
  cf. http://forum.spip.net/fr_244583.html#forum263615
  Mais avant ça, il maudissent le jour où ils sont passé de la version 2.1 à la version 3.x :/

  Est-ce qu’il n’y a pas de meilleure stratégie que celle actuelle ?
  Par exemple, ne pourrait-on pas avoir une variable statique (ou dans un fichier lu par SPIP) qui soit modifié quand on détecte qu’une méthode tombe en timeout ?
  Quel était l’inconvénient de la méthode de l’image de qqs pixels ?

  Wordpress n’utilise pas de socket pour son API Http, mais curl et stream.
  https://core.trac.wordpress.org/browser/tags/4.4.2/src/wp-includes/class-http.php#L308

  Il faudrait regarder d’autres frameworks..

• FFMPEG libavformat internal buffering

  4 octobre 2013, par Theodor

  I'm using FFMPEG for a C++ audio streaming and playback application.

  I use the avformat_open_input function to open an URL to an external compressed audio file and then I step through to stream using av_read_frame. Then for each packet i directly decode the data and queue it in the audio buffer using OpenAL.

  My question is if FFMPEG internally prebuffers compressed data from the external URL ?

  Does FFMPEG keep downloading data in the background even if I don't call av_read_frame ?

  Or is it my responsibility to maintain a intermediate buffer where I download as many packets as possible ahead of time to avoid starving the audio-playback ?

  If so, how much does it buffer/download internally ? Can I configure this ?

  I have been looking through the documentation but have not found any information on this.

  Thanks.

  Update :
  According to this thread http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=15&t=376 libav should by default prebuffer about 5MB depending on AVFormatContext::max_analyze_duration. However I haven't noticed this behavior and it doesn't seem to change if I alter max_analyze_duration.

  If I monitor the memory consumption of my process it doesn't increase after I call avformat_open_input and if I simulate slow-network, av_read_frame directly stops working like if it didn't have any packets buffered.

• Anomalie #4033 (Nouveau) : Critère `{age #TRUC}` erroné en SQLite

  28 octobre 2017

  Découvert suite à https://forum.spip.net/fr_267686.html

  - Le critère {age<3} fonctionne bien en SQLite.
  - Le critère {age<#TRUC}, avec #TRUC valant 3 provoque une erreur de test en SQLite, qui renvoie toujours VRAI.

  La différence est minime entre les deux :
  - TIMESTAMPDIFF('HOUR',articles.date,NOW())/24 < 3
  - TIMESTAMPDIFF('HOUR',articles.date,NOW())/24 < '3' pour le second

  Mysql quand à lui a parfaitement l’air de s’en accomoder. Notons qu’il y a une petite différence en Mysql sur la sortie : TIMESTAMPDIFF(HOUR ... où HOUR est une variable interne
  alors que sous SQLite c’est un paramètre de la fonction TIMESTAMPDIFF que sqlite_fonctions.php déclare. Mais ça ne change rien au problème rencontré ici.

  Pour tester, sous SQLite on obtient 2 résultats différents.
  

  #CACHE0
  #SQUELETTE
      #ID_ARTICLE : #COMPTEUR_BOUCLE / #GRAND_TOTAL
  
  #SETage,100
      #ID_ARTICLE : #COMPTEUR_BOUCLE / #GRAND_TOTAL