Ïðîáëåìà ñ WI-FI ïðè ïðîñìîòðå IPTV íà wl500gp

**Forkur** · 28-05-2009, 20:57

Originally Posted by Omega

À ãäå "èíôîðìàöèÿ äëÿ ðàçìûøëåíèé" ? Êàêàÿ ïðîøèâêà ? Êàêîé ïðîâàéäåð, ïëåéëèñò ?

Äà è ïðè÷åì çäåñü ðîóòåð ? Âû è áåç íåãî, íàïðÿìóþ ñìîòðåòü IPTV òîæå íå ñìîæåòå ...

Åñëè ó Âàñ IPTV îò ÊÎÐÁÈëàéÍÀ, òî êàíàëû IPTV ýòîãî ïðîâàéäåðà ì.á. çàêîäèðîâàíû ...

RTSP - òîò æå ìóëüòèêàñò, äëÿ íåãî â ðîóòåðå äîñòàòî÷íî âêëþ÷èòü Multicast Routing, íî
ñêîðåå âñåãî èñïîëüçîâàí êîäåê H.264, êîòîðûé â VLC è IPTV Player ðåàëèçîâàí ñëàáî ...

Ëó÷øå ñìîòðåòü á/ï êàíàëû IPTV ÷åðåç TV Player îò SergeyVS (Ñâîÿ ïðîãðàììà äëÿ IPTV)

Íàñòðîéêà ðàáîòû IPTV íà ðîóòåðe Asus WL-500gP * IP-TV Player (îáñóæäåíèå/ïîääåðæêà)

Ç.Û. Äà, è íå íàäî áîëüøå àïàòü, çäåñü íå "ñêóïêà êðàäåíîãî" è íå "ðåêëàìíûå îáúÿâëåíèÿ"

Íè ïëååð âàø, íè íàñòðîéêè êîòîðûå âû ïðèâåëè íå ïîìîãàþò.

Ïðîøèâêà 1.9.2.7-10á Ïðîâàéäåð UnionLine, ïëåéëèñò http://www.u-l.ru/iptv.m3u
Íàïðÿìóþ âñ¸ ïîêàçûâàåò.
Enable multicast routing? - Yes

**Forkur** · 31-05-2009, 16:58

UPUPUPUPUPUPUPUP

**Omega** · 01-06-2009, 03:07

Originally Posted by Forkur

Íè ïëååð âàø, íè íàñòðîéêè êîòîðûå âû ïðèâåëè íå ïîìîãàþò.
Ïðîøèâêà 1.9.2.7-10á
Ïðîâàéäåð UnionLine, ïëåéëèñò http://www.u-l.ru/iptv.m3u
Íàïðÿìóþ âñ¸ ïîêàçûâàåò. Enable multicast routing? - Yes

Ìîæåò âñ¸-òàêè 1.9.2.7-10à : http://oleg.wl500g.info/pre10a/WL500gp-1.9.2.7-10.7.trx ?

Code:

#EXTM3U
#EXTINF:0,Îðò
rtsp://10.14.100.1:7001/optt.sdp
#EXTINF:0,Ðîññèÿ
rtsp://10.14.100.1:7002/russ.sdp
#EXTINF:0,ÒÂÖ
rtsp://10.14.100.1:7003/tvcc.sdp
#EXTINF:0,ÍÒÂ
rtsp://10.14.100.1:7004/ntvv.sdp

rtsp://10.14.100.1:7001/optt.sdp Í-äà, êàê âñ¸ çàïóùåíî ... Ñìîòðåòü IPTV ÷åðåç RealPlayer ...

File Description : Informational file created with media broadcasting software;
contains the format, timing, and authorship of the streamed media;
may be created for live streaming media with a program like Sorenson.
Broadcaster or for prerecorded media using a program like PlaylistBroadcaster.

In order for SDP information to be transmitted with the streaming media, the SDP
file must be stored in the designated media directory on the streaming server.
Program(s) that open sdp files : Apple QuickTime Player RealNetworks RealPlayer

