Problemas con Twitch (retransmision de juegos en directo)

Romanalvarado
Yo probé el VDSL
Problemas con Twitch (retransmision de juegos en directo)

No se vosotros pero ni que pongan 1 Gb simetrico de velocidad va bien con movistar Twitch

 

he hecho un tracert hoy dia 28 de octubre a las 23:45 horas y aqui teneis:

 

Traza a la dirección twitch.tv [52.36.196.57]
sobre un máximo de 30 saltos:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     1 ms     2 ms     2 ms  104.red-80-58-67.staticip.rima-tde.net [80.58.67
.104]
  3     *        *        *     Tiempo de espera agotado para esta solicitud.
  4    25 ms    77 ms    25 ms  225.red-80-58-83.staticip.rima-tde.net [80.58.83
.225]
  5    25 ms    36 ms    25 ms  213.140.50.218
  6   133 ms    47 ms    59 ms  xe5-0-4-0-grtparix3.net.telefonicaglobalsolution
s.com [213.140.33.91]
  7  1357 ms   678 ms   340 ms  5-2-17.ear2.Paris1.Level3.net [212.73.207.45]
  8     *        *        *     Tiempo de espera agotado para esta solicitud.
  9   209 ms   209 ms   209 ms  4.16.146.90
 10   208 ms   213 ms   210 ms  52.95.54.12
 11   216 ms   216 ms   216 ms  52.95.54.25
 12   213 ms   214 ms   215 ms  54.239.43.11
 13   240 ms   255 ms   240 ms  52.93.14.40
 14   209 ms   210 ms   210 ms  52.93.14.35
 15     *        *        *     Tiempo de espera agotado para esta solicitud.
 16     *        *        *     Tiempo de espera agotado para esta solicitud.
 17   225 ms   225 ms   224 ms  205.251.232.222
 18     *        *        *     Tiempo de espera agotado para esta solicitud.
 19     *        *        *     Tiempo de espera agotado para esta solicitud.
 20     *        *        *     Tiempo de espera agotado para esta solicitud.
 21     *        *        *     Tiempo de espera agotado para esta solicitud.
 22     *        *        *     Tiempo de espera agotado para esta solicitud.
 23     *        *        *     Tiempo de espera agotado para esta solicitud.
 24     *        *        *     Tiempo de espera agotado para esta solicitud.
 25     *        *        *     Tiempo de espera agotado para esta solicitud.
 26     *        *        *     Tiempo de espera agotado para esta solicitud.
 27     *        *        *     Tiempo de espera agotado para esta solicitud.
 28     *        *        *     Tiempo de espera agotado para esta solicitud.
 29     *        *        *     Tiempo de espera agotado para esta solicitud.
 30     *        *        *     Tiempo de espera agotado para esta solicitud.

Traza completa.

la traza numero 7 , flipa 1357 de ping en francia,no digo mas

 

lo unico solicitar que algun tecnico puede mirar mi linea si esto esta bien,porque yo creo que no.

 

Lo que no entiendo es,localizando las ip hacia donde va la linea ,mi linea siendo de canarias primero va a madrid,luego dice que va a paris en la traza 7,pero esa IP es de inglaterra no de paris,y de hay va estados unidos de la traza 9 hacia delante,tengo menos ping en estados unidos que en paris o inglaterra? es una exageracion mas de 1300 de ping asi como va a ir bien twitch con movistar,si en vez de ir directamente de madrid a estados unidos,se recorre media europa antes de ir a estados unidos.

 

PD: en la traza 6 a telefonica madrid, 133 de ping? XD miradme esto por favor.

Mensaje 1 de 14
4.029 Visitas
13 RESPUESTAS 13
spawn
Yo probé el VDSL

Es una vergüenza el servicio de Movistar y de Movistar con Twitch.

Etiquetas (5)
Mensaje 2 de 14
3.983 Visitas
dennyus
Yo probé el VDSL

todo lo que son servicios que no sean de movistar van con el [....] ( todo lo que este fuera de su red).

 

 

Mensaje 3 de 14
3.955 Visitas
JulioC-Movistar
Antiguo Moderador

