Recherche avancée

Médias (0)

Mot : - Tags -/auteurs

Aucun média correspondant à vos critères n’est disponible sur le site.

Autres articles (37)

  • Création définitive du canal

    12 mars 2010, par

    Lorsque votre demande est validée, vous pouvez alors procéder à la création proprement dite du canal. Chaque canal est un site à part entière placé sous votre responsabilité. Les administrateurs de la plateforme n’y ont aucun accès.
    A la validation, vous recevez un email vous invitant donc à créer votre canal.
    Pour ce faire il vous suffit de vous rendre à son adresse, dans notre exemple "http://votre_sous_domaine.mediaspip.net".
    A ce moment là un mot de passe vous est demandé, il vous suffit d’y (...)

  • Les tâches Cron régulières de la ferme

    1er décembre 2010, par

    La gestion de la ferme passe par l’exécution à intervalle régulier de plusieurs tâches répétitives dites Cron.
    Le super Cron (gestion_mutu_super_cron)
    Cette tâche, planifiée chaque minute, a pour simple effet d’appeler le Cron de l’ensemble des instances de la mutualisation régulièrement. Couplée avec un Cron système sur le site central de la mutualisation, cela permet de simplement générer des visites régulières sur les différents sites et éviter que les tâches des sites peu visités soient trop (...)

  • Taille des images et des logos définissables

    9 février 2011, par

    Dans beaucoup d’endroits du site, logos et images sont redimensionnées pour correspondre aux emplacements définis par les thèmes. L’ensemble des ces tailles pouvant changer d’un thème à un autre peuvent être définies directement dans le thème et éviter ainsi à l’utilisateur de devoir les configurer manuellement après avoir changé l’apparence de son site.
    Ces tailles d’images sont également disponibles dans la configuration spécifique de MediaSPIP Core. La taille maximale du logo du site en pixels, on permet (...)

Sur d’autres sites (4789)

  • Anomalie #3991 : Erreur compression CSS et base64

    29 août 2017, par tcharlss (*´_ゝ`)

    La ligne fautive se trouve ici : https://zone.spip.org/trac/spip-zone/browser/_core_/plugins/compresseur/inc/compresseur_minifier.php#L100

    // zero est zero, quelle que soit l’unite (sauf pour % car casse les @keyframes cf https://core.spip.net/issues/3128)
    $contenu = preg_replace("/([^0-9.]0)(em|px|pt)/ms", "$1", $contenu) ;
    

    Ça cherche le nombre zéro précédé de n’importe quel caractère (autre qu’un chiffre) ou d’un point.
    Du coup ça peut matcher avec les data URIs :

    @font-facefont-family :’spip’ ;src:url("data:application/font-woff ;base64,abc0pxyz") ;
    

    Pour éviter ce souci, on pourrait préciser exactement quels caractères peuvent précéder le zéro pour considérer qu’il s’agit d’une unité. On peut avoir :

    1) deux points

    font-size:0px ;
    

    2) un ou plusieurs espaces

    font-size : 0px ;
    font-size : calc(10px + 0px) ;
    

    3) une parenthèse dans le cas de calc()

    font-size : calc(0px) ;
    

    4) Autres unités

    À noter qu’il y a aussi pas mal d’autres unités qui ne sont pas prises en compte dans la regex actuelle : https://www.w3schools.com/cssref/css_units.asp

    rem ex pc
    vh vw vmin vmax 
    cm mm in
    ch 
    

    Ce qui donne au final la regex suivante, qui laisse mes data URIs tranquilles :

    $contenu = preg_replace("/((?: :|\s+|\()0)(em|px|pt|rem|ex|pc|vh|vw|vmin|vmax|cm|mm|in|ch)/ms", "$1", $contenu) ;
    
  • Evolution #3996 (Nouveau) : Y a t-il une limite de taille de cache dans SPIP ?

    9 septembre 2017, par Julien -

    Ticket qui fait suite à des observations sur #3843.

    cedric :

    1/ il n’y a plus de quota cache en SPIP 3.1+ (aucune taille limite, c’est un nombre de slots qui fixe la limite)
    2/ les images stockées dans local/ n’ont jamais été comptées dans la taille du cache et n’ont aucune influence

    marcimat :

    Notons que le génie ’invalideur’ est toujours appelé et utilise ’quota_cache’ ; le formulaire de vidage de cache affiche aussi le quota.
    Probablement du code mort dans les 2 cas.

    Ref dans le code :
    https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc_version.php#L286
    https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/genie.php#L141
    https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/invalideur.php#L226

    dans la doc :
    https://programmer.spip.net/Configurer-le-cache

  • I am calling ffmpeg from Python. Getting thread.error and repeated attempts to connect to audio stream

    16 février 2016, par user2192778

    I have some code which calls ffmpeg at a particular time of the day to record a web stream. First, the function that calls ffmpeg...

    def record_stream():
       ffmpegEXE = "C:/pathtoffmpeg/ffmpeg.exe"
       subprocess.call([ffmpegEXE, '-i', http://streamurl.mp3, output.mp3], shell=True)

    Then, the function which schedules record_stream according to the clock...

    def sched ():
       i = 0
       while True:

       x = datetime.today()
       y=x.replace(day=x.day+1, hour=i, minute= start_minute, second=0, microsecond=0)
       delta_t=y-x
       secs=delta_t.seconds+1
       t = Timer(secs,stream_record)
       t.start()
       i = (i + 1) % 24

    When I launch the .py program an error reads :

    Traceback <most recent="recent" call="call" last="last">
    ... line X, in <module>
    sched ()
    ... line Y, in sched ()
    t.start()
    ... line Z, in start
    _start_new_thread(self.__bootstrap,())
    thread.error: can't start new thread
    </module></most>

    Despite the error, the program runs.

    When it runs, however, ffmpeg initializes over and over again. It connects to the stream, then connects to the stream again (this time saying "output.mp3 already exists. Overwrite ? Y/N" It will do this ten or so times until it finally just records the stream in a normal way.

    How do I fix these errors ? How do I stop this issue with ffmpeg connecting repeatedly ?