RTFM : http://tools.ietf.org/html/draft-ietf-mmusic-sdp-new-26

Code:

4.1. Media and Transport Information

   An SDP session description includes the following media information:

   o  The type of media (video, audio, etc.)
   o  The transport protocol (RTP/UDP/IP, H.320, etc.)
   o  The format of the media (H.261 video, MPEG video, etc.)

   In addition to media format and transport protocol, SDP conveys
   address and port details. For an IP multicast session, these comprise:

   o  The multicast group address for media
   o  The transport port for media

   This address and port are the destination address and destination
   port of the multicast stream, whether being sent, received, or both.

   For unicast IP sessions, the following are conveyed:

   o  The remote address for media
   o  The remote transport port for media

Session description

         v=  (protocol version)
         o=  (owner/creator and session identifier)
         s=  (session name)
         i=* (session information)
         u=* (URI of description)
         e=* (email address)
         p=* (phone number)
         c=* (connection information - not required if included in all media)
         b=* (zero or more bandwidth information lines)
         One or more time descriptions ("t=" and "r=" lines, see below)
         z=* (time zone adjustments)
         k=* (encryption key)
         a=* (zero or more session attribute lines)
         Zero or more media descriptions

      Time description

         t=  (time the session is active)
         r=* (zero or more repeat times)

      Media description, if present

         m=  (media name and transport address)
         i=* (media title)
         c=* (connection information - optional if included at session-level)
         b=* (zero or more bandwidth information lines)
         k=* (encryption key)
         a=* (zero or more media attribute lines)

An example SDP description is:

      v=0
      o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
      s=SDP Seminar
      i=A Seminar on the session description protocol
      u=http://www.example.com/seminars/sdp.pdf
      e=j.doe@example.com (Jane Doe)
      c=IN IP4 224.2.17.12/127
      t=2873397496 2873404696
      a=recvonly
      m=audio 49170 RTP/AVP 0
      m=video 51372 RTP/AVP 99
      a=rtpmap:99 h263-1998/90000

Such layered encodings

   are normally transmitted in multiple multicast groups to allow
   multicast pruning.  This technique keeps unwanted traffic from sites
   only requiring certain levels of the hierarchy.  For applications
   requiring multiple multicast groups, we allow the following notation
   to be used for the connection address:

      <base multicast address>[/<ttl>]/<number of addresses>

   If the number of addresses is not given it is assumed to be one.
   Multicast addresses so assigned are contiguously allocated above 
   the base address, so that, for example:

      c=IN IP4 224.2.1.1/127/3

   would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are to
   be used at a TTL of 127.  This is semantically identical to including
   multiple "c=" lines in a media description:

      c=IN IP4 224.2.1.1/127
      c=IN IP4 224.2.1.2/127
      c=IN IP4 224.2.1.3/127