El tracert lo que intenta es analizar la ruta que toma, los saltos o nodos por los que va pasando, en el ejemplo creado pasa por cuatro nodos antes de llegar al servidor. Para analizar que equipos o nodos atraviesa les manda un ping y comprueba en que tiempo responde, lo normal es que según te vas alejando del origen el ping se vaya incrementando por el incremento de la distancia a recorrer.

 

Desde un router se lanza un tracert a un servidor X (5)

 

tracert.png

 

 

Tracert a un servidor X

 

  1    5 ms    5 ms    5ms  80.23.5.13
  2     3 ms     7ms     6 ms  104.red-80-58-67.staticip.rima-tde.net [80.58.67
.104]
  3     *        *        *     Tiempo de espera agotado para esta solicitud.
  4    1357 ms    77 ms    25 ms  5-2-17.ear2.Paris1.Level3.net [212.73.207.45]
  5    25 ms    36 ms    25 ms  servidor X  [217.53.125.5]
    

Traza completa.

 

En este ejemplo se pueden ver varios casos:

 

  1    5 ms    5 ms    5ms  80.23.5.13
  2     3 ms     7ms     6 ms  104.red-80-58-67.staticip.rima-tde.net [80.58.67
.104]

 

El tiempo del salto al nodo 2 es menor que el tiempo de salto al nodo 1, algo a priori no posible ya que la distancia es mayor y si hasta el nodo 1 hay un retardo de 5 ms al nodo 2 debiera tener un retardo de 5 ms + XXX ya que está más lejos,  la explicación es que el nodo 1  ha tardado en responder algo más de lo habitual por cualquier motivo, no es síntoma de nada en concreto.


 

 

 

 

 

 

  3     *        *        *     Tiempo de espera agotado para esta solicitud.

 

Puede pasar que como ocurre en el salto 3 que el nodo correspondiente no responda a las peticiones de ping (es lo que hace el tracert, pedir un ping a cada nodo), esta ausencia de respuesta puede ser algo totalmente voluntario por parte del nodo -está configurado para no responder a ningún ping- o algo que dependa de la política de respuesta configurada en ese nodo -puede ser que solo responda 5 peticiones por segundo y las demás las descarte-. Es algo normal y habitual, no es síntoma de nada erróneo, NO son paquetes perdidos, son paquetes que el nodo no contesta, paquetes que desecha.

 

El trabajo del nodo es trasladar al siguiente nodo los paquetes de transito que le llegan, este trabajo lo sigue haciendo sin ningún problema aunque no conteste al ping ya que vemos que la traza llega al siguiente nodo 4 y progresa hasta su destino al servidor X, esto no ocurriría si se perdiese el paquete.

 

 

 

 

 

  4    1357 ms    77 ms    25 ms  5-2-17.ear2.Paris1.Level3.net [212.73.207.45]
  5    25 ms    36 ms    25 ms  servidor X  [217.53.125.5]

 

Puede pasar también lo que ocurre en el salto 4, un incremento brutal del ping (1357 ms), la explicación es la misma que en el caso de los saltos 1 y 2, el nodo 4 está ocupado haciendo otras tareas -reencaminar los paquetes que le llegan hacia su destino final- y tarda mucho en responder a peticiones no prioritarias como un ping, no es sintoma de nada en concreto, puede ser que tarde en responder por carga de trabajo o simplemente por la política de respuesta a ping que tiene configurada el nodo. Si este nodo introdujese un retardo de 1357 ms el siguiente estaría respondiendo con un ping de 1357 ms + XXX y en cambio lo hace con un valor normal de 25 ms.

 

 

En definitiva lo único que importa es la respuesta al ping final, la respuesta de los nodos intermedios hay que descartarla por sistema. Podéis comprobar que está misma explicación la dan desarrolladores de softwares conocidos y ampliamente usados como por ejemplo PingPlotter  http://www.pingman.com/kb/24

 

0.png

 

 

 

 

 

 

 

 



Si necesitas soporte técnico en averías de Móvil, Fijo, Movistar+ o Internet Fijo (cobre o fibra), puedes acceder a nuestro apartado de Soporte Técnico o rellenar este formulario. También puedes contactar con nosotros llamando al 1002.

 Si necesitas contratar Fibra Ópticacomprobar tu cobertura Adsl y Fibrao ver información sobre la instalación de la fibra visita nuestra página ADSL y Fibra en movistar.es 

