problème – Page 6 – Les Mondes de Cyborg Jeff

FCPX (Final Cut Pro X) très lent, j’approche de la solution !

31 mai 2013 cyborgjeff Commentaires 15 commentaires - Post Views: 7 710

Depuis la fin de l’année 2012, et le passage à la version 10.0.5 de FCPX, je rencontre d’importants problèmes de lenteur d’export des mes montages vidéo. Je cherche régulièrement des réponses sur Internet et je pratique de nombreux tests. Si j’ai pensé tout un temps que le problème était uniquement lié à ma génération d’iMac sous OSX 10.6.8 (Core i7, 8go RAM, ATI 6770M 512mo). Après des tests plus approfondi sur mon Mac Book Pro de génération suivante (OSX 10.7.5, Core i7, 8go, ATI 6770M 1go), je me rends compte que mon soucis n’est pas uniquement lié à ma machine.

Pour résumer depuis le passage à la version 10.0.5 de FCPX, le temps de rendu des mes vidéos montée en HD prenait plus de 8 heures pour des montages de moins de 10 minutes… Parfois montant jusqu’à 72 heures lorsque j’appliquais mon plugin de correction d’image RedGiant Magic Bullet Looks. Au par avant les temps de rendu était beaucoup plus correcte, jamais plus de 2 heures. Les tests étaient claire, les processeurs du Core i7 étaient peu sollicité et les accès disques anormalement faible. Il semble effectivement que les nouvelles versions de FCPX privilégient plus le calcul du rendu sur le processeur GPU (carte graphique) que sur celui du CPU, mais malgré cela, j’ai eu beaucoup de difficulté à collationner les témoignages d’autres personnes rencontrant un problème similaire.

Hier pourtant, j’ai pu lire de nouvelles données qui ont pu sensiblement me faire avancer. Plutôt que de choisir l’option de sortie « Dispositifs Apple 720p », j’ai choisi l’option « Render Master ». Une option apparue entre temps dans ce menu qui exporte un fichier imposant (1go/minutes) mais qui se montre beaucoup plus rapide. Mon projet en cours de 15 minutes avec effets Looks en était à 40% au bout de 24h par la méthode utilisée jusqu’ici, il s’est exporté en 8 heures.

…

Lire la suite Lire la suite

Mon HTC One V, un an plus tard.

27 mai 2013 cyborgjeff Commentaires 2 commentaires - Post Views: 325

Je vous parlais il y a quelques jours de la relative déception de l’achat du Wiko Cink+ pour madame, un Androphone à bas prix basé sur un processeur Dual Core et je gardais en point de comparaison mon HTC One V dont je suis particulièrement content… dont J’ETAIS particulièrement content. En effet, si je reste vraiment très content de la prise en main de ce dernier et qualité de finition de celui-ci, il me faut bien constater que les mois passants, il peine de plus en plus. Et le plus frustrant c’est que les reproches que j’ai à lui faire semblent essentiellement lié à des applications internes à HTC.

La dernière mise à jour n’est pas très ancienne et date de fin mars 2013. L’androïd embarqué est une version 4.0.3. La batterie me donne toujours satisfaction et je n’ai pas vraiment de gros ralentissement dans les applications courantes que j’utilise ou dans l’espace de stockage me semble-t-il.

Les soucis que je rencontre après analyse semble donc lié à l’application People qui fait l’interface entre les réseaux sociaux, l’application SMS, l’application téléphone et l’application carnet d’adresse… Hors donc, trop régulièrement je dois attendre plusieurs minutes avant de pouvoir passer un coup de fil, lire ou envoyer un SMS, choisir une personne de contact dans l’annuaire. Un comble me dira encore mon frère ! Et clairement oui, c’est de plus en plus pénible, d’autant que je n’ai pas la possibilité de tuer l’application People, je dois régulièrement attendre qu’Androïd la considère comme bloquée. Visiblement les soucis liés à cela sont très fréquents sur ce modèle, ce qui n’est pas bon signe.

J’imagine qu’une accumulation de données sur chacun des contacts aux fils des mois fini par rendre l’application People très lente voir instable. Une ré-initialisation du téléphone pourrait alors régler le problème de manière tranchée…. ou pas !?

After around a month of use a huge lag problem developed with this phone.
Primarily effects around the « people » « dialer » and « message » apps.
Without warning usually on opening a message the phone will reset the screen, and then proceed to load the message for an extremely long time, normally never actually loading it.
Once this has happened, the dialer, message, and people apps become useless, and do not do anything.
When this happens other apps will work fine, but with the ability to call or text this phone is ridiculous. (Review HTC)

