1. Welkom op het onafhankelijke Ziggo Gebruikersforum. Een forum voor en door gebruikers van Ziggo.
    Registreer je gratis om direct zelf berichten te plaatsen en gebruik te maken van extra functies!
    Verberg deze melding

Slechte signaal kwaliteit VOD oorzaak van problemen?

Discussie in 'Digitale TV - On Demand & Replay' gestart door ArChie, 13 jun 2009.

Niet open voor verdere reacties.
  1. In Ziggo/Casema en Ziggo/Multikabel gebied zijn twee Transport Streams aanwezig voor de doorgifte van de Video On Demand (VOD) content die door de klanten via de Cisco ontvanger besteld wordt. Deze VOD Transport Streams worden doorgegeven op de 130 en 138 MHz met een symbolrate van 6875 en een QAM-256 modulatie waardoor een totale bitrate van 50.6 Mbps mogelijk is per Transport Stream. Van QAM-256 is bekend dat het veel gevoeliger is voor transmissie fouten. Sinds de beide VOD Transport Streams in gebruik zijn genomen in mijn regio/wijk is de signaal kwaliteit nog nooit 100% geweest, maar bleef meestal steken op de 90%.

    Sinds men ook in Ziggo/Multikabel gebied ook VOD kan gebruiken valt mij op dat op diverse momenten van de dag de signaal kwaliteit nog van deze beide VOD Transport Streams veel lager is dan die "normale" 90% van voorheen. Bij veel metingen is de signaal kwaliteit zo'n 40% lager, en momenteel is het helemaal een drama met een 75% lagere signaal kwaliteit.

    Als ik de kwaliteit van de QAM-256 kabel Internet frequenties meet dan is die signaal kwaliteit nagenoeg 100%, dus wat veroorzaakt nu die enorme signaal kwaliteit dips hier in deze wijk? Brakke apparatuur van Ziggo? Ik heb hier ook langdurig verhoogde BER problemen gehad op alle frequenties die voor digitale TV Transport Streams gebruikt worden, maar dat is na langdurig klagen op de diverse forums weer opgelost, met uitzondering van de VOD Transport Streams blijkt nu.

    Hoe zit dat eigenlijk met de Cisco? Kan je daarmee ook de signaal sterkte en kwaliteit (en/of BER) opvragen als je naar een VOD programma zit te kijken i.p.v. een normaal TV kanaal? En zoja, laat die Cisco dan ook zien welke frequentie en instellingen er dan allemaal gebruikt worden voor de weergave van dat VOD programma?
     
  2. Het signaal is momenteel zo slecht op beide VOD Transport Streams dat er van de mogelijke 50.6 Mbps van de VOD Transport Stream op 130 MHz nog maar 5 Mbps aan data binnenkomt en van de VOD Transport Stream op 138 MHz nog maar 15 Mbps. Je zal maar een duur abonnement hebben op dit soort diensten terwijl ze niet eens in staat zijn om het signaal af te leveren.
     
  3. Tja, idd... Dat BER meten onder iTV wil ik ook weten als het al kan...

    Ik heb nml. zelf (voormalig @home) extreem blokkerig beeld / stilstaande momenten op iTV (normale digitale tv eindelijk opgelost na + 1 jaar) en heb gewoon nog helemaal niet iets kunnen kijken op geen enkel moment van de dag/week/maand. Maar goed, voor mijn geval loopt al een draadje en niet lekker ;) Ben benieuwd hoelang het nog gaat duren...
     
  4. Volgens mij zijn de QAM modulators voor VOD in mijn wijk aan het overlijden. Bij de VOD TS op 130 MHz geeft mijn DVB-C PC-TV kaart nu een kwaliteit van 0 % aan met een schamele bitrate van 1 Mbps en bij de VOD TS op 138 MHz is dat iets beter met een kwaliteit van 12 % en een bitrate van zo'n 8 Mbps. Vreemd dat er bij Ziggo/Casema weer geen alarmbellen afgaan als hun apparatuur de geest geeft. Maar ja, aan de andere kant kunnen ze ook al niet zien dat het vanuit hun headend verstuurde digitale TV signaal verstoord aankomt op het centrale punt (Alkmaar) in Ziggo/Multikabel gebied waardoor de Humax IR-FOX C regelmatig last heeft van haperingen, dus laat staan dat ze apparatuur kunnen monitoren op wijkniveau. Daarvoor zullen eerst wel weer diverse klanten van het kastje naar de muur moeten worden gestuurd door de helpdesk voordat iemand misschien eens het idee krijgt dat er misschien sprake is van een groepstoring. Een dergelijke signaleringsmethode is natuurlijk wel een probleem als je een nieuwe dienst introduceert en er is maar één klant in een wijk die gebruik maakt van die dienst. Hoe wil die klant in zijn of haar eentje ooit serieus genomen worden door de helpdesk?
     
  5. Waarom stel je dat er 50Mbps binnen moet komen ?
    Overigens wil ik niet beweren dat er niets mis zou zijn met de streams.
     
  6. Hierom:
    Code:
    │     │ │ ├─■ VOD_delivery_system_descriptor
    │     │ │ │ └─■ VOD delivery systems:
    │     │ │ │   └─■ VOD delivery system:
    │     │ │ │     ├─■ frequency = 130.0
    │     │ │ │     ├─■ FEC_outer = RS(204/188)
    │     │ │ │     ├─■ modulation = 256-QAM
    │     │ │ │     ├─■ symbol_rate = 6.875
    │     │ │ │     └─■ FEC_inner = No conv. coding
    │     │ │ ├─■ VOD_delivery_system_descriptor
    │     │ │ │ └─■ VOD delivery systems:
    │     │ │ │   └─■ VOD delivery system:
    │     │ │ │     ├─■ frequency = 138.0
    │     │ │ │     ├─■ FEC_outer = RS(204/188)
    │     │ │ │     ├─■ modulation = 256-QAM
    │     │ │ │     ├─■ symbol_rate = 6.875
    │     │ │ │     └─■ FEC_inner = No conv. coding
    
    Net als bij een normale Transport Stream of Internet downstreams worden er NULL packets met PID 0x1FFF verstuurd om de bitrate op een contante 50.6 Mbps te houden. Wanneer die signaal kwaliteit maar niet lager wordt dan 90% dan is de totale bitrate bij metingen ook gewoon nagenoeg gelijk aan die 50.6 Mbps. Maar ik hoef je toch hopelijk niet uit te leggen hoe jullie eigen systeem werkt?
     
  7. Een ander aspect is, waar ik me zorgen om maak en Ziggo m.i. in wezen geen vat op heeft, is dat al die gevallen waar de HD medewerkers volgens hun inzicht menen een probleem te hebben opgelost, geen log-entry maken. Immers hoe bestaat het anders dat je regelmatig leest dat als klanten refereren naar een eerder gesprek er niets van is te vinden.

    Juist de problemen die men wijt aan de huisinstallatie zouden hierdoor wel eens kunnen "smoren".

    Als we dit opbrengen dan zou dat allemaal keurig geregeld moeten zijn. Toch bekruipt me het gevoel dat er verschillende "werelden" binnen Ziggo bestaan.
     
  8. ik ging ervan uit dat je het over de effectieve payload had niet over de bruto bitrate.
     
  9. De CRM omgeving ondersteunt dit wel, hoewel ik niet weet of men 100% v/d calls ook altijd registreerd in deze omgeving. De calls worden ook in andere systemen gelogd waarmee call reasons worden afgeleid. Uiteraard ruimte voor verbetering, maar het is zeker niet zo dat er niets gelogd wordt.
     
  10. Gisterenavond nog een testje gedaan door mijn versterker even te "by-passen" in de coax bekabeling. Gevolg: nagenoeg geen signaal meer op de 130 MHz en 138 MHz waardoor de DVB-C PC-TV kaart en de gebruikte software geen lock meer weten te krijgen op deze twee frequenties voor de VOD Transport Streams. Alle overige frequenties voor digitale TV Transport Streams waren wel af te stemmen, dus mijn conclusie is dat een versterker bij Ziggo te zwak is of binnenkort het loodje legt. Na het terugplaatsen van mijn versterker was er weer voldoende signaal, maar met dezelfde erbarmelijke kwaliteit zodat er nog steeds nagenoeg geen data binnenkwam door alle bitfouten.

    Vanavond lijkt het wat beter te gaan. De signaal kwaliteit is nu op beide frequenties rond de 60%, wat nog steeds slecht is, maar de totale bitrate komt dan tenminste weer in de buurt van de 50.6 Mbps. Op het moment dat ik het signaal aan het controleren was met mijn DVB-C PC-TV kaart probeerde er kennelijk ook iemand in mijn wijk om VOD te gaan kijken, maar verder dan een poging is dat niet gekomen. De DVB Service Information (DVB-SI) was even kortstondig aanwezig voor de benodigde video en audio componenten en de daarbij behorende data streams, maar voordat de boel op gang zou komen was het signaal al weer verdwenen. Misschien toch een te slechte signaal kwaliteit waardoor de Cisco er ook niets van weet te maken?
     
Niet open voor verdere reacties.

Deel Deze Pagina