Nouveau:Humax TN 5050 HDR TNTSAT Canal Ready

[franky62]

le technicien solitaire est rentré de congé de paques !

[Invite44]

Vive l'Humax !

[deerevtt]

Message reçu a l'instant ,bonne communication de Humax
Bonjour

Nous avons bien pris en compte votre message pour un problème de changement d’heure sur votre décodeur HUMAX.

Une mise à jour signal a été effectuée aujourd’hui.

Pour remettre à l’heure votre décodeur il suffit donc de le redémarrer.



Nous comprenons le problème et la gêne que cela a pu engendrer de votre côté.

Nous vous prions de bien vouloir nous en excuser.

Nous vous souhaitons une très bonne journée.

Bien cordialement.

[DOURIK95]

Problème résolu également pour moi ce midi. Donc pas de complot!
Seulement un léger retard.
Merci à tous pour vos participations,
JYG

Pour ma part un redémarrage l'a mis à jour,ce qui n'était pas le cas hier.

[JPMSHIVAS]

Bonjour !
Mon Humax 5050 vient de se mettre à l'heure cet après midi, sans manipulation particulière de ma part.
Donc, tout est rentré dans l'ordre.
Je crois que l'on doit reconnaitre que cette fois ci, Humax n'était pas impliqué dans le problème puisqu'ils ne sont pas intervenus.
Cordialement à tous !

[blancoco]

Ça c'est pas sur on ne connaît pas l'origine du problème ni comment ça a été résolu

[kavana]

C'est bon aussi chez moi pour le changement d'heure N'empeche c'est galere ce retard !!!

[JOJO54]

Yes , problème réglé , merci à Humax et à blancoco...

[st4rw4tcher]

Ça c'est pas sur on ne connaît pas l'origine du problème ni comment ça a été résolu

Au contraire, l'origine du problème et sa résolution sont parfaitement connues.

J'ai déjà expliqué ici: http://www.homecinema-fr.com/forum/post178845704.html#p178845704 que certains terminaux ne gèrent pas rigoureusement, ou pas dynamiquement, ou pas du tout, les champs Time_of_change et Next_time_offset du descripteur local_time_offset_descriptor de la table TOT (cf. norme ETS 300 476 pour la spécification détaillée). Cette table est diffusée sur le PID 20 pour ceux que la technique intéresse (et qui veulent comprendre la commande dvbsnoop utilisée plus bas pour la vérification). Pour ces terminaux donc, les diffuseurs ont été obligés de procéder à une actualisation du descripteur diffusé, ce qui a été fait aujourd'hui, comme vous pouvez le constater au nouveau contenu du descripteur (comparer les champs Local_time_offset et Time_of_change avec ceux de mon post précédent):

Code: Tout sélectionner

$ dvbsnoop -n 1 -hideproginfo -pd 4 -nph 20
------------------------------------------------------------
SECT-Packet: 00000001   PID: 20 (0x0014), Length: 29 (0x001d)
Time received: Tue 2016-03-29  21:55:19.678
------------------------------------------------------------
PID:  20 (0x0014)  [= assigned for: DVB Time and Date Table (TDT), Time Offset Table (TOT)]
Guess table from table id...
TOT-decoding....
Table_ID: 115 (0x73)  [= Time Offset Table (TOT)]
section_syntax_indicator: 0 (0x00)
Section_length: 26 (0x001a)
UTC_time: 0xe084195519 [= 2016-03-29 19:55:19 (UTC)]
        DVB-DescriptorTag: 88 (0x58)  [= local_time_offset_descriptor]
        descriptor_length: 13 (0x0d)
            Country_code:  FRA
            Country_region_ID: 0 (0x00)
            local_time_offset_polarity: 0  [= plus to UTC]
            Local_time_offset: 02:00
            Time_of_change: 0xe15b010000 [= 2016-10-30 01:00:00 (UTC)]
            Next_time_offset: 01:00
==========================================================

A contrario, les terminaux qui respectent scrupuleusement la sémantique du descripteur sont capables de sélectionner dynamiquement le "bon" décalage horaire (Local_time_offset ou Next_time_offset) selon le résultat de la comparaison entre l'heure universelle DVB et le paramètre Time_of_change du descripteur. C'est ce qu'ils ont fait en interprétant scrupuleusement le descripteur local_time_offset qui était diffusé la nuit du changement d'heure. Ça leur a permis de passer automatiquement à l'heure d'été. De la même manière, ils passeront automatiquement à l'heure d'hiver le 30/10/2016.

J'espère que c'est clair cette fois-ci.

sw

[45dnlmro]

Là c'est très clair. Prochain RdV concernant le changement d'heure le dimanche 30/10/2016 à 01h00 (UTC).
Merci "st4rw4tcher"

Mon déco est également sur l'heure d'été.
A plus

[45dnlmro]

Je remarque également que mon dernier post ( 29 Mar 2016 22:45 ) a également 1h de retard...
Il va falloir mettre à jour l'horloge du site HOMECINEMA.

[blancoco]

Ça c'est pas sur on ne connaît pas l'origine du problème ni comment ça a été résolu

Au contraire, l'origine du problème et sa résolution sont parfaitement connues.

