fichier enregistrer 0Ko

[santec]

salut

bon j'ai lancer une taches , le fichier et bien là 5Go , donc le problème venais bien du dernier pilotes Pinnacle (3.15) je vois pas d'autres explication

je vais quand même installer le dernier EXP pour voir......

[santec]

salut

ptvm v 0.6.1. 263 (dep activé par defaut)

j'ai encore un enregistrement programmé raté fichier 0Ko (version 32 bits), par contre entre deux enregistrement j'ai installer le pilote "nvidia storage" DD/DVD en ahci , une piste peux être , de plus j'ai fait un essais de programmation en 64 bits plantage direct du logiciel.........

[r0lZ]

J'ai eu le même problème, mais une seule fois (jusqu'ici).

Enregistrement programmé en TS, assez long (je ne me rappelle plus exactement sa durée, mais ça devait faire dans les 2h45) avec options planificateur des tâches et éteindre la lumière. Comme je suis revenu avant la fin de l'enregistrement, j'ai pu constater que l'ordi était bien sorti de son mode veille, et que l'icône de PTVM était rouge. Je n'ai pas fait attention au fichier, et je n'ai jamais ouvert PTVM, que j'ai laissé en paix dans le tray. A la fin de l'enregistrement, la machine s'est éteinte (alors que je travaillais toujours!), puis quand j'ai voulu voir le contenu du fichier, mauvaise surprise: 0 bytes. Aucun autre signe de quoi que ce soit de problématique. Bizarre donc. (A propos, où se trouve le log? Je ne l'ai pas trouvé.)

J'ai immédiatement refait quelques autres essais, avec des enregistrements programmés de quelques minutes, mais je n'ai pas pu reproduire le problème.

Ma seule piste: foobar2000 tournait quand PTVM a éteint la machine. Je ne vois pas pourquoi un player audio ferait planter l'enregistrement, mais il se peut que la machine était trop chargée lors du shutdown. Cela dit, un shutdown avec un fichier mal fermé mais très gros ne devrait pas le laisser complètement vide.

PTVM v0.6.1.263 X64 sous Win7 SP1, codecs vidéo de M$ et AC3Filter pour le son.

[EDIT] Je viens de constater qu'il faut utiliser la version spéciale de diagnostique pour avoir le log.

[Gingko]

Bonjour,

Encore une fois, il n'est pas exceptionnel d'avoir des situations où un tuner se bloque ou bien ne démarre pas correctement, produisant une situation analogue à une absence de réception et un fichier enregistré de taille nulle.

Donc à moins d'avoir des informations plus complètes à étudier, je ne peux pour le moment que présumer le cas de figure d'un tuner un peu instable et que des échecs d'enregistrement occasionnels soient dus à cette raison.

À noter, au passage, que suite aux récents passage au tout numérique de certaines régions, il n'est pas exclu aussi qu'un enregistrement programmé avant la transition ne s'exécute pas correctement après que la nouvelle recherche de chaînes ait été effectuée (ou même devienne invisible dans la liste des enregistrements bien que toujours présent, et donc susceptible de faire conflit, bug que j'ai constaté récemment à Paris). Je vous conseille supprimer le fichier « programmes.xml » dans %AppData% et de reprogrammer vos enregistrements, dans ce cas, pour éviter tout problème.

Gingko

[r0lZ]

Hum, je doute que ce soit à cause du tuner, car il a toujours très bien fonctionné. Et je n'ai pas du reprogrammer les chaînes, donc ce n'est pas ça non plus. Je suspecte plutôt un problème du au mode sleep, ou au shutdown trop rapide. Je ferai encore quelques tests...

[Gingko]

Hum, je doute que ce soit à cause du tuner, car il a toujours très bien fonctionné. Et je n'ai pas du reprogrammer les chaînes, donc ce n'est pas ça non plus. Je suspecte plutôt un problème du au mode sleep, ou au shutdown trop rapide. Je ferai encore quelques tests...

Certains tuners peuvent effectivement mal réagir à la mise en veille.

En revanche, l'arrêt de l'ordinateur se fait régulièrement à l'aide d'une fonction dédiée de Windows (donc de façon identique à un arrêt demandé manuellement depuis le « Menu Démarrer »), et l'application est même quittée avant que celui-ci soit effectué, il est donc fort douteux qu'un « Shutdown trop rapide » soit une notion qui ait même un sens.

Gingko

[r0lZ]

il est donc fort douteux qu'un « Shutdown trop rapide » soit une notion qui ait même un sens.

Je sais. Je suis assez confus d'avoir suggéré ça, mais à défaut d'une meilleure piste, je ne voyais que ça!

