Het grote V6 decoder topic

hello all

hoewel ik een slechte internet verbinding heb (40xspeedtest :10 Mb dwnload en 0.15 up) verliepen de eerste testen goed. (via rj45 kable geen wIFI)
na ook internet connectie problemen en alle bbbox3 en huawei STB fabrieksresetten met tandenstoker
slechts tijdelijk soelaas brachten terug overgeschakeld weinig def. soelaas brachten in de TV-kanaal keuze onderbrekingen ben ik na 2 welen terug overgeschakeld op dezelfde rj 45 kabel en bbox3 kabel op de oude cisco STB.

deze was dus een viertien dagen niet meer online geweest en wat bleek dat de software automatisch werd geupdate naar een versie NTE_9244 welke mij voldoet daar de oude reeds meer dan een jaar gemelde fout omtrent het verwijderen van oude geplande serie -opnamens nu eindelijk kon verwijderd worden .
ik heb dus eindelijk alle geplande reeksen kunnen verwijderen en ook alle opnames.

terug naar de nieuwe geschakeld en ook daar zag ik geen oude reeksen meer die ongewenst werden opgenomen.

hopende dat de belasting op de binnenkomende signaal bandbreedt nu wat zou verminderen werd er echter geen verbetering wastgesteld met de Versie 6

bij omschakelen van kanaal 1 naar 1>2>3456 tot 10 , traag verloor ik regelmatig beeld , klank en dan zwart en dan verbinding die soms terugkwam na een tiental seconden wat echter niet klopte want zodra je TV guide drukt was de info er en kon je verder.

een speedtest op dat moeilijk moment gaf geen slechter cijfer of beter(geen opnames bezig)

als je met de zogenaamd slechte verbindigs onmiddelijk overschakeld naar de cisco dus met zelfde kabel en poort bbox 3 is er geen probleem

de fout zit hem dacht ik op de server waar de emulatie van de versie 6 gebeurd naast die van de vijf cisco

na enige helpdesk meldingen waar denk ik dat er een profiel kan gereset zijn op de server.
hoe dan ook heb ik zelf nu mijn pc kabel Rj 45 genomen om beide n dus op verschillende poorten kort aan te sluiten. nu moet ik slechts overschakelenop mijn tv tussen de 2 HDMI aansluitingen en wat bleek
dat het bnu ineens wel ok is .
en ook blijft als ik het terug met een een dezelde kabel en poort bbox 3 omwissel

ik denk dat het profiel in de server in de knoop geraakt omdat sommige udp profielen in upload voor de kanaal keuzes niet toekomen door mijn te lage upload snelheid van mijn internet verbinding.
waarschijnlijk zit er dius een verschil in de upload kanaalkeuzes UDP paketten van de oude cisco geupdate STB tov de nieuwe huawai V6 kanaal keuzepaketten die gevoeliger is voor een slechte uploadkwaliteit

hieronder enige uitleg gevonden op google:
https://www.tvtechnology.com/expertise/iptv-revolutionizing-the-tv-industry

TCP And UDP
IP defines two protocols for sending messages within IP packets. Transmission Control Protocol (TCP) is a reliable, connection-oriented protocol that guarantees reception and in-order delivery of data from a sender to a receiver. For example, if a packet doesn't arrive in time and is assumed lost, the sender will receive a request to resend that packet. Using the postcard analogy, with IP, some postcards are duplicated, and some are lost. TCP puts the postcards back in order, throws away duplicates and requests the missing ones. This is important to the delivery of compressed digital video, where the loss of a single byte can affect video and audio quality.

User Datagram Protocol (UDP), on the other hand, is a connectionless protocol that provides a best effort in getting the data to its final destination. For many real-time, time-sensitive applications, such as streaming A/V, UDP is often used instead of TCP. UDP minimizes overhead and is not affected by network data loss or delays. However, unlike TCP, UDP is not a guaranteed transport mechanism. If a packet gets lost anywhere along the line, the destination application will simply never get that data.