5.12. Encryption Keys

      ("k=")
      k=<method>
      k=<method>:<encryption key>

   If transported over a secure and trusted channel, the session
   description protocol MAY be used to convey encryption keys.  A simple
   mechanism for key exchange is provided by the key field ("k=")
   although this is primarily supported for compatibility with older
   implementations and its use is NOT RECOMMENDED.  Work is in progress
   to define new key exchange mechanisms for use with SDP [28] [29] and
   it is expected that new applications will use those mechanisms.

   A key field is permitted before the first media entry (in which case
   it applies to all media in the session), or for each media entry as
   required.  The format of keys and their usage is outside the scope of
   this document, and the key field provides no way to indicate the
   encryption algorithm to be used, key type, or other information about
   the key: this is assumed to be provided by the higher-level protocol
   using SDP.  If there is a need to convey this information within SDP,
   the extensions mentioned previously SHOULD be used.  Many security
   protocols require two keys: one for confidentiality, another for
   integrity.  This specification does not support transfer of two keys.

   The method indicates the mechanism to be used to obtain a usable key
   by external means, or from the encoded encryption key given.  The
   following methods are defined:

      k=clear:<encryption key>

         The encryption key is included untransformed in this key field.
         This method MUST NOT be used unless it can be guaranteed that
         the SDP is conveyed over a secure channel.  The encryption key
         is interpreted as text according to the charset attribute, use
         the "k=base64:" method to convey characters that are otherwise
         prohibited in SDP.

      k=base64:<encoded encryption key>

         The encryption key is included in this key field but has been
         base64 encoded [13] because it includes characters that are
         prohibited in SDP.  This method MUST NOT be used unless it can
         be guaranteed that the SDP is conveyed over a secure channel.

      k=uri:<URI to obtain key>

         A Universal Resource Identifier is included in the key field.
         The URI refers to the data containing the key, and may require
         additional authentication before the key can be returned.  When
         a request is made to the given URI, the reply should specify
         the encoding for the key.  The URI is often a a SSL/
         TLS-protected HTTP URI ("https:"), although this is not
         required.

      k=prompt

         No key is included in this SDP description, but the session or
         media stream referred to by this key field is encrypted.  The
         user should be prompted for the key when attempting to join the
         session, and this user-supplied key should then be used to
         decrypt the media streams.  The use of user-specified keys is
         NOT RECOMMENDED, since such keys tend to have weak security
         properties.

   The key field MUST NOT be used unless it can be guaranteed that the
   SDP is conveyed over a secure and trusted channel.  An example of
   such a channel might be SDP embedded inside an S/MIME message or a
   TLS-protected HTTP session.  It is important to ensure that the
   secure channel is with the party that is authorised to join the
   session, not an intermediary: if a caching proxy server is used, it
   is important to ensure that the proxy is either trusted or unable to
   access the SDP.

Ïåðåâåäèòå îäèí èç LAN-ïîðòîâ â îäèí WLAN ñ WAN-ïîðòîì ...

Ïî÷èòàéòå FAQ : çäåñü è òóò ... Ìîæåò áûòü òîëüêî ýòî ïîìîæåò ...

Ç.Û. Âìåñòî "àïîâ" ëó÷øå ïîëüçîâàëèñü áû áîëüøå ïîèñêîì ...

È ÷òî, ó Âàñ â UL ïîñëå Spacesoft'a ñîâñåì íå îñòàëîñü ñïåöîâ ?

**Forkur** · 01-06-2009, 10:55

Originally Posted by Omega

Ìîæåò âñ¸-òàêè 1.9.2.7-10à : http://oleg.wl500g.info/pre10a/WL500gp-1.9.2.7-10.7.trx ?

Code:

#EXTM3U
#EXTINF:0,Îðò
rtsp://10.14.100.1:7001/optt.sdp
#EXTINF:0,Ðîññèÿ
rtsp://10.14.100.1:7002/russ.sdp
#EXTINF:0,ÒÂÖ
rtsp://10.14.100.1:7003/tvcc.sdp
#EXTINF:0,ÍÒÂ
rtsp://10.14.100.1:7004/ntvv.sdp

rtsp://10.14.100.1:7001/optt.sdp Í-äà, êàê âñ¸ çàïóùåíî ... Ñìîòðåòü IPTV ÷åðåç RealPlayer ...

RTFM : http://tools.ietf.org/html/draft-ietf-mmusic-sdp-new-26

Code:

4.1. Media and Transport Information

   An SDP session description includes the following media information:

   o  The type of media (video, audio, etc.)
   o  The transport protocol (RTP/UDP/IP, H.320, etc.)
   o  The format of the media (H.261 video, MPEG video, etc.)

   In addition to media format and transport protocol, SDP conveys
   address and port details. For an IP multicast session, these comprise:

   o  The multicast group address for media
   o  The transport port for media

   This address and port are the destination address and destination
   port of the multicast stream, whether being sent, received, or both.

   For unicast IP sessions, the following are conveyed:

   o  The remote address for media
   o  The remote transport port for media