Autre hypothèse, une tentative de mise à jour des contenus people lors du premier accès. Je vais donc voir si désactiver le WiFi lors de période de plantage de l’application redonne de la vigueur au fonction primaire du téléphone…

Après plusieurs tests et contact avec le SAV de HTC, seul une ré-initialisation du téléphone a pu résoudre le problème. Il lui arrive à nouveau de faire quelques plantages, j’imagine donc que le problème reviendra à la charge au fil du temps…

FCPX 10.0.6 la mise à jour que j’aurais du éviter !

10 novembre 2012 cyborgjeff Commentaires 49 commentaires - Post Views: 518

Il y a des jours, où derrière mes ordinateurs, je rage et je fulmine ! Mais n’aurais-je donc jamais la paix, un ensemble qui fonctionne tip top ! Depuis le temps que je galère avec la suite Pinnacle Studio, je m’étais dirigé vers une solution Final Cut Pro X, impliquant l’utilisation d’un Mac. Cette dernière a bien des avantages, mais elle a aussi ces désagréments, qui depuis ce lundi se montrent bien énervant !

Oui, c’est que depuis la semaine dernière, je suis passé à la version 10.0.6 de Final Cut Pro X, apportant son lot de correctifs et améliorations. Dans les fait, je me retrouve avec un soft (Compressor compris) qui ralenti bien plus qu’avant et surtout, au grand surtout, des projets de 2 à 3 minutes à peine qui ont tout le mal du monde à s’exporter. Difficile de comparer, mais je n’ai jamais dû attendre 2 heures pour exporter un projet jusqu’ici et surtout l’un des arguments forts que j’avais à donner à FCPX était justement sa souplesse et fiabilité de travail !

De fait, cela me fait d’autant plus rager que cette nouvelle version 10.0.6 n’apporte toujours pas l’import de fichiers M2T, issus de ma caméra professionnelle Sony Z5 et son module pour carte mémoire CF. Cela m’oblige donc toujours à devoir passer par un logiciel de conversion au format HDV Pro qui crée d’énormes fichiers. Rageant, d’autant que ce format de fichier fonctionne plutôt bien sur Pinnacle !

A coté de cela, les fichiers M2TS de ma nouvelle Sony VG20 fonctionne sans soucis sous FCPX (jusqu’ici), alors qu’à la maison, je rencontre pas mal de problème quand je les transformes en fichier MPG HDV2.

Je vous l’accorde, c’est un peu technique, mais cela vous montre la complexité de mon quotidien et le besoin ou du moins l’espoir de trouver un environnement stable et fiable !

Au bout d’une semaine de test et chipoteries pour comprendre pourquoi mon outil de travail me fait des misères j’ai fini par trouver d’autres utilisateurs qui galère également avec cette nouvelle mise à jour de FCPX 10.0.6 au coté de nombreux autres qui s’annoncent ravi des performances améliorées de cette mise à jour ! De mon coté, bon nombre d’actions s’enchainent de l’icone de « sablier » propre à Apple et mes projets entamés dans la version 10.0.5 mettent un temps considérable à être exporté par le nouveau module de « partage », y compris via Compressor.

J’ai donc analysé comment fonctionnait mon iMac lorsque je lui demandais d’exporter un montage relativement simple (quelques plans superposés et des textes en surimpression) de 3 minutes. Durant près de 30 minutes, mon Core i7 consomme assez peu de ressources, pour passer de 9 à 11%. Le disque dur ne semble pas plus travailler. Au bout de ce temps (parfois montant jusqu’à pas loin de 1h), la machine s’active. Mes 8 processeurs se mettent alors en route, le disque dur affiche un graphique de fonctionnement linéaire et je peux alors passer en quelques minutes de 11 à 22%, voir 26%. Ensuite calme plat pendant 30 à 40 minutes avant de refaire le même scénario jusqu’à 33%.

La dernière étape allant de 33 à 44% est elle assez variable. un peu avant 50% le travail est terminé.

Tout d’abord, il faut bien admettre que les informations proposée par FCPX sur l’avancement du rendu sont peu claires, mais je me questionne essentiellement sur les temps tellement long de visible inactivité, rendant le rendu anormalement long. Cela se présentant donc essentiellement dans des projets initiés dans la version précédente 10.0.5 au départ de fichiers rushs au format HDV converti pour FCPX.

D’autres bugs sont répertoriés ici :
http://fcpx.tv/bugs.html

Et mes discussions dans le forum :
https://discussions.apple.com/message/20239059#20239059