Mais maintenant que j'y pense, il se peut que PTVM était déjà en train de tourner dans le tray lorsque j'ai mis la machine en mode sleep. Ma carte TV a donc peut-être eu du mal à supporter le sleep. Mais dans ce cas, il serait peut-être utile de réinitialiser le graph, ou carrément de quitter PTVM et le relancer. Je me doute que ça pause des difficultés, car je ne sais pas si PTVM peut se rendre compte qu'il vient d'être réveillé, mais il est peut-être possible de procéder autrement. Vous avez écrit que dans la prochaine version, la 2ème instance communique avec celle qui tourne déjà pour lui signifier de s'ouvrir. Dans le cas des enregistrements programmés, l'option --minimize est incluse dans la ligne de commande, donc la 1ere instance ne s'ouvre pas. Ne serait-il pas facile d'ajouter une option --reset, pour forcer la 1ère instance à réinitialiser la carte TV et le graph? (Bien sur, si la 1ère instance est déjà en train d'enregistrer, ce ne serait pas possible, mais ça ne devrait pas être le cas après un sleep.)

Une meilleure solution serait qu'avant un enregistrement, le reset soit fait de toute façon (si PTVM est icônifié et qu'un autre enregistrement n'est pas en cours).

De toutes façons, maintenant que j'ai cette piste à explorer, je vais faire quelques essais d'enregistrements programmés avec une instance qui tourne lors du sleep, et vous dire si c'est bien là le problème.

[r0lZ]

Confirmé!

C'est très facile à tester. Il suffit de lancer PTVM (icônifié ou non), puis de mettre l'ordi en veille. Lorsque l'ordinateur est réveillé, l'image qui était affichée lors du sleep reste à l'écran indéfiniment. Control-Q pour réinitialiser le graph est suffisant pour remettre le tout en marche.

J'insiste donc pour pouvoir inclure la possibilité de réinitialiser le graph en ligne de commande, et celle d'inclure cet argument dans la ligne de commande utilisée pour le scheduler de Windoze.

Si santec consulte encore ce fil, peut-il faire le même test?

[Gingko]

Mais maintenant que j'y pense, il se peut que PTVM était déjà en train de tourner dans le tray lorsque j'ai mis la machine en mode sleep. Ma carte TV a donc peut-être eu du mal à supporter le sleep. Mais dans ce cas, il serait peut-être utile de réinitialiser le graph

C'est déjà prévu dans la prochaine version.

Car j'ai constaté qu'effectivement, la quasi-totalité de mes cartes TV, et même le graphe au complet, ne récupéraient pas correctement dans cette situation.

, ou carrément de quitter PTVM et le relancer. Je me doute que ça pause des difficultés, car je ne sais pas si PTVM peut se rendre compte qu'il vient d'être réveillé

Si, il peut.

Il y a une notification précise qui est envoyée par Windows à toutes les applications, dans ce sens, d'une part avant la mise en veille, et d'autre part après réveil.

Gingko

[r0lZ]

C'est déjà prévu dans la prochaine version.

, ou carrément de quitter PTVM et le relancer. Je me doute que ça pause des difficultés, car je ne sais pas si PTVM peut se rendre compte qu'il vient d'être réveillé

Si, il peut.

Il y a une notification précise qui est envoyée par Windows à toutes les applications, dans ce sens, d'une part avant la mise en veille, et d'autre part après réveil.

Marrant. C'est justement la question que je pose dans le sujet "Confirmation du shutdown". Pouvez-vous m'indiquer quels sont ces messages?

[Gingko]

Marrant. C'est justement la question que je pose dans le sujet "Confirmation du shutdown". Pouvez-vous m'indiquer quels sont ces messages?

Voir le message WM_POWERBROADCAST (signification variable en fonction de ses paramètres).

Gingko

[r0lZ]

Merci! J'ai fait quelques tests pour intercepter la mise en veille avec WM_POWERBROADCAST, et en effet, ça fonctionne. (Il est plus difficile sous Vista et Win7 d'interdire le sleep, mais c'est aussi possible. De toutes façons, ce n'est pas ce que je voulais faire.)

J'ai donc maintenant un script capable d'intercepter le mode sleep (quand il est initié) et de vite fermer PTVM, avant que le mode sleep ne soit effectif. J'ai aussi tenté de le laisser vivre, et d'intercepter le réveil du PC après le mode sleep, pour envoyer Control-Q à PTVM et l'obliger à reconstruire le graph, mais ça ne fonctionne pas, car l'interception a lieu avant le login, et soit PTVM n'est pas encore prêt, soit mon script n'a pas les droits nécessaires parce que l'utilisateur n'est pas loggé. Bref, je me contente donc de fermer PTVM proprement lors du sleep, ce qui permet à l'instance lancée par le scheduler de windows de démarrer sans problème. Adieu donc les problèmes de fichier vide!

