Pouchin TV Mod

fabien59 a écrit :lorsque que je supprime config.ini, pour rénitialiser la config, ca refonctionne sauf que là pouchintv mod a encore planté et je n'arrive pas à tuer le process.

il faut redémarrer, je me demande si ce n'est pas ffdshow qui fait foirer?

Ainsi que je l''ai déjà dit, ce type de plantage avec impossibilité de tuer le processus ne se produit normalement que dans un pilote qui ne rend pas la main après une entrée/sortie, les pilotes fonctionnant dans le mode dit « protégé » du microprocesseur (mais cela relève sans doute aussi d'une erreur de conception dans Windows). C'est aussi, par exemple, dans ce mode protégé que se produisent les plantages avec « écran bleu ».

Un codec n'a pas besoin normalement du mode protégé pour fonctionner.
Sauf cas particulier, celui des codecs exploitant une accélération matérielle (comme CoreAVC pour l'accélération matérielle « CUDA », ou bien une de ces dernières versions expérimentales de ffdshow qui essaient tant bien que mal d'exploiter l'accélération DXVA), pour lesquels ce problème pourrait effectivement exister.

Certains logiciels de debugging sont capables de donner des indications permettant de déterminer l'endroit du plantage.

Gingko

pour ma part j'ai toujours cocher décalage 5 khz avec offset à zero , en fait les fréquences du Monts d'Arrée Finistère non pas le 167 khz

Bonsoir,
tout d'abord merci pour cette nouvelle version, ça plaisir de voir que ça évolue
J'ai effectué quelques tests et dans l'ensemble c'est bon mais le paramétrage du

Temps d'affichage OSD avant exécution de "chaine suivante" et "chaine précédente" (millisecondes)

ne semble pas avoir d'effet (pas de diff entre 10000 et 100).



@+

Chez moi, l'option du temps d'affichage fonctionne parfaitement avec la version .250.

ronaldo1 a écrit :Bonsoir,
tout d'abord merci pour cette nouvelle version, ça plaisir de voir que ça évolue
J'ai effectué quelques tests et dans l'ensemble c'est bon mais le paramétrage du

Temps d'affichage OSD avant exécution de "chaine suivante" et "chaine précédente" (millisecondes)

ne semble pas avoir d'effet (pas de diff entre 10000 et 100).

@+

C'est vrai que j'aurais dû appeler ça autrement.

En fait, le temps d'affichage est toujours le même (3 secondes), ce qui varie, c'est le temps de latence avant que la chaîne change effectivement.
Mais je pense que ne vais pas augmenter le temps OSD, plutôt plafonner le temps de latence à 3 secondes (plus long est assez déconcertant).

Gingko

Dans ce cas, on pourrait peut être renommer l'option : Temps de latence avant exécution de "chaine suivante" et "chaine précédente" ?

Bonsoir,

C'est vrai que j'aurais dû appeler ça autrement.

Ça m'arrive aussi

JL38 a écrit :Dans ce cas, on pourrait peut être renommer l'option : Temps de latence avant exécution de "chaine suivante" et "chaine précédente" ?

je dirais même mieux (enfin c'est mon avis ) :
-Temps de latence avant exécution du changement de chaine
ou
-délai avant exécution du changement de chaine

re,

Je ne sais pas si ça déjà été dit mais lors d'un enregistrement programmé (j'essaierai plus tard l'enregistrement direct) je ne peux plus changer de chaine QUE via le menu.

PS: je suis sous Windows 7 64Bits et j'utilise PouchinTV 64 Bits

+1, on peut changer de chaine que via le menu.

-Temps de latence avant exécution du changement de chaine
ou
-délai avant exécution du changement de chaine

C'est pas mal aussi, mais le changement de chaine passe aussi par la saisie du numéro de la chaine, qui n'est pas concerné par ce temps de latence.

JL38 a écrit :Dans ce cas, on pourrait peut être renommer l'option : Temps de latence avant exécution de "chaine suivante" et "chaine précédente" ?

C'est une des premières idées que j'ai eues, mais c'est trop long. Et pas très professionnel, en plus. Il faut quelque chose de plus concis.

ronaldo1 a écrit :

JL38 a écrit :Dans ce cas, on pourrait peut être renommer l'option : Temps de latence avant exécution de "chaine suivante" et "chaine précédente" ?

je dirais même mieux (enfin c'est mon avis ) :
-Temps de latence avant exécution du changement de chaine
ou
-délai avant exécution du changement de chaine

JL38 a écrit :

-Temps de latence avant exécution du changement de chaine
ou
-délai avant exécution du changement de chaine

C'est pas mal aussi, mais le changement de chaine passe aussi par la saisie du numéro de la chaine, qui n'est pas concerné par ce temps de latence.

Effectivement, il est concerné par un autre temps de latence (pour permettre de saisir plusieurs chiffres).
Et ce temps est beaucoup plus court.

En fait, vous êtes en train de repasser là toute la réflexion que je m'étais moi-même tenu quant à la manière de nommer l'option.
J'avais fini par parler d'OSD, parce qu'il n'y a que dans les commandes de type « chaîne suivante » et « chaîne précédente » qu'une latence avec affichage OSD existe. Mais ce n'est pas fameux non plus.

Si vous avez d'autres idées…

Gingko

ronaldo1 a écrit :Je ne sais pas si ça déjà été dit mais lors d'un enregistrement programmé (j'essaierai plus tard l'enregistrement direct) je ne peux plus changer de chaine QUE via le menu.

Merci, c'est noté.

Pas besoin que l'enregistrement soit programmé, d'ailleurs.

Gingko

ronaldo1 a écrit :

JL38 a écrit :Dans ce cas, on pourrait peut être renommer l'option : Temps de latence avant exécution de "chaine suivante" et "chaine précédente" ?

je dirais même mieux (enfin c'est mon avis ) :
-Temps de latence avant exécution du changement de chaine
ou
-délai avant exécution du changement de chaine

JL38 a écrit :

-Temps de latence avant exécution du changement de chaine
ou
-délai avant exécution du changement de chaine

C'est pas mal aussi, mais le changement de chaine passe aussi par la saisie du numéro de la chaine, qui n'est pas concerné par ce temps de latence.

Effectivement, il est concerné par un autre temps de latence (pour permettre de saisir plusieurs chiffres).
Et ce temps est beaucoup plus court.

En fait, vous êtes en train de repasser là toute la réflexion que je m'étais moi-même tenu quant à la manière de nommer l'option.
J'avais fini par parler d'OSD, parce qu'il n'y a que dans les commandes de type « chaîne suivante » et « chaîne précédente » qu'une latence avec affichage OSD existe. Mais ce n'est pas fameux non plus.

Si vous avez d'autres idées…

Gingko[/quote]

Tuner : 713x BDA DVBT Tuner
Capture : 713x BDA Digital Capture
Pilote (tuner & capture) :
-- Connexion : PCI
-- Description : ASUSTeK Tiger Capture Device
-- Fichier(s) : 3xHybrid.sys
-- Version : 1.3.3.1
-- Date : 4-17-2006
-- Fabricant : ASUSTeK

Bonjour avec mon matériel je n'ai pas de souci avec cette version mise a part le temps trop long de changement de chaine lorsque je mets l'affichage des chaines en fonction cela dit j'ai peut être effectué un mauvais réglage

Bonjour Gingko,
Lors d'un voyage, voulant scanner avec la version 0.6.1.250, j'ai eu un plantage brutal de pouchinTV.
De retour chez moi, je scanne à nouveau en 3 passes les chaines de Lille Bouvigny puis celles de la Belgique Wallone et celles de la Belgique Flamande tout va bien.
Par curiosité, je fais un scan complet et là arrivé au canal 32 plantage brutal PTVM a rencontré un pb puis drwtsn32.exe a rencontré un pb, je ferme alors PTVM à partir de la barre de tâche : PVTM ne répond pas voulez-vous terminer maintenant OK PVTM se ferme.
Le canal déclenchant le plantage a une force de 49 et une Q de 40%
quand je scanne dans les mêmes conditions (paramètres de scan par défaut) avec la version 0.6.0.232 aucun plantage idem avec la version de diagnostic.
Il semble donc que ce soit ce canal perturbé qui déclenche le plantage.
Mon installation :
PC portable HP dv9000 - proc : AMD Turion 64 X2 TL-50 - mem : 1GO - carte video : NVIDIA geforce GO 7600 - Windows XP SP3 à jour
tuner Avermedia A828 hybrid TV BDA tuner (XC3018) tous les codecs audio (y compris EAC3) et tous les codecs video (y compris H264) sont gérés par ffdshow rev 3054 2009-08-04.
le paramètrage du scan a tous les paramètres par défaut, et le scan lancé est complet.
J'ai désinstallé PTVM 0.6.1.250 en supprimant les fichiers de config et l'ai réinstallé avec toujours les mêmes problèmes.
Il est vrai, que le problème disparait quand je fais un scan en 3 passes comme indiqué en début de post, idem si j'utilise la version 0.6.0.232.
Qu'en pensez-vous ?
J'apprécie beaucoup votre travail et la qualité de PTVM.
Lukoluk

lukoluk a écrit :Lors d'un voyage, voulant scanner avec la version 0.6.1.250, j'ai eu un plantage brutal de pouchinTV.
De retour chez moi, je scanne à nouveau en 3 passes les chaines de Lille Bouvigny puis celles de la Belgique Wallone et celles de la Belgique Flamande tout va bien.
Par curiosité, je fais un scan complet et là arrivé au canal 32 plantage brutal PTVM a rencontré un pb puis drwtsn32.exe a rencontré un pb, je ferme alors PTVM à partir de la barre de tâche : PVTM ne répond pas voulez-vous terminer maintenant OK PVTM se ferme.
Le canal déclenchant le plantage a une force de 49 et une Q de 40%
quand je scanne dans les mêmes conditions (paramètres de scan par défaut) avec la version 0.6.0.232 aucun plantage idem avec la version de diagnostic.
Il semble donc que ce soit ce canal perturbé qui déclenche le plantage.
Mon installation :
PC portable HP dv9000 - proc : AMD Turion 64 X2 TL-50 - mem : 1GO - carte video : NVIDIA geforce GO 7600 - Windows XP SP3 à jour
tuner Avermedia A828 hybrid TV BDA tuner (XC3018) tous les codecs audio (y compris EAC3) et tous les codecs video (y compris H264) sont gérés par ffdshow rev 3054 2009-08-04.
le paramètrage du scan a tous les paramètres par défaut, et le scan lancé est complet.
J'ai désinstallé PTVM 0.6.1.250 en supprimant les fichiers de config et l'ai réinstallé avec toujours les mêmes problèmes.
Il est vrai, que le problème disparait quand je fais un scan en 3 passes comme indiqué en début de post, idem si j'utilise la version 0.6.0.232.
Qu'en pensez-vous ?

Bonjour,

Désolé, mais pas assez d'informations sur les circonstances du plantage lui-même.
N'y a-t-il aucun code d'erreur ou détails de plantages que vous pourriez ajouter ?

Vous dites qu'il n'y a pas de problèmes avec la version de diagnostic, ce qui est assez curieux. Sommes-nous bien en train de parler de la version de diagnostic 0.6.1.250 (aussi) ?
Combien d'essais avec vous effectués avec chaque version (pour éliminer la possibilité de coïncidences) ?

Actuellement, sauf changement impromptu, le canal 32 semble utilisé par l'émetteur de Lille Lambersart pour le multiplex R3 (uniquement des chaînes payantes).
Voyez aussi si quelque chose change selon les horaires (par exemple heures où certaines chaînes payantes sont gratuites).

Gingko