Why would IPTV use UDP if packets can get lost? Broadcast IPTV services using IP multicast are a good example of how UDP might be preferred over TCP. A typical MPEG-2 compressed bit stream might deliver millions of bits per second, contained in thousands of IP packets. The sending device broadcasts these thousands of packets to potentially hundreds of devices in the multicast group simultaneously. If a packet gets lost and is not received by one of the viewers, it would not make sense to halt the transmission while a request is made to resend that missing packet.

Unicast Vs. Multicast
IP is primarily a unicast protocol. It was designed to convey messages from a single source device to a single destination device. IP, however, also defines multicast addresses: destination addresses that represent more than one destination device. Internet Group Management Protocol (IGMP) manages multicast data flows.


From an IPTV perspective, VOD is an example of a unicast application. Data is sent from a single source — the VOD server — to a single destination — a consumer's home. For each unicast VOD session, there is a separate stream of content on the network. Each stream could be 5Mb/s for SD or up to 15Mb/s for HD video. That could add up to a huge amount of bandwidth within the network.

Figure 2 shows a broadband network with three homes playing a VOD movie. Each home has an active unicast session with a VOD server in the headend. There are three separate video bit streams flowing from the headend/VOD server to each house, along with a back channel for trick mode support, such as pause, play, fast forward and rewind.

With multicast, a single source sends data to multiple destinations at a single time. Each broadcast television channel would have a unique IP multicast group, for example. Using IGMP protocol, clients can receive the broadcast packets and enable the routing of the broadcast stream to their network device through the network. Multicast saves much more network bandwidth than unicast, but there is no reliability mechanism so lost packets stay lost.

Figure 3 shows a broadband network with three homes currently playing the same broadcast video stream of the 2006 Winter Olympics. Each home has an active multicast session receiving the same video bit stream, which originates from the headend.

Multimedia Over IP
Multimedia and networking is core to IPTV. Multimedia applications use various media types, such as text, graphics, animations, audio and video. There are many network-based multimedia applications today. Furthermore, there are many bright and imaginative minds working on ideas for applications intended for high-speed bidirectional networks.

Networked multimedia applications are important, so it is critical for the IPTV network architect or content creator to understand the issues associated with multimedia networking as well as understand what tools can enable effective and compelling new applications.

Within the network, multimedia data can be affected in the following ways: dropped packets, jitter between packet delivery times, delayed packets and data corruption. Even when the TCP protocol is used, the effectiveness of the IPTV service can be affected by the reliability and speed of the network.

The goal of quality of service (QoS) is to make sure the network can deliver end-to-end data with expected and predicted results. This includes latency, error rates, up-time, bandwidth and network traffic loads.

QoS can be extremely important to a successful IPTV service within a congested network. Only service operators that also own and manage the IP network to homes can guarantee QoS for the service. IPTV services that use the general Internet are not guaranteed the QoS necessary for a good user experience.

Real-Time Transport Protocol
IP networks were not designed for real-time delivery of data and can have unpredictable jitter and delay. The multimedia data that travels on the IP networks must arrive on time and in the same order it was sent. Real-time Transport Protocol (RTP) addresses the time-critical requirement of multimedia bit streams. It provides a timestamp and sequence number to IP packets containing media data. These can be used by the receiving device to synchronize playback and manage buffers for network jitter.

Encapsulating Media Data Into IP Packets
Delivery of media bit streams over IP requires several layers of encapsulation. MPEG-2 transport streams, for example, consist of a series of 188-byte packets. These are grouped together and wrapped within an RTP packet. Finally, the RTP packet is encapsulated within a TCP or UDP datagram, forming an IP packet.


Figure 4 shows an RTP packet containing several MPEG-2 transport packets within its payload, all encapsulated using UDP in an IP packet. This diagram shows seven 188-byte transport packets that constitute the RTP payload.

Each encapsulation adds additional header data and therefore reduces the bandwidth efficiency. If the network has sufficient QoS, it is possible to deliver media packets without the overhead of RTP. The packets are instead inserted directly into UDP packets. Figure 5 shows how MPEG-2 transport stream packets can be encapsulated within a UDP/IP packet.