J'ai déjà expliqué ici: http://www.homecinema-fr.com/forum/post178845704.html#p178845704 que certains terminaux ne gèrent pas rigoureusement, ou pas dynamiquement, ou pas du tout, les champs Time_of_change et Next_time_offset du descripteur local_time_offset_descriptor de la table TOT (cf. norme ETS 300 476 pour la spécification détaillée). Cette table est diffusée sur le PID 20 pour ceux que la technique intéresse (et qui veulent comprendre la commande dvbsnoop utilisée plus bas pour la vérification). Pour ces terminaux donc, les diffuseurs ont été obligés de procéder à une actualisation du descripteur diffusé, ce qui a été fait aujourd'hui, comme vous pouvez le constater au nouveau contenu du descripteur (comparer les champs Local_time_offset et Time_of_change avec ceux de mon post précédent):

Code: Tout sélectionner

$ dvbsnoop -n 1 -hideproginfo -pd 4 -nph 20
------------------------------------------------------------
SECT-Packet: 00000001   PID: 20 (0x0014), Length: 29 (0x001d)
Time received: Tue 2016-03-29  21:55:19.678
------------------------------------------------------------
PID:  20 (0x0014)  [= assigned for: DVB Time and Date Table (TDT), Time Offset Table (TOT)]
Guess table from table id...
TOT-decoding....
Table_ID: 115 (0x73)  [= Time Offset Table (TOT)]
section_syntax_indicator: 0 (0x00)
Section_length: 26 (0x001a)
UTC_time: 0xe084195519 [= 2016-03-29 19:55:19 (UTC)]
        DVB-DescriptorTag: 88 (0x58)  [= local_time_offset_descriptor]
        descriptor_length: 13 (0x0d)
            Country_code:  FRA
            Country_region_ID: 0 (0x00)
            local_time_offset_polarity: 0  [= plus to UTC]
            Local_time_offset: 02:00
            Time_of_change: 0xe15b010000 [= 2016-10-30 01:00:00 (UTC)]
            Next_time_offset: 01:00
==========================================================

A contrario, les terminaux qui respectent scrupuleusement la sémantique du descripteur sont capables de sélectionner dynamiquement le "bon" décalage horaire (Local_time_offset ou Next_time_offset) selon le résultat de la comparaison entre l'heure universelle DVB et le paramètre Time_of_change du descripteur. C'est ce qu'ils ont fait en interprétant scrupuleusement le descripteur local_time_offset qui était diffusé la nuit du changement d'heure. Ça leur a permis de passer automatiquement à l'heure d'été. De la même manière, ils passeront automatiquement à l'heure d'hiver le 30/10/2016.

J'espère que c'est clair cette fois-ci.

sw

Oui on est d'accord quand je disais ça c'est qu'on ne savais pas pourquoi cette fois ci ces appareils ont Merdouille, mon duo2 et mon atlas n'ont pas eu de probleme

[Invite44]

... Pour ces terminaux donc, les diffuseurs ont été obligés de procéder à une actualisation du descripteur diffusé, ce qui a été fait aujourd'hui, comme vous pouvez le constater au nouveau contenu du descripteur ... A contrario, les terminaux qui respectent scrupuleusement la sémantique du descripteur sont capables de sélectionner dynamiquement le "bon" décalage horaire ... C'est ce qu'ils ont fait en interprétant scrupuleusement le descripteur local_time_offset qui était diffusé la nuit du changement d'heure. Ça leur a permis de passer automatiquement à l'heure d'été. De la même manière, ils passeront automatiquement à l'heure d'hiver le 30/10/2016.

Est-ce que c'est clair ? oui et non à la fois

Les explications données sont plus que convaincantes techniquement, mais elles n'expliquent pas l'intérêt qu'a le diffuseur, en l’occurrence Humax, à ne pas respecter la "sémantique" (le mot est fort) comme les autres le font ; puisque dans le cas présent il est contraint de procéder après coup à l'actualisation du descripteur, il est évident qu'à chaque changement d'heure il devra procéder de même, quel bénéfice retire t il d'avoir à agir sous la pression des utilisateurs ? Je ne vois aucun sens commercial dans cette politique pour la direction d'Humax.

[cajun67]

... Pour ces terminaux donc, les diffuseurs ont été obligés de procéder à une actualisation du descripteur diffusé, ce qui a été fait aujourd'hui, comme vous pouvez le constater au nouveau contenu du descripteur ... A contrario, les terminaux qui respectent scrupuleusement la sémantique du descripteur sont capables de sélectionner dynamiquement le "bon" décalage horaire ... C'est ce qu'ils ont fait en interprétant scrupuleusement le descripteur local_time_offset qui était diffusé la nuit du changement d'heure. Ça leur a permis de passer automatiquement à l'heure d'été. De la même manière, ils passeront automatiquement à l'heure d'hiver le 30/10/2016.

Est-ce que c'est clair ? oui et non à la fois

Les explications données sont plus que convaincantes techniquement, mais elles n'expliquent pas l'intérêt qu'a le diffuseur, en l’occurrence Humax, à ne pas respecter la "sémantique" (le mot est fort) comme les autres le font ; puisque dans le cas présent il est contraint de procéder après coup à l'actualisation du descripteur, il est évident qu'à chaque changement d'heure il devra procéder de même, quel bénéfice retire t il d'avoir à agir sous la pression des utilisateurs ? Je ne vois aucun sens commercial dans cette politique pour la direction d'Humax.

je suis tout à fait d'accord avec toi , car HUMAXX n'as pas fait correctement son boulot

[franky62]

le 30.10 sera un lundi. le tecnicien solitaire ne sera pas en congé.