Les habitués de l’environnement Mac me recommande évidemment « De ne jamais faire de mise à jour avec des projets en cours« , ou « de repartir de mon backup de la version 10.0.5« . Mais dans la mesure où je suis encore jeune utilisateur de cet OS, je n’ai ni les pratiques, ni l’équipement adapté pour cela. (Pas de TimeMachine sur cette station). Au mieux ai-je un FCPX 10.0.3 sur une clé USB, mais mes projets avaient été réalisé avec une version supérieure.

Bref, je galère ! Et je ne peux qu’attendre une mise à jour qui corrige les bugs que je rencontre !

Cyborg Jeff vs Robots

24 mai 2012 cyborgjeff Commentaires 13 commentaires - Post Views: 234

MAJ – illustration générée par ChatGPT, 2026

Ok, après de longues soirées, j’ai donc pu faire redescendre à la normal la charge CPU du serveur Infomaniak et rejoindre mes « copains » du serveur mutualisé. Le combat fut long, stressant et dans la mesure où une fois de plus, je me suis retrouvé seul au monde avec mon problème, je vais en profitez pour vous en faire partager les solutions, puisque déjà quelques autres internautes commencent à rencontrer de problèmes similaires.

Rappel des faits, début du mois, mon hébergement chez Infomaniak devait être isolé car quelques choses saturait le serveur web… et à moi d’en trouver la cause et l’éradiquer. Pas de malware, mise à jour de WordPress et plugins, rien n’y fait, je finis par constater un taux anormal d’appel dans les logs sur une seul et unique page du blog, plus de 10x par secondes et venant de serveurs BingBot officiels Microsoft. La raison reste toujours un mystère, mais mes lectures ont pu montrer d’autres cas similaires. Bug de l’outil, tentative de détournement pour saturer les serveurs…

Tout d’abord, j’ai donc installé un plugin de gestion de cache des pages à la demande d’Infomaniak. Celui-ci n’a pas vraiment fait diminuer la charge CPU, et m’enquiquine plus qu’autre chose d’ailleurs.

Après de nombreux tests, j’ai finalement interdit à BingBot et MSNBot de se rendre sur tout le site contenant la page à problème. Radicale, mais le contenu de celui-ci ne souffrira pas de ce nom référencement… Ceci dit cette solution est à mon goût trop agressive.

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} ^.*(msnbot).* [NC] # Si le user agent contient la chaine msnbot
RewriteRule ^.* – [F,L] # On interdit alors l’accès à la page

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} ^.*(bingbot).* [NC] # Si le user agent contient la chaine msnbot
RewriteRule ^.* – [F,L] # On interdit alors l’accès à la page

La solution s’avère efficace, puisque la charge serveur diminue alors de suite, néanmoins les logs restent surchargés, j’adapte donc avec un fichier ROBOTS.TXT qui placé à la racine du site impose aux différents bots ce qu’il peuvent indexer ou non… 24h plus tard, les résultats sont efficaces, mon fichiers LOG de 40mo est passé à 1,5mo !