Solución aceptada.png
Mensaje 4 de 14
3.931 Visitas
Romanalvarado
Yo probé el VDSL

JulioC-Movistar escribió:

El tracert lo que intenta es analizar la ruta que toma, los saltos o nodos por los que va pasando, en el ejemplo creado pasa por cuatro nodos antes de llegar al servidor. Para analizar que equipos o nodos atraviesa les manda un ping y comprueba en que tiempo responde, lo normal es que según te vas alejando del origen el ping se vaya incrementando por el incremento de la distancia a recorrer.

 

Desde un router se lanza un tracert a un servidor X (5)

 

tracert.png

 

 

Tracert a un servidor X

 

  1    5 ms    5 ms    5ms  80.23.5.13
  2     3 ms     7ms     6 ms  104.red-80-58-67.staticip.rima-tde.net [80.58.67
.104]
  3     *        *        *     Tiempo de espera agotado para esta solicitud.
  4    1357 ms    77 ms    25 ms  5-2-17.ear2.Paris1.Level3.net [212.73.207.45]
  5    25 ms    36 ms    25 ms  servidor X  [217.53.125.5]
    

Traza completa.

 

En este ejemplo se pueden ver varios casos:

 

  1    5 ms    5 ms    5ms  80.23.5.13
  2     3 ms     7ms     6 ms  104.red-80-58-67.staticip.rima-tde.net [80.58.67
.104]

 

El tiempo del salto al nodo 2 es menor que el tiempo de salto al nodo 1, algo a priori no posible ya que la distancia es mayor y si hasta el nodo 1 hay un retardo de 5 ms al nodo 2 debiera tener un retardo de 5 ms + XXX ya que está más lejos,  la explicación es que el nodo 1  ha tardado en responder algo más de lo habitual por cualquier motivo, no es síntoma de nada en concreto.


 

 

 

 

 

 

  3     *        *        *     Tiempo de espera agotado para esta solicitud.

 

Puede pasar que como ocurre en el salto 3 que el nodo correspondiente no responda a las peticiones de ping (es lo que hace el tracert, pedir un ping a cada nodo), esta ausencia de respuesta puede ser algo totalmente voluntario por parte del nodo -está configurado para no responder a ningún ping- o algo que dependa de la política de respuesta configurada en ese nodo -puede ser que solo responda 5 peticiones por segundo y las demás las descarte-. Es algo normal y habitual, no es síntoma de nada erróneo, NO son paquetes perdidos, son paquetes que el nodo no contesta, paquetes que desecha.

 

El trabajo del nodo es trasladar al siguiente nodo los paquetes de transito que le llegan, este trabajo lo sigue haciendo sin ningún problema aunque no conteste al ping ya que vemos que la traza llega al siguiente nodo 4 y progresa hasta su destino al servidor X, esto no ocurriría si se perdiese el paquete.

 

 

 

 

 

  4    1357 ms    77 ms    25 ms  5-2-17.ear2.Paris1.Level3.net [212.73.207.45]
  5    25 ms    36 ms    25 ms  servidor X  [217.53.125.5]

 

Puede pasar también lo que ocurre en el salto 4, un incremento brutal del ping (1357 ms), la explicación es la misma que en el caso de los saltos 1 y 2, el nodo 4 está ocupado haciendo otras tareas -reencaminar los paquetes que le llegan hacia su destino final- y tarda mucho en responder a peticiones no prioritarias como un ping, no es sintoma de nada en concreto, puede ser que tarde en responder por carga de trabajo o simplemente por la política de respuesta a ping que tiene configurada el nodo. Si este nodo introdujese un retardo de 1357 ms el siguiente estaría respondiendo con un ping de 1357 ms + XXX y en cambio lo hace con un valor normal de 25 ms.

 

 

En definitiva lo único que importa es la respuesta al ping final, la respuesta de los nodos intermedios hay que descartarla por sistema. Podéis comprobar que está misma explicación la dan desarrolladores de softwares conocidos y ampliamente usados como por ejemplo PingPlotter  http://www.pingman.com/kb/24

 

0.png

 

 

 

 

 

 

 

 


Entiendo lo que comentas,pero no te parece exagerado que en el nodo 7

 

