Merci pour le lien GitHub.
Car celui dans le jeu pour les bugs et les idées me met un formulaire GitHub de connexion à un compte... que je n'ai pas. Sic.

Et en remontant l'ensemble des releases, la vraie raison profonde à mon désarroi sur des parties déjà en cours au moment de cette release:

The Atlantic cables now come ashore where they really do: Ami-Tea at Bordeaux and Dunno-ant at Nantes, and Dunno-ant starts at Virginia Beach.

https://github.com/fjaeckel/seriesoftubes/releases/tag/v3.1.0
En gras, la raison et le câble qui va de France vers NY. L'autre va un "village" US.

Pour ta proposition, je vais surtout profiter pour avancer quelques jours sur d'autres projets (j'ai commencé le codage d'une page supplémentaire pour mon site perso).
Mais c'est vrai que ça me permettrai de me faire la main sur l'auto-hébergement de Node.js (pas encore fait).

J'ai quand même essayé de sauver cette partie 2, mais ouvrir une autre liaison sous-marine ailleurs pour relier l'Europe et les USA me plombe la partie (en finance), soit une 3eme liaison. Et seule cette liaison se met à se bloquer à 4 longueurs d'ondes... alors qua ma 1ere partie n'avait pas cette "limite" sur cette liaison.... ni les autres liaisons sous-marines. Et tout mes routeurs ont des ports de libres partout.

Aller, je vous laisse deviner sur quel bouton de la capture j'ai appuyé... et je n'ai même pas sauvegardé par export cette partie 2 là.
Par intuition et expérience, les grandes nouveautés arrivent toujours avec de grands bugs. Pas la peine de sauvegarder juste après une grande nouveauté, c'est trop risqué.