Session description

         v=  (protocol version)
         o=  (owner/creator and session identifier)
         s=  (session name)
         i=* (session information)
         u=* (URI of description)
         e=* (email address)
         p=* (phone number)
         c=* (connection information - not required if included in all media)
         b=* (zero or more bandwidth information lines)
         One or more time descriptions ("t=" and "r=" lines, see below)
         z=* (time zone adjustments)
         k=* (encryption key)
         a=* (zero or more session attribute lines)
         Zero or more media descriptions

      Time description

         t=  (time the session is active)
         r=* (zero or more repeat times)

      Media description, if present

         m=  (media name and transport address)
         i=* (media title)
         c=* (connection information - optional if included at session-level)
         b=* (zero or more bandwidth information lines)
         k=* (encryption key)
         a=* (zero or more media attribute lines)

An example SDP description is:

      v=0
      o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
      s=SDP Seminar
      i=A Seminar on the session description protocol
      u=http://www.example.com/seminars/sdp.pdf
      e=j.doe@example.com (Jane Doe)
      c=IN IP4 224.2.17.12/127
      t=2873397496 2873404696
      a=recvonly
      m=audio 49170 RTP/AVP 0
      m=video 51372 RTP/AVP 99
      a=rtpmap:99 h263-1998/90000

Such layered encodings

   are normally transmitted in multiple multicast groups to allow
   multicast pruning.  This technique keeps unwanted traffic from sites
   only requiring certain levels of the hierarchy.  For applications
   requiring multiple multicast groups, we allow the following notation
   to be used for the connection address:

      <base multicast address>[/<ttl>]/<number of addresses>

   If the number of addresses is not given it is assumed to be one.
   Multicast addresses so assigned are contiguously allocated above 
   the base address, so that, for example:

      c=IN IP4 224.2.1.1/127/3

   would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are to
   be used at a TTL of 127.  This is semantically identical to including
   multiple "c=" lines in a media description:

      c=IN IP4 224.2.1.1/127
      c=IN IP4 224.2.1.2/127
      c=IN IP4 224.2.1.3/127

5.12. Encryption Keys

      ("k=")
      k=<method>
      k=<method>:<encryption key>

   If transported over a secure and trusted channel, the session
   description protocol MAY be used to convey encryption keys.  A simple
   mechanism for key exchange is provided by the key field ("k=")
   although this is primarily supported for compatibility with older
   implementations and its use is NOT RECOMMENDED.  Work is in progress
   to define new key exchange mechanisms for use with SDP [28] [29] and
   it is expected that new applications will use those mechanisms.

   A key field is permitted before the first media entry (in which case
   it applies to all media in the session), or for each media entry as
   required.  The format of keys and their usage is outside the scope of
   this document, and the key field provides no way to indicate the
   encryption algorithm to be used, key type, or other information about
   the key: this is assumed to be provided by the higher-level protocol
   using SDP.  If there is a need to convey this information within SDP,
   the extensions mentioned previously SHOULD be used.  Many security
   protocols require two keys: one for confidentiality, another for
   integrity.  This specification does not support transfer of two keys.

   The method indicates the mechanism to be used to obtain a usable key
   by external means, or from the encoded encryption key given.  The
   following methods are defined:

      k=clear:<encryption key>

         The encryption key is included untransformed in this key field.
         This method MUST NOT be used unless it can be guaranteed that
         the SDP is conveyed over a secure channel.  The encryption key
         is interpreted as text according to the charset attribute, use
         the "k=base64:" method to convey characters that are otherwise
         prohibited in SDP.

      k=base64:<encoded encryption key>

         The encryption key is included in this key field but has been
         base64 encoded [13] because it includes characters that are
         prohibited in SDP.  This method MUST NOT be used unless it can
         be guaranteed that the SDP is conveyed over a secure channel.

      k=uri:<URI to obtain key>

         A Universal Resource Identifier is included in the key field.
         The URI refers to the data containing the key, and may require
         additional authentication before the key can be returned.  When
         a request is made to the given URI, the reply should specify
         the encoding for the key.  The URI is often a a SSL/
         TLS-protected HTTP URI ("https:"), although this is not
         required.

      k=prompt

         No key is included in this SDP description, but the session or
         media stream referred to by this key field is encrypted.  The
         user should be prompted for the key when attempting to join the
         session, and this user-supplied key should then be used to
         decrypt the media streams.  The use of user-specified keys is
         NOT RECOMMENDED, since such keys tend to have weak security
         properties.

   The key field MUST NOT be used unless it can be guaranteed that the
   SDP is conveyed over a secure and trusted channel.  An example of
   such a channel might be SDP embedded inside an S/MIME message or a
   TLS-protected HTTP session.  It is important to ensure that the
   secure channel is with the party that is authorised to join the
   session, not an intermediary: if a caching proxy server is used, it
   is important to ensure that the proxy is either trusted or unable to
   access the SDP.