7 1357 ms 678 ms 340 ms 5-2-17.ear2.Paris1.Level3.net [212.73.207.45]

 

como ultimo ping a un servidor de francia sea de 340 de ping

 

ahora te voi a poner otro tracert,que por lo visto a mejorado,y te pregunto si la ruta final de la conexion es en estados unidos,para que primero va a francia y luego a estados unidos? no es mas rapido ir de madrid a estados unidos directamente.

 

esta traza esta hecha hoy dia 31/10/2016 a las 14:50

 

Traza a la dirección twitch.tv [52.41.96.17]
sobre un máximo de 30 saltos:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     2 ms     1 ms     1 ms  104.red-80-58-67.staticip.rima-tde.net [80.58.67
.104]
  3     *        *        *     Tiempo de espera agotado para esta solicitud.
  4    52 ms    25 ms    25 ms  198.red-80-58-83.staticip.rima-tde.net [80.58.83
.198]
  5    24 ms    24 ms    24 ms  213.140.51.13
  6    91 ms   162 ms    47 ms  xe5-0-4-0-grtparix3.net.telefonicaglobalsolution
s.com [213.140.33.91]
  7     *       49 ms    52 ms  5-2-17.ear2.Paris1.Level3.net [212.73.207.45]
  8   203 ms   203 ms   203 ms  ae-2-52.ear2.Seattle1.Level3.net [4.69.206.65]
  9   206 ms   206 ms   206 ms  4.16.146.90
 10   217 ms   314 ms   221 ms  52.95.54.80
 11   211 ms   211 ms   211 ms  52.95.54.95
 12   215 ms   215 ms   215 ms  54.239.43.9
 13   253 ms   216 ms   215 ms  52.93.14.220
 14   214 ms   214 ms   214 ms  52.93.14.217
 15     *        *        *     Tiempo de espera agotado para esta solicitud.
 16     *        *        *     Tiempo de espera agotado para esta solicitud.
 17   214 ms   214 ms   214 ms  205.251.232.225
 18     *        *        *     Tiempo de espera agotado para esta solicitud.
 19     *        *        *     Tiempo de espera agotado para esta solicitud.
 20     *        *        *     Tiempo de espera agotado para esta solicitud.
 21     *        *        *     Tiempo de espera agotado para esta solicitud.
 22     *        *        *     Tiempo de espera agotado para esta solicitud.
 23     *        *        *     Tiempo de espera agotado para esta solicitud.
 24     *        *        *     Tiempo de espera agotado para esta solicitud.
 25     *        *        *     Tiempo de espera agotado para esta solicitud.
 26     *        *        *     Tiempo de espera agotado para esta solicitud.
 27     *        *        *     Tiempo de espera agotado para esta solicitud.
 28     *        *        *     Tiempo de espera agotado para esta solicitud.
 29     *        *        *     Tiempo de espera agotado para esta solicitud.
 30     *        *        *     Tiempo de espera agotado para esta solicitud.

Traza completa.

 

como ves primero va a madrid,luego va en el nodo 7 va a paris.leve13.net para de hay ir a el nodo 8 a seattle1.leve13.net

 

un tracert directamente a seattle1.leve13.net:

 

Traza a la dirección ae-2-52.ear2.Seattle1.Level3.net [4.69.206.65]
sobre un máximo de 30 saltos:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     2 ms     1 ms     1 ms  104.red-80-58-67.staticip.rima-tde.net [80.58.67
.104]
  3     *        *        *     Tiempo de espera agotado para esta solicitud.
  4    27 ms    27 ms    25 ms  225.red-80-58-106.staticip.rima-tde.net [80.58.1
06.225]
  5    24 ms    24 ms    24 ms  ae1-400-gramadte2.net.telefonicaglobalsolutions.