User-agent: *
Disallow: /wp-*
Disallow: /*.php$
Disallow: /*.js$
Disallow: /*.inc$
Disallow: /*.css$
Disallow: /*%26layout=
Disallow: /*xoops_url

J’impose donc de ne pas indexer tous répertoires ou fichiers commençant par wp- à savoir des fichiers critiques à WordPress, les fichiers .php, .js ou .css et propre à ce cas les urls contenant la chaine de caractère %26layout= ou xoops_url.

Bon, j’espère être tranquille jusqu’à l’année prochaine mantenant !

Allé, pour vous donner un peu de coeur à l’ouvrage… tout cela me rappelle ce morceau de musique écrit en 2002 : Cyborg Jeff – We are the Bots !

…

Lire la suite Lire la suite

Saturation serveur

19 mai 2012 cyborgjeff Commentaires 8 commentaires - Post Views: 326

Déjà quelques jours que je m’arrache les cheveux et perd un temps précieux sur un sérieux problème d’attaque Web sur mon serveur, un soucis qui semble s’orienter autour d’attaque de BingBot ou d’un bon bug dans celui-ci, le tout causant une charge CPU anormal sur le serveur.

Et c’est de la que le problème a été identifié. Contacté par Infomaniak il y a un moment, mon hébergement avait dû être démutualisé pour cause de surcharge CPU, or ce n’est pas vraiment le genre d’Infomaniak de faire la grimace ! Difficile de mettre la doigt exactement sur ce qui en est la cause, il a donc fallu tenter plusieurs pistes.

J’ai d’abord fait un genre de test malware de mes différents sites avec cet outil : http://sucuri.net/ sans grand résultat, il m’annonçait simplement que mes versions de WordPress n’était pas à jour. Dans la mesure où le passage à Worpdress 3.x impliquait toute une série d’incompatibilité plugins, je m’étais volontairement arrêté à la version 2.9.8.2 J’ai donc mis à jour mes noyaux, mis à jour les nombreux plugins et puis ?

Je me suis souvenu avoir lu qu’il était parfois utile de checker authenticité des thèmes wordpress utilisés. En effet, par exemble, celui de mon blog avait été réalisé au départ d’un thème datant maintenant de 2007…. Cause potentiel ? Pas vraiment sur, mais bon, cela n’aura pas fait de tord de mettre tout cela à jour

J’en ai profité pour faire du nettoyage sur mon serveur, par bloquer via .htaccess certains répertoires,… puis sous les conseilles d’Infomaniak, j’ai installé un outil d’optimisation de cache du site WP Super Cache, qui permet de diminuer les requêtes aux serveurs.

Mais rien à faire, la charge CPU restait toujours assez élevée… Dans les statistiques, je voyais qu’une page d’un de mes blogs était anormalement visitée, plus de 600.000 fois depuis début mai sans aucune raison. La page était plutôt clean, on aurait juste pu lui reprocher un embed de player Jamendo… Un croisement avec les weblog du site me montre effectivement que le problème passe bien par là, on retrouve ce genre de log plusieurs fois par seconde en permanence :

157.55.17.151 - - [16/May/2012:00:00:10 +0200] "GET /cyborgjeff/site/albums/divagation-se-1997/%26layout=button_count%26show_faces=false%26width=250%26action=like%26colorscheme=light%26font=arial%26height=35px/1997/02/24/344-4u2-ethnic-drums-ftl-mix-16/1997/04/10/372-ego/1997/03/23/365-2-3-frutti-dance-classics/1997/02/24/344-4u2-ethnic-drums-ftl-mix-16/1997/04/10/370-introduction-of-dream-part-ii/1996/11/27/279-moon-day/1996/11/27/279-moon-day/1997/04/04/368-deep-house-titanic-mix/1997/04/10/372-ego/1997/04/10/372-ego/1997/04/05/369-i-get-no-sleep-part-2/1997/03/03/351-one-month-but-three-weeks-without-you-mixing/1997/03/16/361-hey-mister-dj/1997/02/12/335-space-del/1997/02/12/335-space-del/ HTTP/1.1" 301 - "-" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"

Plusieurs choses m’intrigue là dedans, d’abord tout le blabla après la page proprement dit et ensuite des appels vers les urls des pages liées à la première, un peu comme si l’appel en question allait ouvrir une dizaine de pages d’un coup, ce qui pourrait évidemment expliquer la surcharge, ensuite à quoi peut bien faire référence ceci : %26layout=button_count%26show_faces=false%26width=250%26action=like%26colorscheme=light%26font=arial%26height=35px

J’ai tout d’abord supprimer ma page temporairement, les appels ont continuer sans soulager le serveur, et pour cause, c’est wordpress qui génère les messages d’erreur type 404 et compagnie, par contre fin de journée, le BingBot a fini par se lassé et la charge CPU est retombée… J’ai réactivé la page, et dès le lendemain, bardouf !

Petit check, les différentes IPs semblent bien provenir de Microsoft (MSNBot et BingBot), j’avais fini par trouver quelques Abus BingBot récent mais qui semble surtout provenir d’adresse IP douteuses, et cibler essentiellement les pages de logins ou de commentaires, ce qui n’est pas le cas ici… J’ai par contre aussi trouvé certaines personnes rapportant des comportements agressif et anormaux des BingBots officiels ces dernières semaines…

Que faire ? Pour l’heure j’ai bloqué l’accès à Bingbot et Msnbot via du code .htaccess

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} ^.*(msnbot).* [NC] # Si le user agent contient la chaine msnbot
RewriteRule ^.* - [F,L] # On interdit alors l'accès à la page

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} ^.*(bingbot).* [NC] # Si le user agent contient la chaine msnbot
RewriteRule ^.* - [F,L] # On interdit alors l'accès à la page

Cela soulage le serveur, mais je trouve la parade un peu trop large… j’aimerais bien pouvoir affiner cela, voir comprendre la raison du problème sur ma page bien précise… histoire de pouvoir me prémunir d’autres pertes de temps de ce genre !

>> Ici la solution finale mise en place : https://lesmondesdecyborgjeff.be/2012/05/24/cyborg-jeff-vs-robots/

…

Lire la suite Lire la suite