Sending MPEG-2 transport stream packets over UDP is used extensively within the private networks of cable and telephone companies to deliver MPEG-2 transport streams throughout the system. For general delivery over the unmanaged Internet without QoS guarantees, streaming protocols such as RTP need to be used, but even then, packets may be lost in delivery, resulting in artifacts in the media presentation.

There are other system layer standards besides MPEG-2 and next-generation compression methods such as AVC H.264. While the encapsulation methods may differ slightly, they all require either strong QoS or overhead to ensure timely delivery of media packets.

Summary
Delivering TV and movie services over IP promises to revolutionize almost every component of the television industry. Just as the Internet changed the way we shop, read the news and personally interact, television services over IP could change how we integrate television entertainment into our daily lives. Decades old business models may change as a result of this technological shift to IPTV.

The Internet and the protocols used within it were not designed for the real-time delivery of multimedia content. Assuring the required QoS over a network may require additional protocols and additional bandwidth to overcome the inherent limitations of IP.

Tom Newberry is product development manager for Thomson, and Joseph Weber, Ph. D., is director of product management for TiVo.


By TOM NEWBERRY AND JOSEPH WEBER

Hallo Thomas,

Alle andere inputs, zoals mijn Chromecast en Apple TV die via de ARC hun geluid naar het surround systeem sturen hebben dit probleem niet.
Het synchronisatieprobleem doet zich ook voor wanneer ik gewoon het geluid via televisie beluister.
Ik heb op de televisie ondertussen alle bewerkingen die op het signaal zouden kunnen gebeuren uit gezet om te vermijden dat het probleem zich zou voordoen tijdens het processen van het signaal op de tv.
Mijn Blu ray speler heeft een optie waarbij ik een vertraging kan instellen. Het lijkt mij een idee om dit ook in de software van de decoder te voorzien. Dit omdat de oorzaak van het probleem duidelijk op de decoder zit.

Grtz
Peter

Peter M, het niet synchroon lopen van de audio wanneer je een surround systeem of home cinema systeem gebruikt hebben we nog al gekregen op de V6. Maar we kregen deze ook soms met de andere decoders. Dit zijn ook zaken zeer moeilijk te testen door onze ingenieurs in het labo gezien we niet al de verschillende systemen op de markt kunnen testen. 🙂 Soms ligt het ook aan het surround systeem zelf.

Globaal gezien moet dit werken. Soms is het herstarten van de surround systeem (wanneer je decoder aan blijft staan) ook een oplossing.