com [216.184.113.186]
  6    25 ms    24 ms    24 ms  lag-13.ear1.Madrid2.Level3.net [4.68.111.33]
  7    25 ms    24 ms    24 ms  vl-3103-ve-131.ebr1.Madrid2.Level3.net [4.69.210
.69]
  8    49 ms    43 ms    42 ms  ae-45-45.ebr2.Paris1.Level3.net [4.69.158.34]
  9   147 ms   146 ms   160 ms  ae-40-40.ebr4.Washington1.Level3.net [4.69.137.1
74]
 10   146 ms   147 ms   146 ms  ae-1-11.ebr3.Washington1.Level3.net [4.69.204.25
3]
 11   166 ms   149 ms   149 ms  ae-15-3615.ebr4.Atlanta2.Level3.net [4.69.150.23
3]
 12     *      157 ms   157 ms  ae-41-41.ebr5.Dallas1.Level3.net [4.69.209.238]

 13   178 ms   178 ms   184 ms  ae-28-28.ebr3.Denver1.Level3.net [4.69.210.189]

 14   174 ms   174 ms   174 ms  ae-1-11.ebr4.Denver1.Level3.net [4.69.206.214]
 15   199 ms   210 ms   199 ms  ae-3.ebr4.Seattle1.Level3.net [4.69.203.237]
 16   199 ms   199 ms   201 ms  ae-2-52.ear2.Seattle1.Level3.net [4.69.206.65]

Traza completa.

en mi opinion aqui el nodo que sobra es el 8,que va de madrid a paris,cuando deberia de ir directamente desde madrid al servidor de estados unidos,al nodo 9 Washington1.Level3.net

Mensaje 5 de 14
3.919 Visitas
JulioC-Movistar
Antiguo Moderador

El tiempo de respuesta de los nodos intermedios como te decía no es significativo de nada, simplemente ese nodo no prioriza la respuesta al ping, es más con un poco más de tiempo daría como no contestado y de forma errónea se podría interpretar como paquete perdido cuando no es así.

 

Por otro lado para llegar a un determinado servidor lo tenemos que hacer por las rutas por las que se anuncia ese servidor, probablemente solo se anuncia por la ruta a la que tenemos acceso por Paris.



Si necesitas soporte técnico en averías de Móvil, Fijo, Movistar+ o Internet Fijo (cobre o fibra), puedes acceder a nuestro apartado de Soporte Técnico o rellenar este formulario. También puedes contactar con nosotros llamando al 1002.

 Si necesitas contratar Fibra Ópticacomprobar tu cobertura Adsl y Fibrao ver información sobre la instalación de la fibra visita nuestra página ADSL y Fibra en movistar.es 

Solución aceptada.png
Mensaje 6 de 14
3.886 Visitas
Romanalvarado
Yo probé el VDSL

JulioC-Movistar escribió:

El tiempo de respuesta de los nodos intermedios como te decía no es significativo de nada, simplemente ese nodo no prioriza la respuesta al ping, es más con un poco más de tiempo daría como no contestado y de forma errónea se podría interpretar como paquete perdido cuando no es así.

 

Por otro lado para llegar a un determinado servidor lo tenemos que hacer por las rutas por las que se anuncia ese servidor, probablemente solo se anuncia por la ruta a la que tenemos acceso por Paris.


sea como sea por la rutas,por donde se anuncie,o por lo que sea yo como usuario final cliente,soy quien da uso de la conexion de 300 megas simetricos de movistar,y doy fe que no va bien.

 

lo curioso es que en mi edificio,tengo 3 opciones para contratar fibra,200 de jazztel y 300 de orange ( fibra directa,no la misma fibra de movstar con distinto nombre)  y por supuesto la fibra de 300 de movistar.

 

tengo vecinos con fibra directa de 200 de jazztel y con 300 de orange,le he preguntado a algunos de mis vecinos sino le importa que haga algunas pruebas con Twitch en su friba de jazztel y a otros con su fibra de orange.

 

Y mira por donde,un vecino que tengo a tres metros de mi,con su fibra de 200 de Jazztel le va de lujo,hace una  prueba en Twitch de velocidad de tranferencia para transmitir juegos y le recomienda una calidad alta,la mas alta,superando incluso los 2000 KB/s que es la alta.

 

en cambio yo hago la misma prueba con el mismo dispositivo con mi conexion de movistar 300 de fibra y me dice que debo transmitir a una velocidad baja,la mas baja incluso por debajo de la mas baja,porque la calidad mas baja en Twitch para transmitir es de 800 KB/s y a mi en algunas pruebas en Twitch con mi fibra de movistar me a dicho que debo tranmitir los juegos a una calidad de 400 KB/s.

 