Ïåðåâåäèòå îäèí èç LAN-ïîðòîâ â îäèí WLAN ñ WAN-ïîðòîì ...

Ïî÷èòàéòå FAQ : çäåñü è òóò ... Ìîæåò áûòü òîëüêî ýòî ïîìîæåò ...

Ç.Û. Âìåñòî "àïîâ" ëó÷øå ïîëüçîâàëèñü áû áîëüøå ïîèñêîì ...

È ÷òî, ó Âàñ â UL ïîñëå Spacesoft'a ñîâñåì íå îñòàëîñü ñïåöîâ ?

Ýòî áûë åäèíñòâåííûé, êîòîðîãî ïðèçíàâàëà àäìèíèñòðàöèÿ. Åñòü è äðóãèå, íî àäìèíèñòðàöèÿ èõ âî âíèìàíèå áðàòü ñîâåðøåííî íå õî÷åò. Ïî ïîâîäó Âëàí, íà ñêîëüêî ìíå èçâåñòíî, íóæåí åù¸ îäèí ÈÏ äëÿ ñåòè òîãäà, à ó íàñ ýòî ñòîèò 450 ðóáëåé.
Ñåé÷àñ ïî÷èòàþ ïîëíîñòüþ ÷òî âû íàïèñàëè.

ÏÑ ïðîøèâêó ñêîïèðîâàë ñ âåáà ðîóòåðà.

**RCM** · 01-06-2009, 17:18

Èìååòñÿ 500g prem , ïîäêëþ÷åíèå â èíòåðíåò ÷åðåç vpn ñàì èíòåðíåò ðàáîòàåò íîðìàëüíî, íàðåêàíèé íåò, ê ðîóòåðó ïîäêëþ÷åíî 2 ñòàöèîíàðíûõ êîìïüþòåðà è 2 íîóòáóêà ïî wifi Âîïðîñ, ó íàñ ñäåëàëè â ñåòêå ip òåëåâèäåíèå, èç íàñòðîåê íóæíî áûëî òîëüêî âêëþ÷èòü â ðîóòåðå ìóëüòèêàñò, Âîïðîñ! Êîãäà ñìîòðþ òåëåâèçîð íà ëîêàëüíîì êîìïüþòåðå, íà íîóòáóêå ïî wifi èíòåðíåò «íàãëóõî» ïðîïàäàåò, òîëüêî ÿ âûêëþ÷àþ òåëåê «íà êîìïüþòåðå» âñå ñðàçó ïî wifi íà÷èíàåò ëåòàòü, ñíà÷àëà äîëãî ëîìàë ãîëîâó äóìàë ÷òî ÷òî-òî èëè ñ àíòèâèðóñîì, íî âîò â÷åðà ðàçãàäàë ïðè÷èíó îòñóòñòâèÿ èíòåðíåòà íà íîóòáóêå, åñåñíî âîïðîñ ìîæíî ëè ÷òî-òî ñäåëàòü ÷òîáû âñå òàêè êàêòî èëè îãðàíè÷èòü òðàôèê èëè ìîæåò â íàñòðîéêàõ, ãäå òî íàäî ïîñòàâèòü äëÿ wifi ïðèîðèòåò ? êòî íèòü ñ òàêîé ïðîáëåìîé âñòðå÷àëñÿ?