Et tant que j'y étais, j'ai aussi ajouté dans le script la possibilité de surveiller si PTVM tourne, et d'entrer automatiquement en mode sleep (ou hibernate) quand ce n'est plus le cas. Je sais que la prochaine version de PTVM permettra de programmer le sleep au lieu du shutdown après un enregistrement, mais en attendant, j'ai tout ce qu'il me faut pour programmer plusieurs enregistrements, et laisser le PC au repos entre ces enregistrements. Il me suffit de dire simplement à PTVM de quitter après l'enregistrement, et mon script fait la mise en mode sleep, et le scheduler relance PTVM pour l'enregistrement suivant. Pratique!

Je posterai peut-être ce script compilé dans la section Contribution, après l'avoir testé un peu mieux...

[r0lZ]

Dans la foulée, je me suis demandé ce qu'il se passe quand on fait un shutdown, sleep ou hibernate de l'ordinateur pendant que PTVM est en train d'enregistrer. Malheureusement, sous Win7 en tous cas, le shutdown se produit bien, et on se ramasse un fichier incomplet. Ça me parait dommage, car quand PTVM est icônifié (et surtout s'il a démarré automatiquement via le scheduler), on peut complètement oublier qu'il enregistre, et faire un shutdown sans mesurer les conséquences.

J'ai donc tenté de modifier mon script pour qu'il puisse intercepter le shutdown, et je parviens bien à l'empêcher. (Je n'ai pas testé avec sleep et hibernate, mais ça devrait être à peu près la même chose.) Malheureusement, si le shutdown se bloque, et même si l'utilisateur décide de l'annuler complètement, ça n’empêche pas PTVM d'être brutalement fermé par Windows. Je n'ai donc pas tenté d'aller plus loin, car de toute évidence, ce blindage doit être dans PTVM lui-même. (De plus, je n'ai pour le moment aucun moyen de tester si PTVM enregistre, et empêcher le shutdown quand il ne fait qu'attendre dans le tray qu'on veuille bien se souvenir de lui n'a pas beaucoup de sens!)

Gingko, je ne sais pas si l'arrêt du shutdown est prévu dans la version actuelle, ou s'il le sera dans la prochaine, mais ça aussi ça me parait important, au moins autant que le fait de demander la permission d'éteindre l'ordinateur à la fin d'un enregistrement. Dans un cas, on perd son travail en cours, et dans l'autre, l'enregistrement. A éviter dans les deux cas, donc!

Si c'est déjà prévu dans la v0.6.1.263 x64, c'est que ça ne marche pas sous Win7 et Vista, qui nécessitent d'utiliser un API documenté ici: Application Shutdown Changes in Windows Vista. Il suffit d'un appel à ShutdownBlockReasonCreate() pour que tout fonctionne à peu près comme sous XP, et même un peu mieux.

Pouvez-vous voir ça aussi pour la prochaine version? Il me semble important de forcer l'ordinateur à tourner en permanence tant qu'un enregistrement est en cours. (L'utilisateur a toujours la possibilité de forcer le shutdown si vraiment c'est ce qu'il veut, mais au moins, il saura qu'il va perdre un enregistrement.)

Je pense même que sous Win7/Vista, si c'est correctement implanté, il serait possible de lancer un enregistrement manuellement, puis de demander le shutdown (ou le sleep ou hibernate), et, dès qu'apparaît l'écran de Windows disant que PTVM refuse de se fermer, laisser les choses en l'état. Lorsque PTVM a fini d'enregistrer, il appelle normalement ShutdownBlockReasonDestroy(), et le shutdown peut continuer comme si de rien n'était, même après plusieures heures d'attente. Ce serait un bon truc, quoi qu'un peu bizarre, pour arrêter l'ordi à la fin d'un enregistrement lancé manuellement.

Merci d'avance!

[Gingko]

J'ai donc maintenant un script capable d'intercepter le mode sleep (quand il est initié) et de vite fermer PTVM, avant que le mode sleep ne soit effectif. J'ai aussi tenté de le laisser vivre, et d'intercepter le réveil du PC après le mode sleep, pour envoyer Control-Q à PTVM et l'obliger à reconstruire le graph, mais ça ne fonctionne pas, car l'interception a lieu avant le login, et soit PTVM n'est pas encore prêt, soit mon script n'a pas les droits nécessaires parce que l'utilisateur n'est pas loggé. Bref, je me contente donc de fermer PTVM proprement lors du sleep, ce qui permet à l'instance lancée par le scheduler de windows de démarrer sans problème. Adieu donc les problèmes de fichier vide!

Et tant que j'y étais, j'ai aussi ajouté dans le script la possibilité de surveiller si PTVM tourne, et d'entrer automatiquement en mode sleep (ou hibernate) quand ce n'est plus le cas. Je sais que la prochaine version de PTVM permettra de programmer le sleep au lieu du shutdown après un enregistrement, mais en attendant, j'ai tout ce qu'il me faut pour programmer plusieurs enregistrements, et laisser le PC au repos entre ces enregistrements. Il me suffit de dire simplement à PTVM de quitter après l'enregistrement, et mon script fait la mise en mode sleep, et le scheduler relance PTVM pour l'enregistrement suivant. Pratique!