asi que,que me contestas a eso?

 

porque yo no soy tecnico,ni especialista en rutas ni especialista en detalles tecnicos,pero no hay que tener un master o un doctorado en algo,para darte cuenta que si haciendo pruebas a un mismo servicio,con un mismo dispositivo (PC,consola de videojuegos,etc..) y ves que a tu vecino que vive a tres metros de ti con 200 de jazztel le va de lujo y a ti con tus 300 de movistar te va de pena,pues no hay que ser un lumbreras,sino un simple cliente utilizando un poco de logica y sentido comun;para darte cuenta que en mismas condiciones (utilizando los mismos aparatos) y solamente usando conexiones de diferentes compañias,va de lujo con jazztel y va de pena con movistar,pues sera problema de movistar,y no de los servicios ajenos a movistar o de los aparatos que utilizas.

 

Porque yo he ido a casa de mi vecino con mi PC y mi consola de videojuegos, he realizado las mismas pruebas con los mismos aparatos,y en su conexion de jazztel de 200 megas va de lujo,este servicio.

 

luego me llevo mis aparatos a mi casa,mi pc y mi consola de videojuegos,y con movistar va de pena,el mismo servicio.y teniendo supuestamente 100 megas mas de velocidad que mi vecino.

 

hay alguna explicacion tecnica para esto? o simplemente se puede usar el sentido comun y la logica,de un cliente llano.porque por muchas vueltas que se le de al asusto,la logica es aplastante.

 

Fijate si es aplastante la logica que me planteado cambiar de compañia,a jazztel 200 megas,lo unico es que estoy un poco amarrado porque compre un movil en movistar y aun lo estoy pagando,que sino no estariamos hablando aqui de este asunto.

 

 

Mensaje 7 de 14
3.875 Visitas
spawn
Yo probé el VDSL

Y por eso yo me ahorro aportar tracers y otras pruebas que no tienen porque ser significativas.

 

Lo que importa y lo que reclamo es que no funciona, yo reitero mis posts, lo sé, pero habeis sumado más de 30 usuarios reportando idéntico problema no en este hilo, si no en todos los que habeis ido cerrando que son varios.

 

Os falla un mes, funciona bien una semana y vuelta a fallar. Teneis un problema y me causais a mí otro, al menos vamos a compartirlo de ahora en adelante 😉

Mensaje 8 de 14
3.848 Visitas
Leander
Yo probé el VDSL
Mensaje 9 de 14
3.839 Visitas
spawn
Yo probé el VDSL

No me importa el motivo, pero puedo añadir esto otro:

 

http://i.imgur.com/ou3sS8S.png

 

Ese es un test hecho por uno de los desarrolladores de OBS, como se puede ver tengo velocidad suficiente contra los servers a los que envio mi audio/video.

 

Pero ni yo ni otros Españoles con movistar pueden verme, se corta cada 5 segundos.

 

De hecho, mi stream queda archivado correctamente.

Mensaje 10 de 14
3.827 Visitas
JulioC-Movistar
Antiguo Moderador

@romanalvarado  ¿Has probado a cambiar los servidores a los que emites? ¿En todos tienes la misma limitación?

 

@spawn  El problema que planteas, un usuario movistar emite y el resto de usuarios movistar lo ve con parones de buffer ya se planteó hace tiempo y el problema está en que no podemos probarlo ya que entra en medio la red de twitch, lo que tu emites llega bien a twitch, si un usuario de otra operadora lo quiere ver lo ve sin problemas, los usuarios de Movistar que ven tu stream con buffering ven otros videos -de usuarios de otras operadoras- sin buffer. No es algo que solo le ocurra a Movistar Can't watch my own stream while streaming from the same internet connection (EEUU) , ya se trató en su día sin solución explicacion de funcionamiento de twitch

 

 

 

 

 

 



Si necesitas soporte técnico en averías de Móvil, Fijo, Movistar+ o Internet Fijo (cobre o fibra), puedes acceder a nuestro apartado de Soporte Técnico o rellenar este formulario. También puedes contactar con nosotros llamando al 1002.

 Si necesitas contratar Fibra Ópticacomprobar tu cobertura Adsl y Fibrao ver información sobre la instalación de la fibra visita nuestra página ADSL y Fibra en movistar.es 