**vectorm** · 01-06-2009, 19:26

Originally Posted by RCM

åñåñíî âîïðîñ ìîæíî ëè ÷òî-òî ñäåëàòü ÷òîáû âñå òàêè êàêòî èëè îãðàíè÷èòü òðàôèê èëè ìîæåò â íàñòðîéêàõ, ãäå òî íàäî ïîñòàâèòü äëÿ wifi ïðèîðèòåò ? êòî íèòü ñ òàêîé ïðîáëåìîé âñòðå÷àëñÿ?

Âû íàâåðíîå óäèâèòåñü, íî â ïîèñêå îáíàðóæèòå íåñêîëüêî ïîäîáíûõ òåì ñ ðåøåíèåì äàííîé ïðîáëåìû, Âû íå ïåðâûé ñ ýòèì âîïðîñîì.

**Omega** · 02-06-2009, 20:07

Originally Posted by vectorm

Âû íàâåðíîå óäèâèòåñü, íî â ïîèñêå îáíàðóæèòå íåñêîëüêî ïîäîáíûõ
òåì ñ ðåøåíèåì äàííîé ïðîáëåìû, Âû íå ïåðâûé ñ ýòèì âîïðîñîì.

+1

Äîñòàòî÷íî íàáðàòü âíèçó òýãè òèïà "iptv" è "wi-fi", è áóäåò Âàì ñ÷àñòüå ...

È IPTV âïðèäà÷ó ...

Íàñòðîéêà ðàáîòû IPTV ïî Wi-Fi íà ðîóòåðe Asus WL-500gP

**RCM** · 04-06-2009, 14:29

Originally Posted by Omega

+1

Äîñòàòî÷íî íàáðàòü âíèçó òýãè òèïà "iptv" è "wi-fi", è áóäåò Âàì ñ÷àñòüå ...

È IPTV âïðèäà÷ó ...

Íàñòðîéêà ðàáîòû IPTV ïî Wi-Fi íà ðîóòåðe Asus WL-500gP

Áîëüøîå ñïàñèáî âñå ïîìîãëî, âîò òîëüêî íå ïîíÿë ïðî iptv íà íîóòå, òàì ïîëó÷àåòñÿ òà ïðîãðàììà êîòîðóþ ñêà÷àòü íóæíî â íåé óæå çàáèòû êàíàëû, à ÿ äóìàë ÷òî òàì â òîì ïëýåðå ìîæíî çàáèòü íàø ïëåéëèñò, íî ÷òîòî êàæåòñÿ ÷òî íîóò íå ïîòÿíåò ïî wifi òåëåê, èáî íà êàíàë íóæíà ïåðåäà÷à ++++ î÷ õîðîøàÿ

**Omega** · 06-06-2009, 02:44

Â íàñòðîéêàõ ïëååðà ìîæíî çàãðóçèòü ñâîé ïëåéëèñò

Ñìîòðåòü íà íîóòå ïî Wi-Fi íóæíî ÷åðåç udp-http proxy

Ðàáîòàåò íîðìàëüíî äàæå ñ 2 êàíàëàìè îäíîâðåìåííî â PiP :-)

**Omega** · 06-06-2009, 04:39

Ïëàòèòü íóæíî òîëüêî çà IPTV

Äîïîëíèòåëüíûé ip-àäðåñ íå íóæåí

Ç.Û. Êàêîé ïëååð èñïîëüçóåòñÿ ?
Ìîæíî åù¸ çàáèòü êîìï â DMZ ...