Je posterai peut-être ce script compilé dans la section Contribution, après l'avoir testé un peu mieux...

Il est déjà prévu que la prochaine version de Pouchin TV Mod fasse ça (ou plus précisément, détruise le graphe sans quitter, et pour le relancer ensuite).
Votre contribution ferait donc double emploi, et serait d'un usage plus complexe.

Dans la foulée, je me suis demandé ce qu'il se passe quand on fait un shutdown, sleep ou hibernate de l'ordinateur pendant que PTVM est en train d'enregistrer. Malheureusement, sous Win7 en tous cas, le shutdown se produit bien, et on se ramasse un fichier incomplet. Ça me parait dommage, car quand PTVM est icônifié (et surtout s'il a démarré automatiquement via le scheduler), on peut complètement oublier qu'il enregistre, et faire un shutdown sans mesurer les conséquences.
[…]
Gingko, je ne sais pas si l'arrêt du shutdown est prévu dans la version actuelle, ou s'il le sera dans la prochaine, mais ça aussi ça me parait important, au moins autant que le fait de demander la permission d'éteindre l'ordinateur à la fin d'un enregistrement. Dans un cas, on perd son travail en cours, et dans l'autre, l'enregistrement. A éviter dans les deux cas, donc!
[…]
Pouvez-vous voir ça aussi pour la prochaine version? Il me semble important de forcer l'ordinateur à tourner en permanence tant qu'un enregistrement est en cours. (L'utilisateur a toujours la possibilité de forcer le shutdown si vraiment c'est ce qu'il veut, mais au moins, il saura qu'il va perdre un enregistrement.)!

Ce qu'il faudrait maintenant, surtout, c'est arrêter d'ajouter des trucs et sortir une version « stable », ça fait plus d'un an qu'il n'y en a pas eu.

Il sera toujours temps de voir ça pour la version suivante.

Sinon, il ne sera plus possible de rien sortir, les choses à faire arrivent plus vite qu'il y a de temps pour les faire (et les tester !!!).

En attendant, ne supposez pas que le programme va prendre toutes les précautions possibles à votre place, et faites davantage attention à comment vous l'utilisez.

Gingko

[r0lZ]

Il est déjà prévu que la prochaine version de Pouchin TV Mod fasse ça (ou plus précisément, détruise le graphe sans quitter, et pour le relancer ensuite).
Votre contribution ferait donc double emploi, et serait d'un usage plus complexe.

De fait. Tant mieux si c'est prévu. Mais j'avais bien écrit que ma solution était en attendant la prochaine version.

Ce qu'il faudrait maintenant, surtout, c'est arrêter d'ajouter des trucs et sortir une version « stable », ça fait plus d'un an qu'il n'y en a pas eu.

Il sera toujours temps de voir ça pour la version suivante.

Sinon, il ne sera plus possible de rien sortir, les choses à faire arrivent plus vite qu'il y a de temps pour les faire (et les tester !!!).

Tout à fait d'accord. Cependant, ajouter le contrôle du shutdown ne devrait pas prendre beaucoup de temps. J'ai faits tous les tests, je sais que ça fonctionne bien, et il m'a suffi d'une heure de travail. Cela dit, je ne veux pas mettre la pression! Il est vrai qu'il y a plus important.

En attendant, ne supposez pas que le programme va prendre toutes les précautions possibles à votre place, et faites davantage attention à comment vous l'utilisez.

Hum, sur ce point, je ne peux pas être d'accord. Un bon programme doit idéalement tenir compte de toutes les possibilités de mauvaise utilisation. Ce sera toujours un rêve impossible à atteindre, mais il me semble qu'il faut tout tenter pour obtenir ce résultat. Quant au fait de remettre ça à une version plus tardive, par contre, je peux totalement le comprendre. Il y a toujours des priorités.

Ne m'en voulez-pas si je balance autant de suggestions en si peu de temps. C'est pour deux raisons. D'abord, je trouve PTVM génial, et il me semble que faire des suggestions constructives ne peut que le rendre encore meilleur. Si j'avais trouvé PTVM mauvais ou moyen, je ne passerais pas mon temps à lui programmer une télécommande, ni à intervenir dans ce forum. Ensuite, c'est justement parce que je fait ce programme de télécommande que je suis obligé de faire beaucoup de tests, et bien sur, je découvre des bugs, et quelques insuffisances. Mon programme touche à sa fin, et je devrais donc me calmer bientôt!

De toutes façons, merci pour votre rapidité à répondre, et vos intentions d'implanter certaines de mes idées. Je n'ai jamais espéré que toutes le soient!