EDIT:
- jeu mis sur ma liste noire (trop bugué depuis la v3)
- désabonné de ce sujet (je regarderai parfois si avec une nouvelle partie créée avec la v3 vous arriverez à dépasser 4 longueurs d'onde sur NY-Paris)

EDIT 2:
J'ai trouvé la cause visible.
J'ai testé aussi avec ma 1ere partie: même blocage sur cette liaison mais avec beaucoup plus de longueurs d'onde déjà en place.
J'ai créé une partie TEST: cette liaison sous-marine n'existe carrément plus du jeu!
Conclusion: bug ou volontaire, ça oblige de refaire (encore) un nouveau réseau de 0, pour ne pas se laisser piéger à vouloir répartir du trafic où on n'a que peu d'options pour ça dans le jeu...
Un jeu aussi mouvant, non merci.

Sur mon installation, OQEE sous Android TV mettait plusieurs secondes à changer de chaîne en qualité haute. Le passage en qualité Intermédiaire rendait le zapping rapide.

Le problème a été résolu par une règle de pare-feu IPv6 ciblée sur l’UCG-FIBER. Voici la procédure, avec des IPv6 fictives à remplacer par vos propres adresses.

Pourquoi ce ralentissement ?

Les captures réseau ont montré qu’OQEE contactait correctement la Freebox en RTSP, puis lui demandait d’ouvrir une nouvelle connexion TCP vers la TV, sur un port variable.

Cette connexion entrante échouait. OQEE attendait environ 3 secondes par tentative avant d’abandonner. Un test IPv6 Internet pouvait pourtant être bon : il ne vérifie pas cette connexion particulière.
1. Relever les bonnes IPv6
   Il faut identifier :
   - l’IPv6 de la Freebox Server ;
   - l’IPv6 globale de la TV utilisée pendant la lecture OQEE.
   Exemples fictifs :
   Freebox : 2001:db8:1234:100::1
   TV      : 2001:db8:1234:101:1111:2222:3333:4444
2. Vérifier la résolution de mafreebox.freebox.fr
   Dans mon installation, ces deux enregistrements DNS locaux existaient déjà sur l’UCG :
   Type   Nom   Destination
   A   mafreebox.freebox.fr   212.27.38.253
   AAAA   mafreebox.freebox.fr   IPv6 réelle de la Freebox
   
   
   212.27.38.253 est une adresse de service Free, pas une IP personnelle. L’AAAA doit désigner la Freebox, et non l’UCG.
   La TV doit utiliser le DNS de l’UCG pour bénéficier de ces entrées. Dans mon cas, elles fonctionnaient déjà : le correctif décisif était la règle suivante.
3. Créer la règle de pare-feu
   Dans UniFi Network, ouvrir Settings → Policy Table → Create New Policy → Firewall. Le chemin peut varier selon la version.
   Champ   Valeur
   Nom   OQEE Freebox vers TV
   Source Zone   External
   Source IP   2001:db8:1234:100::1/128
   Source Port   Any
   Action   Allow
   Auto Allow Return Traffic   Coché
   Destination Zone   Internal, ou la zone réelle du réseau TV
   Destination IP   2001:db8:1234:101:1111:2222:3333:4444/128
   Destination Port   Any
   IP Version   IPv6
   Protocol   TCP
   Connection State   All
   
   
   Placer la règle avant les règles de blocage.
   Les ports restent sur Any, car le port demandé change à chaque tentative. L’autorisation est toutefois limitée à une adresse source Freebox et une adresse destination TV, en TCP IPv6.
   Une seule règle est à créer manuellement : la case Auto Allow Return Traffic fait gérer automatiquement le retour par UniFi.
4. Retester en qualité haute
   Après enregistrement, remettre OQEE en qualité haute et tester plusieurs changements de chaînes.
   Chez moi, le zapping est devenu immédiatement rapide.
Attention au suivi : l’IPv6 de la TV peut changer. Si cela arrive, il faudra adapter la destination de la règle ; une réservation IPv4 ne fixe pas cette IPv6.

Cette solution correspond au blocage observé sur mon installation, sans garantir que toutes les lenteurs OQEE ont la même cause.

Bonjour tout le monde

La question a du revenir plusieurs fois, mais j'ai rien vu dans la recherche, désolé
Depuis hier, j'ai des ralentissements sur certaines pages, je voulais tester du côté des DNS (et on m'avait aussi conseillé de les changer par d'autres que ceux de Free)
Ceux de Cloudfare semble être les mieux pour la rapidité (et kif kif côté sécurité) comparé à ceux de Free
 
Vous utilisez quel DNS ?

Merci
 
PS : bizarrement, il y a très très longtemps j'avais fais un ipconfig /all pour avoir les DNS (de Free) enregistré sous Windows (y a plus de 15 ans)
Et j'avais cela

Serveurs DNS. . .  . . . . . . . . . . : 212.27.40.241
                                          212.27.40.240

Je pensais que le 212.27.40.241 était donc le primaire, et en regardant sur le net aujourd'hui, c'est en fait le secondaire
15 ans que je tourne avec 212.270.40.241 / 212.27.40.240

Ou Free à changer les DNS depuis ?

Bonjour,

Grosse correction pour Edge.
On a mal interprété l'annonce de Microsoft, mais c'est toutefois le début de la fin.

Depuis la fin de l'été:
- il n'est plus possible de soumettre une nouvelle extensions MV2 dans https://microsoftedge.microsoft.com/addons/Microsoft-Edge-Extensions-Home
- très progressivement, et en test A/B (pour une même version, le comportement diffère d'une installation à l'autre), il y a d'abord un message d’avertissement sur fond rouge ou orange (selon le thème) dans edge://extensions/ pour avertir de la fin prochaine du MV2, puis le blocage pur et simple des extensions MV2 déjà installées... d'ici la fin de l'année pour le grand publique
- une procédure avancée "pour les entreprises"... qui fonctionnera jusqu'en avril 2027 (mais je n'ai pas fait de recherche sur ce point, car ce sera beaucoup moins longtemps que ce qu'avait laisser Chrome malgré ses propres annonces)

Pour vous donner une idée de cette progressivité, je viens de mettre mon Edge en version 157 (la dernière du moment), et j'ai ni blocage d'Ublock Origin (non Lite), ni avertissement dans edge://extensions/

Les navigateurs basés sur chromium n'ont plus la possibilité de supporter correctement les bloqueurs de pubs, depuis 2025.
Ublock & ghostery ont déjà défintivement quitté les plateformes publicitaires que sont google et chromium.
Sans passer par firefox, considérer qu'il est impossible de bloquer efficacement la pub. Google a tranché, aux internautes de s'adapter.