**komunyaka1** · 08-06-2009, 13:18

Ñëîæèëàñü òàêàÿ ñèòóàöèÿ ïðè ïðîñìîòðå IP TV ïî WIFI ,â îáùåì íå õâàòàåò ñêîðîñòè ïåðåäà÷è ó ðîóòåðà WL 500 GP V 1,ïðîøèâêà ïîñëåäíÿÿ Îëåãà,ïðîâàéäåð ñêàçàë êóïèòü ÄÈÐ 300 è íàñëàæäàòüñÿ.Ïî êàáåëþ âñå èäåò îòëè÷íî.
Âîïðîñ,ìîæíî ÷òî ëèáî ñäåëàòü ?

**Omega** · 08-06-2009, 14:29

Âàø ïðîâàéäåð ñîâñåì íå â òåìå íè ðàçó

Ïîèñê ïî òýãó iptv ïîìîæåò ñìîòðåòü ïî Wi-Fi

**RCM** · 11-06-2009, 06:33

Originally Posted by Omega

Â íàñòðîéêàõ ïëååðà ìîæíî çàãðóçèòü ñâîé ïëåéëèñò

Ñìîòðåòü íà íîóòå ïî Wi-Fi íóæíî ÷åðåç udp-http proxy

Ðàáîòàåò íîðìàëüíî äàæå ñ 2 êàíàëàìè îäíîâðåìåííî â PiP :-)

ñäåëàë âñå êàê íàïèñàíî ïîñòàâèë 81 ïîðò è íàñòðîèë ñïèñîê êàíàëîâ, íå â êàêóþ íå õî÷åò ïîêàçûâàòü, ïîòîì ïîïðîáîâàë èçìåíèòü ïîðò íà 2002 è îïÿòü ïðîáîâàë, âîò ïðèìåð ñïèñêà, êîòîðûé ÿ ñîñòàâèë äëÿ íîóòáóêà
=============
#EXTM3U
#EXTINF:0,Ýôèðíûå: ÎÐÒ
httð://192.108.1.1:81/udp/224.0.42.1:5000
#EXTINF:0,Ýôèðíûå: Ðîññèÿ
=== à ýòî ñïèñîê äëÿ ñòàöèàíàðíîãî êîìïà, íà íåì âñå õîðîøî ïîêàçûâàåò

#EXTM3U
#EXTINF:0,Ýôèðíûå: ÎÐÒ
udp://@224.0.42.1:5000
#EXTINF:0,Ýôèðíûå: Ðîññèÿ
udp://@234.5.2.2:20000

Âîïðîñ ÷òî åùå ìîæíî ïîäêðóòèòü, èëè ãäå ìîÿ îøèáêà?

**xkir** · 11-06-2009, 09:05

Originally Posted by RCM

httð://192.108.1.1:81/udp/224.0.42.1:5000
ãäå ìîÿ îøèáêà?

Ìîæåò âñå òàêè httð://192.168.1.1 à íå httð://192.108.1.1 ?

**RCM** · 11-06-2009, 12:03

Originally Posted by xkir

Ìîæåò âñå òàêè httð://192.168.1.1 à íå httð://192.108.1.1 ?

íó åñëè áû ÿ íà ðîóòåð çàõîäèë 192.168.1.1 òî òîãäà áû ñäåëàë òàê, à òàê ó ìåíÿ ñïåöèàëüíî èçìåíåíî íà ....108..... ò.ê çàáèòû ðîóòèíãè äëÿ DC++ è îíè ìîãóò ñîâïàäàòü.

Thread: Ïðîáëåìà ñ WI-FI ïðè ïðîñìîòðå IPTV íà wl500gp

Thread Tools

Display

Âîïðîñ ïðî ðàáîòó ìóëüòèêàñòà

IPTV

Ïîìîùü IP TV

Tags for this Thread

Posting Permissions