De test leert mij het volgende (tov de v5 remote)
1- als ik kort indruk komt er geen reactie
2- als TV-Mode + herhaaldelijk EXT indrukken gebruik scrolt die door de lijst naar beneden, maar ik moet goed opletten dat ik niet te kort en niet te lang op de EXT druk!
3- Als ik herhaaldelijk op EXT druk (zonder de TV-MODE in te drukken krijg ik net het zelfde resultaat als onder punt 2
Het nadeel is als ik met het herhaaldelijk drukken op de EXT ik door gans de lijst moet scrollen om terug een bron een stap terug te kiezen en met de pijltjes toetsen methode gaat dit natuurlijk met veel minder manipulaties.
Ik vermoed nog altijd dat er toch iets scheelt aan die v6 remote aangezien het met de v5 remote allemaal soepeler verloopt?
Martin, terwijl je de tv mode indrukt ga je in principe naar de tv menu, je selecteert de bron door telkenmale de EXT toets te gebruiken en niet met de pijltjes toch?

Janick

thomasP

ondertussen hebben onze acties elkaar doorkruist

ook bbox 3 zelf gereset en alle kabels eraf

opnieuw kabel per kabel erop

steeds probleem met v6 normaal STBox per set top box op zelfde kabel nu elk een kabel maar wel spanning af

ben nu terug op settopbox cisco want huawei v6 opnieuw slecht

stop ermee voor vandaag

Martin schreef: 2- als TV-Mode + herhaaldelijk EXT indrukken gebruik scrolt die door de lijst naar beneden, maar ik moet goed opletten dat ik niet te kort en niet te lang op de EXT druk!

Op mijn samsung tv moet ik ook stap voor stap op de EXT toets drukken om de juiste bron te selecteren, daar is toch niets mis mee.
Ik heb geen problemen met hoelang ik op die toets druk, gewoon indrukken om door de lijst te scrollen.

De usb heeft nog geen functie bij de proximus decoders dus dat gaat niet.

Beste thomas P

een klein jaar geleden werd om mij onbekende redenen aan de aansluitingen op straat gewerkt

gevolg : alleen analoge telefoon

met geluk vond ik nog de technici aan het werk en dat werd dan in orde gebracht

nu zijn wij 6 maanden straat- en rioleringswerken verder en alles ligt bijna toe en dus moet er ergens weer putjes gemaakt worden .

ik begrijp echter niet hoe cisco V5 kan werken en de nieuwe v6 bijna niet

ik kan de v6 best missen en zal binnen een veertien dagen na mijn terugkeer van dringend familie bezoek

eens een bezoekje aanvragen , tis nu toch te laat .

bedankt voor het voorstel

groet

Beste Thomas P

zoals gemeld was ik terug omgeschakeld naar de cisco V5 met soft
NTE_9244

hier was het vroeger niet mogelijk om geplande reeksen opnames te wissen.

ik had dan ook als eerste test met de V6 huawei dit getest en zag dat het goed was.
door een tweetal weken later eens om te schakelen zag ik de cisco een nieuwe versie va, programma installeren en ik dacht daarna dat ook hier et probleem was opgelost.

dit blijkt dus deze namiddag niet het geval te zijn .

ik zie hier terug de montalbanos en andere geplande opnames die ik niet meer wenste.
ik zal morgen nog eens alles wissenen ook de opnames en de geplande opnames en zien of deze vanzelf terugkomen .

nu valt mijn frank dus ook : als je en de nieuwe versie V6 en de oude cisco met V5 gebruikt op een bbbox 3 dan leidt dit zeker tot botsingen op de server want de een kent de opnames niet die de andere heeft gewist en wil deze dus terugplaatsen.

kan u mij bevestigen dat men nooit mag terugschakelen en ook de tweede Huawei V6 niet samen met
de V5 cisco gebruiken op hetzelfde netwerk ?
Hartelijk dank

Ter aanvullende info: ik heb een V5C en een nieuwe v6 op mijn lijn aangesloten, de opnames lopen synchroon op beide decoders, gelijk waar op welke decoder ik een opname wis, verdwijnt die ook in de lijst van de andere en gelijk op welke decoder ik een opname doe komt die ook in de lijst van de andere.

IrisOost, ik heb dit opgelost door middel van een wifi bridge. Deze kan je aankopen in een Proximus shop. Werkt bij mij uitstekend.

ik heb er zelf geen praktische ervaring mee, maar vraag mij af of > HDMI ARC mss een oplossing zou kunnen bieden voor je probleem

Dat is juist het probleem om dit in groepen te splitsen want hoeveel procent die een probleem hier op het forum melden gaan hier iedere keer de hardware en software versie vermelden van hun toestel waarmee ze problemen hebben je mag al content zijn dat ze bv het type reeds vermelden want de meesten melden bv ik heb dit of dat probleem met mijn bbox of dit of dat probleem met mijn decoder ........wat ook begrijpelijk is, maar op zich is dat totaal geen probleem want het is in feite proximus die moet weten over welke type software en hardware het probleem gaat om het kunnen analyseren en op te lossen en dat weten ze want iedereen die hier iets meldt daarvan kunnen ze direct natrekken wat voor type toestellen ze hebben en daarbij wet ze al heel lang dat er problemen zijn met die opnames alleen is het precies complexer dan dat wij het ons voorstellen want het zal niet alleen software zijn op de decoders die meespeelt, enfin draait en keert het zoals je wilt het is tenslotte aan Proximus en hun ondersteunende leveranciers van hard- en soft ware om het op te lossen en daar wachten wij nog altijd op als klant.