Recherche avancée

Sur d’autres sites (10852)

• Cannot run ffmpeg in subproces.call

  27 juin 2012, par Richard Knop

  So, I have a simple class where I am trying to save a string response from a terminal ffmpeg command into an object property :

  import os
  
  import subprocess
  
  
  
  class Movie(object):
  
  
  
      absolute_path = None
  
      movie_info = None
  
  
  
      def __init__(self, path):
  
          self.absolute_path = "%s/%s" % (os.getcwd(), path)
  
          if(os.path.exists(self.absolute_path) is False):
  
              raise IOError("File does not exist")
  
  
  
      def get_movie_info(self):
  
          ffmpeg_command = "ffmpeg -i %s" % self.absolute_path
  
          self.movie_info = subprocess.call(ffmpeg_command)
  
          print self.movie_info

  When I then run this command in cmd :

  import os
  
  import sys
  
  sys.path.append(os.getcwd())
  
  
  
  from Encode.Movie import Movie
  
  
  
  try:
  
      movie = Movie("tests/test_1.mpg")
  
      movie.get_movie_info()
  
  except IOError as e:
  
      print e

  I get this exception :

  richard@richard-desktop:~/projects/hello-python$ python main.py 
  
  Traceback (most recent call last):
  
    File "main.py", line 9, in <module>
  
      movie.get_movie_info()
  
    File "/home/richard/projects/hello-python/Encode/Movie.py", line 16, in get_movie_info
  
      self.movie_info = subprocess.call(ffmpeg_command)
  
    File "/usr/lib/python2.7/subprocess.py", line 493, in call
  
      return Popen(*popenargs, **kwargs).wait()
  
    File "/usr/lib/python2.7/subprocess.py", line 679, in __init__
  
      errread, errwrite)
  
    File "/usr/lib/python2.7/subprocess.py", line 1249, in _execute_child
  
      raise child_exception
  
  OSError: [Errno 2] No such file or directory
  
  </module>

  The path is correct because when I do print self.absolute_path before subprocess.call(), I get :

  /home/richard/projects/hello-python/tests/test_1.mpg

  And this file exists.

• Anomalie #3504 : anomalie dans cvt_autosave : les purges ne se font pas

  23 juillet 2015, par Peet du

  Tu as raison...une fois que tu valides ton formulaire (avec _autosave activé), les données de session concernant CE formulaire sont bien purgées. Pas de bug en l’état puisque ce traitement n’est pas basé sur la constante _AUTOSAVE_GB_DELAY

  Ce que j’avais oublié de préciser dans mon post, c’est que le bug signalé se situe dans la deuxième partie du traitement, celle qui "purge aussi toutes les vieilles autosave". C’est elle qui est basée sur _AUTOSAVE_GB_DELAY.
  Voir https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/cvt_autosave.php#L88

  Si j’ai bien compris, elle traite le cas où le site contient plusieurs formulaires CVT avec l’autosave activé. Dans ce cas on purge également ces sessions.
  Et c’est là que le bug sur le timestamp fait son office. Ces vieilles sessions ne seront jamais purgés.

  SUGGESTION
  Perso, je trouve que ce fonctionnement est astucieux, mais il induit un fonctionnement confus pour l’utilisateur et pour le développeur.
  Si le visiteur revient sur son formulaire, (même 1 an après) il trouve les champs remplis puisque _AUTOSAVE_GB_DELAY n’est pas pris en compte dans ce cas . Il valide son formulaire et sa session pour ce formulaire est purgé.
  Puis dans la foulée il arrive sur un autre formulaire et là....rien ?! (ben oui, il a validé le premier et la purge basée sur _AUTOSAVE_GB_DELAY a fonctionnée (si on corrige le bug hein ;-)

  Bref, perso j’ai modifié le core (je sais, c’est mal) en mettant les purges uniquement basée sur _AUTOSAVE_GB_DELAY dans la fonction cvtautosave_formulaire_charger. On (peut) garder la purge à la validation du formulaire.

  SUGGESTION 2
  L’idéal serait, selon moi, de garder cette dernière idée avec un ajout : on purge dans le répertoire /sessions toutes les données de tous les utilisateurs pour lesquels la valeurs _AUTOSAVE_GB_DELAY a été dépassé. Ça marche bien et de plus, d’un point de vue de sécurité, cela règle en partie le problème des personnes qui on mal lu la doc sur la partie "Vie privée" (voir http://www.spip.net/fr_article5428.html).

  SUGGESTION 3
  même si vous n’êtes pas d’accord avec mon analyse, serait-il possible de mettre

  • cvtautosave_formulaire_charger
  • cvtautosave_formulaire_traiter

  en _dist ?

• Anomalie #3462 (Nouveau) : Gestion des documents utilisés dans les rubriques - suppression impossi...

  5 juin 2015, par Pascal Verrier

  Bonjour,

  Je constate une modification liée à l’utilisation de documents/images au sein du texte explicatif d’une rubrique.
  Dans SPIP 2.1.27 l’édition de rubrique permet l’ajout de documents (bloc Ajouter une image à gauche), cette fonctionnalité a apparemment été supprimée dans la 3.0.19.

  Cela n’interdit pas de saisir des codes type (correspondant à des éléments de la médiathèque chargés auparavant) dans le texte de description de la rubrique, ce qui permet d’utiliser ces contenus dans la présentation d’une rubrique : ils sont bien affichés, mais contrairement à ce qui se passait sur les versions précédentes, on n’a pas en bas de page rubrique du backoffice (exec=naviguer&id_rubrique=N) le rappel des documents liés, or en regardant dans la médiathèque on peut constater que le lien a bien été réalisé (lors de l’enregistrement) entre les documents utilisés et la rubrique.

  Cela se complique lorsque l’on décide de supprimer une rubrique utilisant, ou ayant utilisé des documents.

  Si je reprends ma rubrique, j’en supprime ou déplace tous les articles, j’en supprime le contenu texte, je n’obtiens jamais le bouton "Supprimer cette rubrique". En fait les documents utilisés y sont liés et tant que ces liens existent la suppression est impossible. C’est le même comportement que sur les versions précédentes* à cela près que l’absence de la liste des documents liés (normalement affichés en bas de page, ou à gauche en édition) n’aide pas vraiment à comprendre pourquoi cette rubrique ne peut être supprimée. Seul indice, sous l’identifiant de rubrique est indiqué "N documents". Autre curiosité la rubrique est d’office considérée comme active, et elle apparaît sur l’espace public, même si elle ne contient aucun article. C’est ainsi que l’on se retrouve avec une rubrique vide, impossible à supprimer, et affichée dans les menus de l’espace public.

  En supprimant manuellement les liens document/rubrique depuis la médiathèque le lien "Supprimer cette rubrique" réapparaît.

  (* : je ne suis pas certain par ailleurs que le fait de ne pas pouvoir supprimer une rubrique à laquelle des documents sont liés soit réellement justifié)

  Ce choix de supprimer l’ajout de documents dans l’édition de rubriques est-il intentionnel ? Pourrait-on retrouver le mécanisme existant dans les articles et dans SPIP 2.1 ?
  Serait-il envisageable de pouvoir supprimer directement une rubrique vide sans avoir à se préoccuper de l’existence de ces liens avec les documents ?
  Merci.