Solución aceptada.png
Mensaje 11 de 14
3.803 Visitas
spawn
Yo probé el VDSL

De acuerdo 100% con que la mayoría de los tracer carecen de valor.

 

El plugin que permitía cambiar de servidor ya no funciona (obvio no es un plugin vuestro), el Global Server dejó de funcionar y el resto de localizaciones que se pueden escoger funcionan mal.

 

Cada X tiempo falla la visualización con todos los streams no solo con los de Movistar y corroboro con usuarios de otras operadoras que ellos no están afectados.

 

Acepto lo de que lo único manipulable sea la ruta del CDN a mi hogar,

 

En relación a la explicación animada no me queda claro del todo claro, ¿emito a América, de América vuelve a Francia y de nuevo a España?

 

¿Podrías dividir mi emisión y mi propia visualización citando los elementos que intervienen, usando CDN's como ejemplos? (no necesito que sea por medio de otro dibujo).

 

 

 

 

Mensaje 12 de 14
3.770 Visitas
JulioC-Movistar
Antiguo Moderador

El Gif que ves lo hice en su día por una queja similar, en aquel momento veiamos que la descarga la hacía desde un cdn en Amsterdan si no recuerdo mal, el envío se realizaba a EEUU, lo que hace twitch entre medias lo desconozco, puedes ver desde donde descargas el video siguiendo estas instrucciones

 

Hay que analizar las conexiones, os tenéis que bajar el TCPview de Microsoft, es un fichero zip

 

 

 

 

 

 

descomprimis el zip en una carpeta donde os encontraréis estos archivos

 

 

 

 

 

 

Con el botón derecho del ratón hacemos clic encima de Tcpview.exe  y lo ejecutamos como administrador.

 

 

 

 

 

Ahora arrancamos un navegador y nos vamos a twitch.tv y visualizamos un directo cualquiera

 

 

 

 

 

 

 

 

En el TCPView clicamos en la columna Rcvd Bytes (Bytes recibidos) para ordenarlo de mayor a menor

 

 

 

 

 

 

 

esperamos 2-3 minutos y comprobamos cual es la IP que tiene más Bytes recibidos, esa será la IP del CDN de video de twitch desde el que os está sirviendo datos de video, esa es la IP que nos hace falta saber, por favor enviarme un privado con ese dato, vuestra IP en ese momento y un tracert a esa IP (dejar que acabe el tracert, que de traza completa, le lleva un rato) todos estos datos en modo texto por favor.

 

 

 

Luego puedes ver la localización de esa IP en ipinfo.io

 

 



Si necesitas soporte técnico en averías de Móvil, Fijo, Movistar+ o Internet Fijo (cobre o fibra), puedes acceder a nuestro apartado de Soporte Técnico o rellenar este formulario. También puedes contactar con nosotros llamando al 1002.

 Si necesitas contratar Fibra Ópticacomprobar tu cobertura Adsl y Fibrao ver información sobre la instalación de la fibra visita nuestra página ADSL y Fibra en movistar.es 

Solución aceptada.png
Mensaje 13 de 14
3.746 Visitas
JulioC-Movistar
Antiguo Moderador

No hemos tenido más noticias tuyas, espero que tu duda haya quedado resuelta, si para mañana no hemos recibido noticia en contra lo daremos por solucionado y cerraremos el hilo, si te encuentras el hilo cerrado y sigues con problemas no dudes en ponerte en contacto de nuevo con nosotros en Soporte Técnico Banda Ancha

 

Si consideras que alguna de las respuestas es la solución a tu duda o problema, te agradecería que la marques clicando en el botón "Aceptar como solución" con esa acción ayudarás a otros usuarios que puedan tener el mismo problema.



Si necesitas soporte técnico en averías de Móvil, Fijo, Movistar+ o Internet Fijo (cobre o fibra), puedes acceder a nuestro apartado de Soporte Técnico o rellenar este formulario. También puedes contactar con nosotros llamando al 1002.

 Si necesitas contratar Fibra Ópticacomprobar tu cobertura Adsl y Fibrao ver información sobre la instalación de la fibra visita nuestra página ADSL y Fibra en movistar.es 

Solución aceptada.png
Mensaje 14 de 14
3.728 Visitas