Digitale TV problemen bij Ziggo/Casema/Multikabel

[ArChie]

Klaus_1250 schreef op zondag 07 december 2008 @ 16:39:
InfoTV zit al een tijd niet meer op 224Mhz. Weet eigenlijk niet of ie nog op de kabel zit, gebruik zelf geen analoog. Op 1 computer zit nog een analoge kaart met Dscaler en daar heb ik een paar maanden geleden InfoTV uitgehaald (sneeuw kijken is niet interessant :-) ).

Okee, dan haal ik InfoTV uit de lijst. Ik heb zojuist nog even via de Ziggo website het analoge frequentie plan van Roosendaal opgevraagd en daar stond dat kanaal nog wel in de lijst op de 224 MHz, dus zal die informatie wel verouderd zijn.

[Klaus_1250]

Ik zag het ook staan. Maar net ff gedubbelchecked en 224Mhz levert analoog toch echt alleen ruis op.

[Klaus_1250]

Roosendaal; upstream frequentie #1: 36Mhz, #2: 44.5MHz, #4 58.2Mhz. Downstream frequenties 300 en 308Mhz lijken gereserveerd te zijn; CMTS verwijst je direct naar een andere frequentie en ze zijn ook vrijwel leeg. Eveneens heeft Ziggo 316Mhz voledig vol gezet met abbonees (97-99%) waardoor de up- en download nog niet de halve snelheden halen.
Het was trouwens interessant om te zien dat dit in twee golfen gebeurden: rond 1630 en 1700 (scholieren?) was duidelijk in mijn up- en download te zien dat er wat mis ging op het netwerk (ping tijden modem waren 100-200ms, die van de router 1-2ms).

Na de rest van de frequentie-bezetting bekeken te hebben, valt me toch op dat er ondanks 8 frequenties maar heel weinig ruimte op het netwerk is (feit dat ze hiernaast een nieuwe woonwijk aan ht neerplaten zijn zal niet helpen). Twee zijn er klaarblijkelijk niet toegankelijk (Interactieve TV?) de rest zat tussen de 60 en 97/99% vol.

De upload-kanalen kan ik helaas niet bekijken, maar #2 en #4 zitten iig beide vol. Het was me al een tijdje opgevallen dat daar iets vreemds mee was, maar door van #4 naar #2 te gaan, haal ik ineens 20-40KB/s (nog altijd beneden de 180KB/s).

Eens kijken of er ook een 3 en 5 zijn. Voor 3 en 5 is geen plek meer, de indeling verbaast me.

[ Voor 3% gewijzigd door Klaus_1250 op 08-12-2008 21:12 ]

[ArChie]

Klaus_1250 schreef op maandag 08 december 2008 @ 20:44:
Roosendaal; upstream frequentie #1: 36Mhz, #2: 44.5MHz, #4 58.2Mhz.

Hoe bepaal je de upstream frequenties? Is dat door met je kabel Internet modem gewoon andere waarden te proberen of ben je aan het experimenteren met de DVB-C PC-TV kaart. In het laatste geval: wat zijn de instellingen die gebruikt worden voor de upstream frequenties?

Downstream frequenties 300 en 308Mhz lijken gereserveerd te zijn; CMTS verwijst je direct naar een andere frequentie en ze zijn ook vrijwel leeg. Eveneens heeft Ziggo 316Mhz voledig vol gezet met abbonees (97-99%) waardoor de up- en download nog niet de halve snelheden halen.
Het was trouwens interessant om te zien dat dit in twee golfen gebeurden: rond 1630 en 1700 (scholieren?) was duidelijk in mijn up- en download te zien dat er wat mis ging op het netwerk (ping tijden modem waren 100-200ms, die van de router 1-2ms).

Toen je gisteren met de opmerking kwam dat er twee frequenties bij waren gekomen heb ik ook nog even gescand hier in Ziggo/Multikabel gebied. Hoewel ik geen nieuwe kabel Internet frequenties heb aangetroffen viel mij het hier ook op dat de verdeling van abonnees over de beschikbare frequenties niet erg gunstig was. Een tweetal frequenties die voor meer dan 80% in gebruik waren terwijl er ook nog frequenties waren met een belasting van hooguit 10%.

[Klaus_1250]

ArChie schreef op maandag 08 december 2008 @ 21:36:
[...]

Hoe bepaal je de upstream frequenties? Is dat door met je kabel Internet modem gewoon andere waarden te proberen of ben je aan het experimenteren met de DVB-C PC-TV kaart. In het laatste geval: wat zijn de instellingen die gebruikt worden voor de upstream frequenties?

Voorlopig het eerste. Als ik wat meer tijd heb zou het laatste eens kunnen proberen, aangezien de Twinhan tot 51Mhz gaat en QAM16 pakt.

Overigens, kleine toevoeging op mijn post hierboven. Upstream kanalen 1, 2 en 4 zijn Docsis 1.1 (QAM16). Ik gok erop dat #3 Docsis 2.0 is in QAM64, alleen niet 8Mhz breed. Ik kan me eigenlijk niet voorstellen dat er geen Docsis 2 upstreams zijn, maar dat verklaard wel weer het upstream bandbreedte-tekort (vandaag 50KB/s max tijdens de piekuren, nu weer 180KB/s).
Heb hier een SB5120 liggen, maar die komt niet op het netwerk. Ziggo heeft de Alles-in-1 aanvraag verprutst (telefonie-gedeelte vergeten) en krijg ze niet binnen een fatsoenlijke tijd (<15min) aan de lijn.

Toen je gisteren met de opmerking kwam dat er twee frequenties bij waren gekomen heb ik ook nog even gescand hier in Ziggo/Multikabel gebied. Hoewel ik geen nieuwe kabel Internet frequenties heb aangetroffen viel mij het hier ook op dat de verdeling van abonnees over de beschikbare frequenties niet erg gunstig was. Een tweetal frequenties die voor meer dan 80% in gebruik waren terwijl er ook nog frequenties waren met een belasting van hooguit 10%.

Ik gok erop dat ze die kanalen voor premium users gebruiken, e.g. Z3i en/of VoD. Voor dat laatste moeten ze genoeg bandbreedte op een kanaal hebben, dus ik gok erop dat er minstens 1 of 2 kanlen daarvoor exclusief houden. Dat mensen hun download-snelheden niet halen is 1 ding, maar dat je betaald voor een film en blokjes ziet gaat natuurlijk niet.

[ArChie]

ArChie schreef op zaterdag 06 december 2008 @ 22:10:
Het is weer zover, vanavond weer om de 20 seconden haperingen op Comedy Central. Ze zullen wel weer aan het klooien zijn met de timing van de Entitlement Control Message (ECM) bij Ziggo/Casema.

En zoals gewoonlijk blijft het geklooi bij Ziggo/Casema maar aanhouden. Niet alleen Comedy Central vertoont dit gehaper, maar ook WDR. De andere kanalen van Transport Stream 7 behoren niet tot mijn pakket, maar het zal mij niets verbazen als die ook van die haperingen vertonen:

code:

Motors TV 
Nick/Comedy Central
WDR
Garuda TV 
Holland DOC
Arrow Classic Rock
BNR Nieuws Radio
Classic FM
Funx
Slam! FM
Q-Music
Radio 1
Radio 2 
Radio 3
Radio 4 
Radio France Inter.
Radio Rembrandt

Een sleutel of een aanleveringsprobleem van het signaal van Ziggo/Casema naar (delen van) het Ziggo/Multikabel gebied. Op het Ziggo gebruikers forum lees ik dat iemand uit Heerhugowaard hetzelfde probleem ervaart met WDR als ik in Oosthuizen. Hoeveel weken moet dit gelazer deze keer weer gaan duren totdat Ziggo/Casema dit oplost?

[Klaus_1250]

Welke oplossing gebruik je precies om Digitaal te kijken?

[ArChie]

Klaus_1250 schreef op dinsdag 09 december 2008 @ 19:29:
Welke oplossing gebruik je precies om Digitaal te kijken?

Humax IR-FOX

[Elsido]

Klaus_1250 schreef op donderdag 04 december 2008 @ 18:20:
Jammer dat er nog altijd niks over de analoge kwaliteit staat.

Verder mag je niets doen aan de groene kabel. AOP mag je wel aan zitten, moet je ook vervangen bij doe-het-zelf verhuispakketten e.d. De groene kabel is vooral heilig.

Allen bij Telefonie was dat destijds anders, waarbij het AOP nog wel eens verzegeld was. Maar dat is ook al niet meer zo.

Niet waar het AOP is eigendom van Ziggo en mag jezelf geen aanpassingen aan doen. Indien je storing krijgt en de monteur constateert dat het een verkeerd AOP is wat niet door ziggo is aangesloten zijn alle kosten voor jouw. Dit staat allemaal in de algemene voorwaarden van ziggo.

artikel 8 – Aansluiting

1. Ziggo voert de werkzaamheden uit en treft de voorzieningen die nodig zijn voor het aanleggen, controleren, onderhouden, herstellen, wijzigen en opruimen van de Aansluiting en de aan de Klant ter beschikking gestelde apparatuur. Zij houdt daarbij zoveel mogelijk rekening met de belangen van de Klant. Ziggo verricht geen onderhoud of reparaties en biedt geen ondersteuning aan apparatuur die zij niet aan de Klant ter beschikking heeft gesteld.

2. Als voor de aanleg van een Aansluiting, al dan niet op verzoek van de Klant, bijzondere voorzieningen worden getroffen of daaraan buitengewone kosten zijn verbonden, dan kan Ziggo deze kosten bij de Klant in rekening brengen. Ziggo informeert de Klant vooraf over de hoogte van deze kosten. De Aansluiting wordt niet aangelegd voordat de Klant heeft ingestemd met de betaling van de kosten.

3. De Klant verleent gelegitimeerd personeel van Ziggo vrije toegang tot de Aansluiting en de ter beschikking gestelde apparatuur. Als hiervoor toestemming of medewerking van een derde nodig is, zorgt de Klant voor die toestemming of medewerking. De Klant vrijwaart Ziggo voor vorderingen van derden in dit verband.

4. Alleen Ziggo en door haar ingeschakelde derden zijn bevoegd werkzaamheden te (laten) verrichten of veranderingen te (laten) aanbrengen aan de Aansluiting, het Netwerk en eventuele door Ziggo aan de Klant ter beschikking gestelde apparatuur.

5. De Klant handhaaft de Aansluiting in goede staat, ook na beëindiging van het Abonnement.

[Klaus_1250]

Elsido schreef op dinsdag 09 december 2008 @ 19:40:
Niet waar het AOP is eigendom van Ziggo en mag jezelf geen aanpassingen aan doen.

Hoe moet je dan als klant de TRAS vervangen als je een verhuiskit opgestuurd krijgt? En als de helpdesk erop staat dat je iets aansluit op de groene kabel (die wel eens ver achter de TRAS kan zitten als de kabel in de meterkast binnenkomt en de huisaansluiting in de woonkamer zit).

Tis leuk dat het in de voorwaarden staat maar de praktijk is anders.

[ArChie]

Bij de Cisco leveren ze tegenwoordig ook een TRAS + versterker mee die de klant in principe zelf moet monteren. Deze Interactieve TV kit leveren ze immers ook via bijvoorbeeld de Mediamarkt waar de monteur er niet standaard bijgeleverd wordt. Zoals gewoonlijk is Ziggo voornamelijk bezig zichzelf in te dekken met dit soort voorwaarden voor het geval er wel iets misgaat als de klant zelf de TRAS vervangt. Losse kits leveren aan klanten maar wel de verantwoording afschuiven.

[Elsido]

Klaus_1250 schreef op dinsdag 09 december 2008 @ 19:49:
[...]


Hoe moet je dan als klant de TRAS vervangen als je een verhuiskit opgestuurd krijgt? En als de helpdesk erop staat dat je iets aansluit op de groene kabel (die wel eens achter de TRAS kan zitten als de kabel in de meterkast binnenkomt en de huisaansluiting in de woonkamer zit).

Tis leuk dat het in de voorwaarden staat maar de praktijk is anders.

Dat is inderdaad een goeie . Maar je zult zien dat ze je op dat soort dingen altijd zullen pakken als ut er op aan komt. Wat ik nog weet van het oud-multikabel gebied is dat als er een AOP vervangen of aangesloten moest worden dit altijd door multikabel of een bevoegde derden werd gedaan op afspraak. Maar ja blijkbaar is dat nog niet helemaal eenduidig in de voorwaarden en de praktijk.

[Klaus_1250]

Bij @home is dat was dat al jaren niet meer zo. Waarschijnlijk om de kosten te drukken aangezien het in veel gevallen ook door de klant kan worden gedaan. Als men netjes werkt en goed kijkt wat men moet doen, is het in 90% van de gevallen goed zelf te doen. Persoonlijk sluit ik dingen sowieso liever zelf aan, dan weet je tenminste hoe en wat.

Bij KPN was het ISRA punt ook ooit heilig, maar als je in zo'n ding openmaakt en kijkt, kun je je afvragen waaron, buiten wat meer kabeltjes.

Humax IR-FOX

OK, das vreemd. Misschien heeft het er ook mee te maken dat ze het basispakket hebben opengezet voor alle kaarten. PVR's vielen daar ook over.

[ Voor 14% gewijzigd door Klaus_1250 op 09-12-2008 20:16 ]

[Anoniem: 261170]

Heb je digitale tv van Ziggo?
Gebruik je 2 smartcards vanwege 2 decoders of een HTPC met 2 dig. ontvangers?

Goed nieuws. Vanaf 1 januari krijg je ook op de 2de smartcard je extra pakketten gratis!! Ik heb zelf vandaag met Ziggo gebeld hierover en ik kreeg dit te horen.
Vanaf 1 jan kun je bellen met de helpdesk van ziggo en wordt het kosteloos geactiveerd.

Op dit moment is dat dus niet het geval. Een 2de smartcard is, inmiddels, gratis. Maar daar krijg je alleen het standaardpakket met digitale zenders op. Voor de extra pakketten op de 2de kaart moet je weer extra abonnementsgeld betalen. Eigenlijk absurd natuurlijk. Zo bepaalt Ziggo in welk deel van het huis je welke zenders mag kijken. Maar gelukkig is dat vanaf 1 januari dus verleden tijd!

[ Voor 6% gewijzigd door Anoniem: 261170 op 09-12-2008 20:15 ]

[ArChie]

Klaus_1250 schreef op dinsdag 09 december 2008 @ 20:09:
OK, das vreemd. Misschien heeft het er ook mee te maken dat ze het basispakket hebben opengezet voor alle kaarten. PVR's vielen daar ook over.

Nee, dit heeft niets te maken met het "openzetten" van het basis basis pakket. Het komt alleen voor op de kanalen in Transport Stream 7, de andere kanalen van het basispakket in andere Transport Streams hebben deze storing niet. Dit soort geneuzel hebben we hier al vaker gehad met dat gehaper van de kanalen in een TS. Gaat weer weken duren voordat het is opgelost en dan is er weer een tijd niets aan de hand. Helaas is Ziggo/Casema kennelijk niet in staat om het signaal te monitoren dat ze leveren in het Ziggo/Multikabel gebied. Sinds de overname van het signaal alhier door Ziggo/Casema gaat het om de haverklap mis wat elke keer weer weken van ergernis oplevert totdat het probleem wordt erkend/opgelost.

[ Voor 4% gewijzigd door ArChie op 09-12-2008 20:44 ]

[The_Doman]

ArChie schreef op dinsdag 09 december 2008 @ 18:50:
En zoals gewoonlijk blijft het geklooi bij Ziggo/Casema maar aanhouden. Niet alleen Comedy Central vertoont dit gehaper, maar ook WDR. De andere kanalen van Transport Stream 7 behoren niet tot mijn pakket, maar het zal mij niets verbazen als die ook van die haperingen vertonen:

Hier (Den Helder) op de genoemde zenders geen problemen gemerkt met mijn Siemens M750 PVR.

[ArChie]

The_Doman schreef op dinsdag 09 december 2008 @ 21:18:
Hier (Den Helder) op de genoemde zenders geen problemen gemerkt met mijn Siemens M750 PVR.

Dat is op zich niet vreemd. Bij de overgang van het signaal van Ziggo/Multikabel naar Ziggo/Casema was de regio waar Den Helder deel van uitmaakt volgens mij ook niet gelijk aan de beurt met de regio waar Oosthuizen onder valt. Het geeft wel aan dat het vermoedelijk geen sleutel probleem is, maar een signaal leveringsprobleem naar mijn regio.

[ArChie]

Nog een melding op het Ziggo gebruikers forum van iemand uit Hoofddorp in het Ziggo/Multikabel gebied die dit haperingsprobleem heeft met alle kanalen uit Transport Stream 7 op de 514 MHz. Volgens zijn profiel heeft hij zowel een Samsung DCB-9401R als een Humax IR-FOX C. Helaas heeft deze persoon niet aangegeven op welke van zijn ontvangers dit optreed.

The_Doman schreef op dinsdag 09 december 2008 @ 21:18:
Hier (Den Helder) op de genoemde zenders geen problemen gemerkt met mijn Siemens M750 PVR.

Zou jij eens willen testen of je dit haperingsprobleem misschien wel hebt met je Humax IR-FOX C op de kanalen uit Transport Stream 7?

[Fantomaz]

Dat de klanten zélf de WCD in de woning moesten gaan vervangen voor de TRAS1000 is voer geweest voor zeer verhitte discussies bij @home (en Essent daarvoor) destijds!

Je gooit wél je overgang van verantwoordelijkheid overboord.
Maar "thenagain" Waar ligt de verantwoordelijkheid wanneer de klant een ETU heeft?
De klant mag dan ook niet meer aan het kabeltje in de TRAS komen en is de uitgang RTV aan de voorzijde het Abonnee Overname Punt, als je het letterlijk neemt.

Het is voor ons het punt tot hoever wij gaan met onze service. Strikt genomen, wel te verstaan.
Uit service oogpunt meet ik wel meer dan alleen aan het AOP. Ik wil ook nog wel eens verder kijken om de klant te helpen...
Maar ik zal dan niets vervangen. Want het is onze verantwoording niet meer.
Daar staat echter tegenover dat wanneer de klant een decoder heeft van Ziggo, en die werkt niet achter het blikken bakje dat voor een WCD moet doorgaan... Moet ik die dan vervangen om de klant zijn product te kunnen laten gebruiken?
In princiepe niet, lijkt mij.

Maar dan de routers en draadloze netwerken van de klant...
Als de klant "onze" router en Wireless stick gebruikt, moeten wij daaraan service bieden, wanneer er problemen zijn daarmee. Tóch moet je dan rommelen aan de PC van de klant, die vaak verre van een "clean installed" besturingssysteem is.

Waar houdt wiens verantwoordelijkheid op en waar begint de ander zijn verantwoordelijkheid? Niet altijd vrij van grijze gebieden.

[The_Doman]

ArChie schreef op woensdag 10 december 2008 @ 17:56:
Zou jij eens willen testen of je dit haperingsprobleem misschien wel hebt met je Humax IR-FOX C op de kanalen uit Transport Stream 7?

Ik heb momenteel even geen Humax tot mijn beschikking, wel lees ik op het Ziggo forum dat het haperen van o.a WDR in onderzoek is:
WDR "hapert", meer mensen last van?

Sinds een paar dagen merk ik hier trouwens wel een probleem bij Eurosport HD op mijn PC?
Het lijkt erop dat er bij deze zender af en toe een korte onderbreking in de TS zit met als gevolg stilstaande/haperende beelden doordat de codec (ProgDVB/Cyberlink H264/Purevideo) hierdoor ontregeld raakt.
Hebben meer mensen hier misschien last van?

[ArChie]

The_Doman schreef op donderdag 11 december 2008 @ 22:15:
Ik heb momenteel even geen Humax tot mijn beschikking, wel lees ik op het Ziggo forum dat het haperen van o.a WDR in onderzoek is:
WDR "hapert", meer mensen last van?

Jammer dat je even geen Humax hebt, want anders hadden we kunnen onderzoeken of het probleem afhangt van de gebruikte kabel ontvanger. Ziggo/Casema kennende zijn ze rustig in staat om met een Samsung of Cisco te gaan testen in de probleem gebieden en dan te roepen dat er niets aan de hand is terwijl dit gedrag vermoedelijk alleen tot uitting komt met een Humax IR-FOX. Ook is de kans groot dat als het alleen optreed met een Humax IR-FOX dat Ziggo/Casema weer gaat roepen dat het aan deze ontvanger ligt en niet aan hun signaal. Ziggo/Casema is volgens mij namelijk niet in staat om hun eigen signaal in Ziggo/Multikabel gebied goed te monitoren/onderzoeken anders had er allang een storingsmelding op hun website moeten staan.

Mijn verwachting is dat dit nog weken gaat duren ondanks dat een Ziggo/@Home medewerker op het gebruikers forum zegt dat het in onderzoek is. Ik lees veel meer klachten over haperingen in de weergave van het digitale TV signaal met de Humax IR-FOX in Ziggo/Casema en Ziggo/Multikabel gebied. En wat doet deze Ziggo/@Home medewerker? Hij gaat met een Samsung DCB-9401R kijken in Ziggo/@Home gebied of hij het ook ziet. Daar heb je wat aan.

[The_Doman]

ArChie schreef op vrijdag 12 december 2008 @ 09:52:
[...]
Jammer dat je even geen Humax hebt, want anders hadden we kunnen onderzoeken of het probleem afhangt van de gebruikte kabel ontvanger.

Vandaag dan ook maar even met een Humax IR FOX bij een familielid getest.
Inderdaad geven de genoemde zenders regelmatig een freeze op de Humax, met mijn Siemens M750 PVR zijn er geen zichtbare problemen te zien bij deze zenders.
Blijkbaar dan toch ook weer een specifiek Humax probleem.

[AleSyS]

Ondervinden meer mensen momenteel problemen met digitale tv van ziggo. Sinds vanmiddag heb ik op alle kanalen storing....allemaal blokjes e.d. Ben in het bezit van een samsung HD decoder. Heb al een reset uitgevoerd en kanalen opnieuw laten zoeken. Dit zonder resultaat. Ook bekabeling opnieuw aangesloten. Geen resultaat. Ik zit in postcode 2351CT (Leiderdorp)

[ArChie]

The_Doman schreef op vrijdag 12 december 2008 @ 14:47:
Vandaag dan ook maar even met een Humax IR FOX bij een familielid getest.
Inderdaad geven de genoemde zenders regelmatig een freeze op de Humax, met mijn Siemens M750 PVR zijn er geen zichtbare problemen te zien bij deze zenders.

Mijn dank is groot.

Blijkbaar dan toch ook weer een specifiek Humax probleem.

Ik wil het iets anders verwoorden als je het niet erg vindt: Het is een probleem in het signaal van Ziggo/Casema dat zich kennelijk alleen via de Humax IR-FOX C openbaart. De Humax IR-FOX C had immers eerder geen problemen met de kanalen in Transport Stream 7 en er is niets aan deze ontvanger gewijzigd sinds lange tijd, terwijl er regelmatig wijzigingen plaatsvinden aan het signaal van Ziggo/Casema. Weer zo'n voorbeeld van een door Ziggo "gecertificeerde" ontvanger die niet lekker wil samenwerken met het door hun geproduceerde signaal. Aan die "certificatie" heb je dus ook niets.

[Klaus_1250]

Aan die "certificatie" heb je dus ook niets.

Certificatie heeft niks met het belang voor de consument te maken. Tis eerder een extra inkomstenbron voor Ziggo, tis makkelijker voor hun om zaken op hun manier aan te passen zonder lastige standaarden in acht te nemen en een manier om klanten te binden cq. te locken. Met de Humax zijn, ondanks dat het an sich geen slecht kastje is, al sinds het begin vreemde problemen geweest en Ziggo (daarvoor @home) heeft nooit echt zin gehad om er wat aan te doen.

[ Voor 22% gewijzigd door Klaus_1250 op 12-12-2008 15:32 ]

[The_Doman]

Klaus_1250 schreef op vrijdag 12 december 2008 @ 15:30:
Met de Humax zijn, ondanks dat het an sich geen slecht kastje is, al sinds het begin vreemde problemen geweest en Ziggo (daarvoor @home) heeft nooit echt zin gehad om er wat aan te doen.

Inderdaad, ondanks dat de ergste bugs er nu wel uit zijn (zoals het regelmatig totaal vastlopen) heeft de Humax Fox toch nog vaak last van willekeurige, kortstondige freezes.
Sinds ik mijn Siemens decoders gebruik inplaats van de Humax heb ik daar nu helemaal geen last meer van.

[ArChie]

Klaus_1250 schreef op vrijdag 12 december 2008 @ 15:30:
Certificatie heeft niks met het belang voor de consument te maken.

Ik zet de term "certificatie" niet voor niets tussen aanhalingstekens. Het is weer zo'n typische flauwekul term van Ziggo wat wel gewichtig en officieel klinkt, maar waar je in de praktijk als consument helemaal niets aan hebt. Als je er om vraagt, dan kunnen ze bij Ziggo waarschijnlijk helemaal geen certificaat tonen dat zou zijn afgegeven na het testen van een kabel ontvanger, laat staan dat ze de certificeringseisen kunnen ophoesten. Als er al iets gecertificeerd wordt dan is dat door Irdeto die controleert of de beveiliging juist is toegepast door de fabrikant. Zo'n eventuele Irdeto certificering is dus meer een garantie voor het kabelbedrijf dat de ontvanger goed dichtgetimmerd is zodat Ziggo alle controle heeft over het door ons gekochte apparaat, dan dat de consumenten er wat aan hebben. Er is tot op heden immers nog geen enkele aanbevolen ontvanger uitgekomen die niet direct al een firmware update nodig had om allerlei problemen te fixen.

En na die eerste firmware fix heeft de fabrikant door de lage marges meestal al geen zin meer om nog meer geld en tijd te spenderen aan de ontvanger. Alles wat ze niet opgelost hadden blijft dan maar zo met als gevolg ergernis bij de klanten die er terecht van uit gingen dat een "gecertificeerde" ontvanger een probleemloze ontvanger zou zijn want die zijn toch na "zware certificeringstesten" door Ziggo goed bevonden?

Vanaf het begin is er bijvoorbeeld al aangegeven dat de Humax IR-FOX C niet op tijd loopt. Twee firmware fixen verder voor dit apparaat en nog steeds is het niet verholpen. Dan heb je op het gebruikers forum zo'n helpdeskmedewerker die dan rustig durft te beweren dat het niet bekend was. Volgende keer beter. De Siemens M750C is ook een "gecertificeerde" ontvanger, maar dat apparaat heeft nog nooit goed gefunctioneerd. Via de Ziggo "helpdesk" zijn ze nu al bezig om aan te geven dat Ziggo geen support meer gaat leveren op dit apparaat. Lekker zo'n gecertificeerde ontvanger... De Samsung DCB-9401R is er voor verantwoordelijk dat wij bij Ziggo/Casema maar twee dagen EPG informatie krijgen want anders valt die "gecertificeerde" ontvanger om. Een helpdeskmedewerker loopt al meer dan een jaar te verkondigen dat er een firmware update gaat komen, maar ondertussen mag Samsung de ene na de andere nieuwe ontvanger uitbrengen zonder dat Ziggo nu eens op zijn strepen gaat staan en voor hun klanten eist dat eerst die firmware update uitkomt voordat er nieuwe ontvangers gemaakt mogen worden. "Certificering" betekent dus ook niet dat je als klant kan rekenen op de steun van Ziggo als duidelijk is dat de "gecertificeerde" ontvangers problemen opleveren. Moeten we het nog over de Panasonic ontvanger hebben, of de Philips en Digi1 ontvangers met al hun hardwarematige gebreken? De bouw kwaliteit van de Samsungs?

Met de Humax zijn, ondanks dat het an sich geen slecht kastje is, al sinds het begin vreemde problemen geweest en Ziggo (daarvoor @home) heeft nooit echt zin gehad om er wat aan te doen.

Ik weet niet hoe het bij Ziggo/@Home bijvoorbeeld gesteld is met het weergeven van de Present/Following EPG informatie door de Humax IR-FOX C, maar bij Ziggo/Multikabel is dat de laatste tijd ook waardeloos. Veelal weet de Humax IR-FOX C tegenwoordig namelijk niet meer tijdens het zappen op tijd het huidige programma te tonen in de informatie box onder aan het scherm. Het zal wel weer iets met de update timing van de Present/Following EPG informatie bij Ziggo/Casema te maken hebben waardoor de Humax de informatie net te laat ontvangt en dus niet tijdens het zappen kan weergeven. Vroeger werkte dat prima en kon je dus gewoon op de programma info zappen. Het zal mij niets verbazen als Ziggo/Casema hier aan heeft zitten rommelen om de timing beter te krijgen voor "hun" Cisco 8455DVB PVR.

Sowieso gaat de aandacht van Ziggo/Casema tegenwoordig volledig uit naar de Cisco 8455DVB PVR aangezien ze daar via een OpenTV toepassing wel meer dan 2 dagen EPG informatie bieden. Natuurlijk is zo'n OpenTV toepassing voor EPG interessanter dan normale EPG aangezien ze daar in de toekomst een apart abonnement aan kunnen hangen wat met normale EPG niet gaat. Het zal Ziggo/Casema dan ook worst zijn of de normale EPG goed werkt, volledig is en up-to-date is. Als die normale EPG maar slecht genoeg is dan stappen de klanten vanzelf over op hun Cisco 8455DVB PVR. Op ontwikkelingen als Sony's TVTV EPG of XML protocollen als EPG bron zitten ze uiteraard niet te wachten omdat de klanten dan van derde partijen de EPG kunnen betrekken. Handig als je dan zelf tijdens het "certificeren" kan eisen dat de ontvangers helemaal dichtgetimmerd moeten worden en IP poorten op de nieuwe generaties ontvangers kan laten uitschakelen.

[The_Doman]

The_Doman schreef op donderdag 11 december 2008 @ 22:15:Sinds een paar dagen merk ik hier trouwens wel een probleem bij Eurosport HD op mijn PC?
Het lijkt erop dat er bij deze zender af en toe een korte onderbreking in de TS zit met als gevolg stilstaande/haperende beelden doordat de codec (ProgDVB/Cyberlink H264/Purevideo) hierdoor ontregeld raakt.
Hebben meer mensen hier misschien last van?

Blijkbaar ben ik dus niet de enige die problemen heeft met de Eurosport HD zender lees ik:

Ziggo-Gebruikers.nl - Vraag: Eurosport HD valt vaak weg...

[ArChie]

The_Doman schreef op zondag 14 december 2008 @ 13:32:
Blijkbaar ben ik dus niet de enige die problemen heeft met de Eurosport HD zender lees ik:

Ziggo-Gebruikers.nl - Vraag: Eurosport HD valt vaak weg...

Ik las het. Om de hoeveel tijd treed dat probleem op? Ik heb afgelopen week na jouw melding een Transport Stream capture file gemaak van de TS waar Eurosport HD in zit, maar daar werd door de door mij gebruikte tools geen afwijking in aangetroffen. Nu was dit een capture file van 200 MB wat overeenkomt met 44 seconden een Transport Stream volledig opslaan, dus ik kan de onderbreking gemist hebben. Bij alle TS capture files die ik tot nu toe van het 514 MHz probleem gemaakt heb blijkt dat er in elke capture file van 44 seconden wel een onderbreking van het signaal is waar te nemen wat overeenkomt met de regelmaat waarin de haperingen optreden met de kanalen die op die 514 MHz frequentie worden doorgegeven.

Het is ondertussen via forums wel bekend dat er in het oud Multikabel gebied waarschijnlijk capaciteits problemen zijn met de glasvezel backbone van Ziggo en ook de Transport Streams voor digitale TV worden via glasvezel vanuit de Ziggo/Casema headend naar de wijkcentra getransporteerd om daar met QAM modulatoren op de kabel te worden gezet. Wie zegt mij dat we hier niet naar het zelfde probleem zitten te kijken? Als dat zo is, dan kan het wel eens een lange tijd gaan duren totdat deze problemen zijn opgelost, want hoelang hebben de ex-Multikabel kabel Internet klanten nu al problemen met hun verbindingen in bepaalde gebieden.

[The_Doman]

ArChie schreef op zondag 14 december 2008 @ 13:44:
[...]
Ik las het. Om de hoeveel tijd treed dat probleem op? Ik heb afgelopen week na jouw melding een Transport Stream capture file gemaak van de TS waar Eurosport HD in zit, maar daar werd door de door mij gebruikte tools geen afwijking in aangetroffen.

Er zit geen regelmaat in, soms is er een paar uur geen merkbaar probleem maar op andere momenten krijg ik freezes om de 5~10 minuten bijvoorbeeld.

[Davidshadow13]

ArChie schreef op vrijdag 12 december 2008 @ 16:24:
[...]

Ik zet de term "certificatie" niet voor niets tussen aanhalingstekens. Het is weer zo'n typische flauwekul term van Ziggo wat wel gewichtig en officieel klinkt, maar waar je in de praktijk als consument helemaal niets aan hebt. Als je er om vraagt, dan kunnen ze bij Ziggo waarschijnlijk helemaal geen certificaat tonen dat zou zijn afgegeven na het testen van een kabel ontvanger, laat staan dat ze de certificeringseisen kunnen ophoesten. Als er al iets gecertificeerd wordt dan is dat door Irdeto die controleert of de beveiliging juist is toegepast door de fabrikant. Zo'n eventuele Irdeto certificering is dus meer een garantie voor het kabelbedrijf dat de ontvanger goed dichtgetimmerd is zodat Ziggo alle controle heeft over het door ons gekochte apparaat, dan dat de consumenten er wat aan hebben. Er is tot op heden immers nog geen enkele aanbevolen ontvanger uitgekomen die niet direct al een firmware update nodig had om allerlei problemen te fixen.

En na die eerste firmware fix heeft de fabrikant door de lage marges meestal al geen zin meer om nog meer geld en tijd te spenderen aan de ontvanger. Alles wat ze niet opgelost hadden blijft dan maar zo met als gevolg ergernis bij de klanten die er terecht van uit gingen dat een "gecertificeerde" ontvanger een probleemloze ontvanger zou zijn want die zijn toch na "zware certificeringstesten" door Ziggo goed bevonden?

Vanaf het begin is er bijvoorbeeld al aangegeven dat de Humax IR-FOX C niet op tijd loopt. Twee firmware fixen verder voor dit apparaat en nog steeds is het niet verholpen. Dan heb je op het gebruikers forum zo'n helpdeskmedewerker die dan rustig durft te beweren dat het niet bekend was. Volgende keer beter. De Siemens M750C is ook een "gecertificeerde" ontvanger, maar dat apparaat heeft nog nooit goed gefunctioneerd. Via de Ziggo "helpdesk" zijn ze nu al bezig om aan te geven dat Ziggo geen support meer gaat leveren op dit apparaat. Lekker zo'n gecertificeerde ontvanger... De Samsung DCB-9401R is er voor verantwoordelijk dat wij bij Ziggo/Casema maar twee dagen EPG informatie krijgen want anders valt die "gecertificeerde" ontvanger om. Een helpdeskmedewerker loopt al meer dan een jaar te verkondigen dat er een firmware update gaat komen, maar ondertussen mag Samsung de ene na de andere nieuwe ontvanger uitbrengen zonder dat Ziggo nu eens op zijn strepen gaat staan en voor hun klanten eist dat eerst die firmware update uitkomt voordat er nieuwe ontvangers gemaakt mogen worden. "Certificering" betekent dus ook niet dat je als klant kan rekenen op de steun van Ziggo als duidelijk is dat de "gecertificeerde" ontvangers problemen opleveren. Moeten we het nog over de Panasonic ontvanger hebben, of de Philips en Digi1 ontvangers met al hun hardwarematige gebreken? De bouw kwaliteit van de Samsungs?


[...]

Ik weet niet hoe het bij Ziggo/@Home bijvoorbeeld gesteld is met het weergeven van de Present/Following EPG informatie door de Humax IR-FOX C, maar bij Ziggo/Multikabel is dat de laatste tijd ook waardeloos. Veelal weet de Humax IR-FOX C tegenwoordig namelijk niet meer tijdens het zappen op tijd het huidige programma te tonen in de informatie box onder aan het scherm. Het zal wel weer iets met de update timing van de Present/Following EPG informatie bij Ziggo/Casema te maken hebben waardoor de Humax de informatie net te laat ontvangt en dus niet tijdens het zappen kan weergeven. Vroeger werkte dat prima en kon je dus gewoon op de programma info zappen. Het zal mij niets verbazen als Ziggo/Casema hier aan heeft zitten rommelen om de timing beter te krijgen voor "hun" Cisco 8455DVB PVR.

Sowieso gaat de aandacht van Ziggo/Casema tegenwoordig volledig uit naar de Cisco 8455DVB PVR aangezien ze daar via een OpenTV toepassing wel meer dan 2 dagen EPG informatie bieden. Natuurlijk is zo'n OpenTV toepassing voor EPG interessanter dan normale EPG aangezien ze daar in de toekomst een apart abonnement aan kunnen hangen wat met normale EPG niet gaat. Het zal Ziggo/Casema dan ook worst zijn of de normale EPG goed werkt, volledig is en up-to-date is. Als die normale EPG maar slecht genoeg is dan stappen de klanten vanzelf over op hun Cisco 8455DVB PVR. Op ontwikkelingen als Sony's TVTV EPG of XML protocollen als EPG bron zitten ze uiteraard niet te wachten omdat de klanten dan van derde partijen de EPG kunnen betrekken. Handig als je dan zelf tijdens het "certificeren" kan eisen dat de ontvangers helemaal dichtgetimmerd moeten worden en IP poorten op de nieuwe generaties ontvangers kan laten uitschakelen.

toon volledige bericht

Dus volgens jouw zijn alle DVB-C ontvangers die nu op de markt zijn brak?

Ik moet zeggen dat idd die certificering gewoon totale bull is. Verder is het met Multikabel alleen maar bergafwaarts gegaan sinds het is overgenomen door Ziggo.

Verder ben ik van mening dat Humax de enige fabrikant is die nog een beetje degelijke decoders maakt zeker met de IR-HD5000. Want ik heb met de Samsung, en Philips decoders alleen nog maar problemen gehad. En ja ook ik heb maar 2 dagen EPG minder zelfs. Maar ik ben van mening dat je dan beter gwn een tv gidsie kunt kopen voor 45 cent per week. Heb je ook dat gezeur niet

[ArChie]

The_Doman schreef op zondag 14 december 2008 @ 13:56:
Er zit geen regelmaat in, soms is er een paar uur geen merkbaar probleem maar op andere momenten krijg ik freezes om de 5~10 minuten bijvoorbeeld.

Tja, dan wordt het dus puur toeval wil ik een TS capture file kunnen maken waarin net zo'n freeze voorkomt. Dus dat kan ik wel vergeten. Nu zitten er trouwens verder niet veel bekeken kanalen in Transport Stream 25 afgezien van Eurosport HD, dus zou het best zo kunnen zijn dat die freezes zich ook voordoen op de andere kanalen maar dat niet veel mensen dit zien (laat staat dat die personen toevallig ook nog op de forums komen). Met het onregelmatig optreden heeft het ook geen zin om als het optreed tijdens het kijken naar Eurosport HD even snel naar de andere kanalen van Transport Stream 25 te zappen om te zien of het daar ook optreed. Weinig houvast en tot dusver volgens mij alleen nog maar meldingen uit Ziggo/Multikabel en Ziggo/Casema gebied dus heb ik weinig hoop dat Ziggo/Casema dit op korte termijn zal gaan oplossen. Ze hebben het momenteel even te druk met hun eigen Cisco 8455DVB ontvanger moet je maar denken.

[ArChie]

Davidshadow13 schreef op zondag 14 december 2008 @ 14:02:
Dus volgens jouw zijn alle DVB-C ontvangers die nu op de markt zijn brak?

Wat ik aangeef is dat Ziggo met de term "certificatie" bepaalde verwachtingen wekt bij hun klanten die ze in de praktijk niet waarmaken gezien de problemen met alle ontvangers die ze tot nu toe "gecertificeerd" hebben. Met elke ontvanger bleek na introductie al snel dat er wat aan mankeerde waarvoor snel een firmware update noodzakelijk was en dat waren in veel gevallen problemen die met een beetje serieus testen toch wel aan het licht hadden moeten komen voordat die ontvangers via de winkels werden aangeboden.

Ik moet zeggen dat idd die certificering gewoon totale bull is. Verder is het met Multikabel alleen maar bergafwaarts gegaan sinds het is overgenomen door Ziggo.

Ik maak hier uit op dat je net als ik ook in Ziggo/Multikabel gebied woont. Misschien is je bekend dat destijds bij introductie van de Samsung DCB-P850R PVR deze ontvanger veel E19 problemen kende en ook niet in staat bleek om bij bepaalde Sport1 kanalen geluid weer te geven als die ontvanger in Multikabel gebied gebruikt werd. Uiteindelijk bleek dit aan het signaal van Multikabel te liggen, maar ook hier ging het om een "aanbevolen ontvanger" zoals Multikabel dat destijds noemde. De conclusie die uit dat voorval getrokken kon worden is dat Multikabel het testen van nieuwe ontvangers kennelijk ook niet zo serieus nam want anders hadden de "technische" testers deze problemen ook moeten opmerken. Elke normale consument had immers binnen een paar dagen door dat er iets goed mis was met die ontvanger hoewel de problemen uiteraard ontkend werden door Multikabel.

Verder ben ik van mening dat Humax de enige fabrikant is die nog een beetje degelijke decoders maakt zeker met de IR-HD5000. Want ik heb met de Samsung, en Philips decoders alleen nog maar problemen gehad. En ja ook ik heb maar 2 dagen EPG minder zelfs. Maar ik ben van mening dat je dan beter gwn een tv gidsie kunt kopen voor 45 cent per week. Heb je ook dat gezeur niet

Humax is één van de betere, maar ook niet zonder fouten. Lees op de diverse forums maar eens de topics over Humax ontvangers door. Ook de IR-HD5000 is niet zonder problemen zoals bijvoorbeeld met timers en de beeldkwaliteit van SD kanalen via deze ontvanger laat te wensen over. Nu kunnen wij als consument natuurlijk wel overal een workaround voor gaan verzinnen, maar ik ben van mening dat een ontvanger pas goed is als die probleemloos doet wat hij volgens de specificaties en de handleiding moet doen. Met andere woorden de verwachting waarmaakt die de fabrikant zelf wekt met zijn beschrijvingen ongeacht of je nu wel of niet regelmatig gebruik maakt van bepaalde functionaliteit.

[ArChie]

We hebben er twee (TV) kanalen bij in Ziggo/Multikabel gebied, namelijk Schagen FM en Seaport, die beide samen met Regio22 via de lokale Transport Stream 150 worden doorgegeven. Het zijn eigenlijk radio kanalen die ook een TV signaal bieden om een soort kabelkrantje en vooral veel reclame door te geven. Het is dat er toch al een complete Transport Stream aan bandbreedte verspild wordt voor het doorgeven van lokale kanalen, want op dit soort TV kanalen zit ik niet te wachten.

[ArChie]

ArChie schreef op zaterdag 06 december 2008 @ 22:10:
Het is weer zover, vanavond weer om de 20 seconden haperingen op Comedy Central.

Ondertussen is de eerste week verstreken en nog steeds geen verbetering. Hoewel dit punt volgens een helpdeskmedewerker op het gebruikers forum in onderzoek is, is er echter nog steeds geen storingsmelding op de Ziggo website terug te vinden. Zouden ze soms niet in staat zijn om een Humax IR-FOX C aan te sluiten in de probleem gebieden, af te stemmen op één van de de kanalen in Transport Stream 7 en dan een seconde of twintig te wachten totdat het beeld bevriest? Dat moet toch niet zo moeilijk zijn? Of wordt dit er weer eentje waar ze niet veel ruchtbaarheid aan willen geven in de hoop dat het vanzelf overgaat? Of hopen ze dat hun klanten met een Humax IR-FOX C het maar opgeven als ze er maar lang genoeg niets aan doen?

[ArChie]

Ik las vandaag op het gebruikers forum van een helpdeskmedewerker dat het haperen van de kanalen in Transport Stream 7 op de 514 MHz in Ziggo/Multikabel gebied in combinatie met de Humax IR-FOX C opgelost zou moeten zijn. Dus even gecontroleerd en inderdaad zijn Comedy Central en WDR weer haperingsvrij.

Voor de zekerheid even een Transport Stream capture file gemaakt van TS 7 en door de analyse tools gehaald. Vanaf het moment dat haperingen op Comedy Central me opvielen ontbrak in elke gemaakte 200 MB capture file van TS 7 kortstondig data. De zojuist gemaakte capture file van 200 MB had niet zo'n korte onderbreking van de data stroom. Op zijn zachts gezegd vind ik het nogal verontrustend dat er bij Ziggo/Casema in de headend/NOC gewoon geen alarmbellen afgaan op het moment dat de via glasvezel verstuurde data naar Ziggo/Multikabel gebied niet volledig aankomt of niet volledig op de kabel wordt gezet.

Er moeten eerst weer klanten gaan klagen over haperingen in het beeld voordat men in actie komt en zelfs dan wordt er geen storingsmelding op de website geplaatst. Ongetwijfeld wordt de klanten die dit via de helpdesk aanmelden verteld dat het aan hun COAX huisinstallatie ligt wat dan volgens die helpdeskmedewerkers wel veroorzaakt zal worden door interferentie van stoorsignalen of slechte bekabeling. Dat is tenminste het standaard antwoord dat je van de helpdesk krijgt bij het aanmelden van dit soort problemen. Hoeveel klanten zullen op basis van deze helpdesk beweringen kosten hebben gemaakt om hun bekabeling onnodig te verbeteren? Hoeveel klanten zullen onnodig vrij hebben genomen om een monteur te ontvangen als ze toch tegen die helpdeskmedewerker zijn blijven volhouden dat het niet aan hun eigen bekabeling kan liggen? En dat alleen omdat Ziggo/Casema het signaal van Ziggo/Multikabel gebied niet goed in de gaten houdt of kan houden.

[ArChie]

Vanavond nog eens met mijn Humax IR-FOX C in het EPG Guide overzicht gekeken voor BBC three en BBC four, maar nog steeds denkt Ziggo/Casema dat het aantal uur van 06:00 tot 20:00 uur gelijk is aan 13 i.p.v. 14 en nog steeds ontbreekt het laatste programma dat 's nacht voor 06:00 uur wordt uitgezonden. Op 14 juli heb ik in dit topic al melding gemaakt (ArChie in "Digitale TV frequenties bij Ziggo Casema...") van het foutieve EPG filter voor de BBC three en BBC four kanalen, dus het duurt nu ondertussen al meer dan 5 maanden en nog steeds is het EPG filter niet goed. Hoe moeilijk kan het toch zijn? Zouden ze hun eigen werkzaamheden überhaupt wel controleren daar bij Ziggo/Casema? Dure tools heb je er niet voor nodig om de fout zichtbaar te maken, met een simpel Humax IR-FOX C ontvangertje kun je de EPG gaten al waarnemen. Of denkt Ziggo/Casema soms dat deze EPG gaten een bug in de Humax en andere ontvangers zijn?

[ArChie]

Volgende probleem: Video lock errors op Veronica.

[Klaus_1250]

Ik heb de afgelopen 2 weken eveneens vreemde problemen met een aantal zenders. Eerst het probleem dat RTL5, 7 e.d. om de zoveel seconde stotterde, gisternacht viel om de zoveel seconde het signaal weg op de NL1/2/3 transponder. En vandaag weer van downstream kunnen wisselen omdat de kabel vol zat.

Ziggo verheft incompetentie tot een kunst.

[ArChie]

Klaus_1250 schreef op donderdag 18 december 2008 @ 21:13:
Ziggo verheft incompetentie tot een kunst.

Moedeloos wordt je van die gasten. Onbegrijpelijk dat er mensen zijn die iedere dag naar hun werk gaan zonder interesse voor hetgeen ze doen. Een beetje dom gaan zitten afwachten totdat er weer te veel geklaagd wordt door de klanten voordat ze iets willen oppakken en dan de boel maar half oplossen zonder goed te controleren of gemaakte wijzigingen ook goed hebben uitgepakt. Actief zelf dingen in de gaten houden, diepgaand onderzoeken en goed oplossen hoef je niet van ze te verwachten.

[Mr Magic]

ArChie, heb je recentelijk nog bitrate-metingen gedaan van de digitale kanalen?

Heb het idee dat bij Ziggo/Casema BBC 1 en 2 omlaag zijn gegaan in bitrate, maar misschien ligt het aan m'n ogen

[ArChie]

Mr Magic schreef op donderdag 18 december 2008 @ 23:09:
ArChie, heb je recentelijk nog bitrate-metingen gedaan van de digitale kanalen?

Nee, het is een handmatig proces dat veel tijd kost. Af en toe kijk ik nog wel eens naar de bitrate van wat kanalen als ik vind dat de kwaliteit verder achteruit is gegaan.

Heb het idee dat bij Ziggo/Casema BBC 1 en 2 omlaag zijn gegaan in bitrate, maar misschien ligt het aan m'n ogen

BBC 1 en BBC 2 schommelen momenteel zo rond de 3 Mbps waarbij ze in de categorie van kanalen vallen met een lagere bitrate. Belangrijker voor de kwaliteit is echter de vraag of die 3 Mbps de originele bitrate is of het door Ziggo/Casema verminkte signaal door 10 tot 15 % van de data van de originele data stream van deze kanalen uit te filteren in een poging de bitrate naar beneden te krijgen. Omdat het om kanalen gaat met een variabele bitrate bij BBC 1 en BBC 2 is dat nagenoeg niet hard te maken. De bitrate alleen zegt tegenwoordig niet meer zoveel over de beeldkwaliteit van een kanaal door dat gerommel van Ziggo/Casema aan de originele bitrates. Als ze teveel MPEG data van een kanaal weggooien dat toch al een lage bitrate had dan gaat dat eerder opvallen door artifacten dan bij kanalen met hoge bitrates, dus misschien staat de bitrate beperking voor BBC 1 en 2 wel procentueel wat te hoog ingesteld waardoor het meer is gaan opvallen. Dat zou dan overigens totaal onnodig zijn want in de Transport Stream 13 waar deze kanalen worden doorgegeven is nog 6.7 Mbps ongebruikte ruimte. Maar die ongebruikte ruimte is tot nu toe nog nooit een reden voor Ziggo/Casema geweest om de bitrate beperkingen uit te zetten want het is natuurlijk niet goed als de klanten weten dat het beeld beter kan.

[ArChie]

Ik ben er denk ik uit hoe de klok in de Humax IR-FOX C werkt. Die werkt namelijk niet of wordt in ieder geval niet gebruikt om een up-to-date gehouden tijd aan de gebruiker te presenteren. Vandaag zette ik mijn Humax IR-FOX C ontvanger weer aan nadat die gisteravond om om ongeveer elf uur 's avonds was uitgezet. Tijdens het zappen werd deze laatst weergegeven tijd van gisterenavond nog weergegeven in de EPG informatie box onder aan het scherm en pas na 10 seconden zappen bijgewerkt met de huidige tijd. Voor wie het niet weet, bij Ziggo/Casema wordt er om de 10 seconden afwisselend een Time Date Table (TDT) of een Time Offset Table (TOT) pakketje met de huidige tijd in het digitale TV signaal meegezonden.

De tijd die dus wordt weergegeven bij de EPG informatie en wordt toegepast om het huidige programma uit alle EPG informatie te selecteren is volledig gebasseerd op de ontvangst van die TDT of TOT pakketjes. Daar komt geen intern hardware-matig klok signaal aan te pas. Als je maar langs de kanalen blijft zappen dan heeft de Humax IR-FOX C het te druk om de ontvangen TDT of TOT pakketjes te verwerken waardoor de tijd niet bijgewerkt wordt. Stop je met zappen dan heeft de Humax wel weer de tijd en volgt er een update zodra het volgende tijd pakketje langs komt. Ga je nu weer een programma kijken dan blijft de tijd weer stilstaan op de laatst ontvangen en verwerkt tijd pakketjes totdat je weer gaat zappen of de EPG informatie oproept. Tijdens het kijken naar een programma verwerkt de Humax IR-FOX C dus niet de tijd pakketjes en zoals gezegd is er kennelijk geen interne hardware-matige klok die de tijd up to date houdt.

Gevolg: Zodra je begint te zappen is de laatst verwerkte tijd altijd verouderd en zal de Humax IR-FOX C dus niet in staat zijn om het huidige programma uit de EPG informatie halen. Dat lukt pas nadat de tijd weer "bij" is. Zeer irritant en eigenlijk is het te gek voor woorden dat dit door de "testen" van Ziggo heen komt. Maar ja, als de belangrijkste eis van Ziggo is dat een ontvanger zo min mogelijk mag kosten dan krijg je dit soort rommel.

[Klaus_1250]

Als ik het goed heb (denk even diep terug) was dit niet zo toen de Humax uit kwam. Tenminste, wat jij beschrijft zie ik volgens mij pas sinds de laatste 2 updates. Daarvoor is het me nooit opgevallen. Ik vraag me af waarom ze de interne klok van de Humax niet gebruiken, maar ik gok erop dat het iets met de vastlopers te maken heeft.

[ Voor 14% gewijzigd door Klaus_1250 op 20-12-2008 19:04 ]

[ArChie]

Klaus_1250 schreef op zaterdag 20 december 2008 @ 19:02:
Als ik het goed heb (denk even diep terug) was dit niet zo. Tenminste, wat jij beschrijft zie ik volgens mij pas sinds de laatste 2 updates. Daarvoor is het me nooit opgevallen. Ik vraag me af waarom ze de interne klok van de Humax niet gebruiken.

De Humax IR-FOX C heeft nog nooit echt op tijd gelopen. Bij de originele firmware liep de klok ook veel achter waardoor ik het vermoeden had dat er toen helemaal niet van die tijd pakketjes gebruik werd gemaakt. Mogelijk dat de interne hardware klok te onnauwkeurig is. Ik vermoed nu dat de programmeur voor de laatste firmware update besloten heeft om dan die interne hardware klok maar helemaal niet meer te gebruiken en de tijd volledig te laten sturen door de tijd pakketjes in het signaal als er ergens een tijd wordt getoond. Dat werkt dus voor geen meter tijdens het zappen. Tegenwoordig staat er bij mij tenminste veelal geen huidig programma in de EPG informatie box die getoond wordt tijdens het zappen omdat de tijd nog achterloopt. En Ziggo ziet dat niet tijdens het "testen" van een firmware update. Dit soort geklooi moeten zij toch afkeuren, dat hoef ik als klant toch niet te gaan onderzoeken? Zij hebben toch inside informatie over wat en hoe er gefixd is als ze een firmware update moeten testen? Stelletje prutsers.

[ArChie]

Nog zo'n hardnekkige bug in de Humax IR-FOX C dat via forums al diverse keren is aangekaart, maar na meerdere firmware updates nog steeds niet is opgelost: Het blijven hangen in de 4:3 aspect ratio terwijl je naar een 16:9 uitzending gezapt bent. Alleen maar op te lossen door of de Humax ontvanger uit en aan te zetten, of door even het systeem menu te openen en te sluiten. Gisterenavond had ik hier ook weer eens last van. Het komt meerdere keren per week voor, maar is kennelijk niet belangrijk genoeg voor Ziggo om er ook eens iets aan te laten doen door de fabrikant.

[The_Doman]

Wat ik ook niet kan begrijpen is dat de timerfuncties van de Humax decoders (nog steeds) niet goed functioneren.
Hierdoor is het niet goed mogenlijk om op eenvoudige wijze opnames te maken op een externe DVD/HD recorder met behulp van de EPG timerfunctie.
Echt onvoorstelbaar dat deze functies niet normaal bruikbaar zijn, blijkbaar wordt het grootste deel van het testen/certificeren nog steeds besteed aan de irdeto beveiliging.

Ziggo-Gebruikers.nl - Vraag: Humax Standby Timer

TipX over de Humax IRHD-5000:
Ik heb al een mail geschreven naar Copaco, de importeur van Humax Ned., met de klachten. Het beeld is niet geheel ok maar zeer storend vind ik dat de timer niet werkt en dus geheel nutteloos is. Ik verbaas me eigenlijk dat ik daar hier niet zoveel klachten over lees, affijn. Dit komt omdat men de decoder zuiniger wilden laten zijn en hebben zij dus door firmware bepaalde 'spanningen' veranderd waardoor de timer niet opstart. De beeldklachten zijn ook bij hun bekend en hebben ze doorgegeven aan Humax voor een volgende firmware uitgave. Maar het is natuurlijk ook nog maar de vraag of dit door een firmware opgelost kan worden, dat weet alleen Humax.

[ArChie]

The_Doman schreef op zondag 21 december 2008 @ 15:08:
Wat ik ook niet kan begrijpen is dat de timerfuncties van de Humax decoders (nog steeds) niet goed functioneren.
Hierdoor is het niet goed mogenlijk om op eenvoudige wijze opnames te maken op een externe DVD/HD recorder met behulp van de EPG timerfunctie.
Echt onvoorstelbaar dat deze functies niet normaal bruikbaar zijn, blijkbaar wordt het grootste deel van het testen/certificeren nog steeds besteed aan de irdeto beveiliging.

Als ik toch keer op keer de problemen lees met alle door Ziggo goedgekeurde ontvangers dan vraag ik me af wat er nu eigenlijk getest wordt en wie die testen uitvoeren. Bij de timer en klok problemen van Humax gaat het toch om basis functionaliteit die niet werkt en niet opgemerkt wordt door de "testers". Vermoedelijk zijn die testers de helpdesk medewerker van de maand of iets dergelijks die al blij zijn als ze het ding aangesloten weten te krijgen en er af en toe beeld uitkomt. Altijd beeld en geluid is niet noodzakelijk voor goedkeuring zoals destijds wel bleek bij het fieldtesten van de Samsung DCB-P850R in Multikabel gebied.

Ook de testen voor de Irdeto beveiliging blijken in de praktijk niet veel voor te stellen gezien de problemen met het niet op kunnen nemen met de Siemens PVR en recent ook de Cisco HDTV PVR. Ziggo/Casema was al meer dan een jaar bezig met die Cisco HDTV PVR, maar na introductie regende het klachten over problemen met deze ontvanger. Het "testen" was er door tijdsgebrek kennelijk een beetje bij ingeschoten moeten we maar denken.

Nu zijn ze weer bezig met een zogenaamd Cisco HDTV PVR "test" traject voor klanten dat gecoördineerd wordt door een enquete bureau. Het zal wel net zo'n "test" traject zijn als bij UPC waar het doel niet het "testen" van een ontvanger is, maar onder het mom van "testen" zoveel mogelijk ontvangers bij klanten neerzetten in de hoop dat er zo min mogelijk ontvangers aan het einde van het "test" traject retour worden gezonden. Voor de vorm wordt er dan aan het einde van het "test" traject nog even een enquete gehouden waarvan de kans groot is dat de deelnemers nooit meer iets van de resultaten horen. Voorzieningen voor het aanmelden van echte bugs zijn er waarschijnlijk niet getroffen, maar dat is ook niet het doel van dit "test" traject. Dat blijkt wel uit het feit dat klanten die allang een Cisco HDTV PVR hebben en dus ervaringsdeskundigen zijn niet meer mee mogen doen met dit "test" traject. Met andere woorden: gewoon een ordinair marketing traject i.p.v. een test traject. En dan zijn sommige mensen nog tereurgesteld dat ze niet mogen mee helpen met het "testen".

Zolang de kabel ontvanger markt niet echt open is heeft het handje vol fabrikanten dat door Ziggo toegelaten wordt nauwelijks te vrezen voor omzet verlies als hun ontvanger niet goed blijkt te functioneren. Er is toch nagenoeg geen keus voor een andere ontvanger en ondanks de "zware testen" van Ziggo blijkt die andere goedgekeurde ontvanger net zoveel problemen te kennen. Het is toch te gek voor woorden dat consumenten handen vol geld uitgeven aan dure platte schermen, waarvan de interne functionaliteit nauwelijks wordt gebruikt, terwijl de kwaliteit, stabiliteit en functionaliteit van het TV kijken bepaald wordt door een waardeloze, slecht geteste, middle of the road losse kabel ontvanger vol bugs.

De volgende ellende zit er overigens al weer aan te komen, de Humax HDTV PVR en de tweede generatie Samsung HDTV ontvanger als vervanging van de Samsung DCB-H360R. Hoe goed getest deze ontvangers zijn zullen we via de diverse forums weer snel genoeg weten. Trouwens, was het niet eerst de bedoeling dat Samsung een firmware update zou uitbrengen voor de DCB-9401R? Dat wordt nu toch al jaren beloofd? Ondertussen zijn al de DCB-P850R en DCB-B270R verschenen, waardoor er kennelijk geen tijd was voor de beloofde firmware update van de DCB-9401R en met de vervanging van de DCB-H360R zal dat er wel weer bij ingeschoten zijn. Het mag duidelijk zijn waar de prioriteiten van Ziggo liggen en dat is niet bij de klant.

[ Voor 9% gewijzigd door ArChie op 21-12-2008 16:21 ]

[ArChie]

Verkeerd

[ Voor 105% gewijzigd door ArChie op 25-02-2009 21:16 ]

[ArChie]

Nog een bug die sinds de laatste firmware update geïntroduceerd is in de Humax IR-FOX C: Tegenwoordig blijft het TV beeld in de achtergrond deels zichtbaar als je met behulp van de Guide knop het volledige EPG overzicht oproept. Op zich geen ramp, maar in het volledige EPG overzicht heeft de blauwe knop de functie om in de EPG informatie te zoeken terwijl normaal bij het weergeven van het TV beeld diezelfde blauwe knop de functie heeft om het beeld te pauzeren. Druk je in het EPG overzicht op de blauwe knop om te gaan zoeken dan wordt het beeld in de achtergrond ook gepauzeerd. Verlaat je vervolgens het volledige EPG overzicht met behulp van de Exit knop dan blijft het beeld gepauzeerd en moet je dus nog een keer op de blauwe pauze knop drukken om het beeld weer verder te laten gaan. Irritant en ook weer niet opgemerkt tijdens de "zware testen" van Ziggo.

[The_Doman]

The_Doman schreef op zondag 14 december 2008 @ 13:32:
Blijkbaar ben ik dus niet de enige die problemen heeft met de Eurosport HD zender lees ik:

Ziggo-Gebruikers.nl - Vraag: Eurosport HD valt vaak weg...

De problemen met het Eurosport HD signaal zijn momenteel voorbij lijkt het.
Dit lag toch aan Eurosport zelf aangezien de kijkers bij UPC dezelfde storing hadden waargenomen.

[psy]

Dit vind ik een beetje raar. Net5 is sinds een week of 2 aantal dagen verdwenen (Ziggo Limburg). Ik dus een nieuwe scan doen, niks Net5. Gewoon onvindbaar. Zou ik die transponderlijst weer moeten updaten?

[ArChie]

psy schreef op dinsdag 23 december 2008 @ 12:45:
Dit vind ik een beetje raar. Net5 is sinds een week of 2 aantal dagen verdwenen (Ziggo Limburg). Ik dus een nieuwe scan doen, niks Net5. Gewoon onvindbaar. Zou ik die transponderlijst weer moeten updaten?

Volgens deze lijst (http://www.digitalekabeltelevisie.nl/techniek/tvhome.shtml) zou NET5 gewoon in Transport Stream 3 moeten zitten die in Limburg op de 372 MHz wordt doorgegeven samen met bijvoorbeeld Eurosport HD. Die lijst dateert van 27 oktober en is misschien nog niet bijgewerkt met de laatste stand van zaken. Ik zit echter niet in Ziggo/@Home gebied dus ik kan het niet aan de hand van het signaal even controleren.

[Klaus_1250]

Net5 zit op zijn gebruikelijke plek (regio 1111, Brabant/Limburg).

[ArChie]

Op het gebruikers forum werd nog een bug in de Humax IR-FOX C genoemd die ik vergeten ben om te vermelden: Bij het zappen langs het Zenderoverzichtskanaal naar Discovery Channel komt het regelmatig voor dat er alleen beeld is maar geen geluid op Discovery Channel. Even naar het volgende kanaal zappen en weer terug zorgt er voor dat er weer geluid is. Lekker irritant als je zoals ik regelmatig even een programma op Discovery Channel kijkt. Ondertussen voldoende bugs voor een firmware update lijkt me, maar Ziggo zal deze bugs wel niet belangrijk genoeg vinden om Humax ook eens aan te sporen om er iets aan te doen.

Geen idee wat er toch voor iets bijzonders aan de hand is met die still van het Zenderoverzichtskanaal bij Ziggo/Casema, maar de Humax IR-FOX C heeft dit nog nooit een lekker kanaal gevonden. Waarom dat Zenderoverzichtskanaal nu zo nodig tussen de kanalen in op positie 12 moet staan is mij overigens een raadsel. Volgens mij raadpleegt nauwelijks iemand dat overzicht. Zet zo'n kanaal op 999.

[ Voor 9% gewijzigd door ArChie op 23-12-2008 13:23 ]

[digitalekabeltv]

ArChie schreef op dinsdag 23 december 2008 @ 12:54:
[...]
Volgens deze lijst (http://www.digitalekabeltelevisie.nl/techniek/tvhome.shtml) zou NET5 gewoon in Transport Stream 3 moeten zitten die in Limburg op de 372 MHz wordt doorgegeven samen met bijvoorbeeld Eurosport HD. Die lijst dateert van 27 oktober en is misschien nog niet bijgewerkt met de laatste stand van zaken.

Lijst is bijgewerkt, en weer actueel. Wat er veranderd is in stream 3 is dat Brabant 10 er bij gekomen is. Net 5 heeft gewoon zijn oude Service-ID gehouden, dus dat lijkt me geen probleem.

Vraag aan Psy; zie je wel Brabant 10?

[psy]

Nou...
Ik heb gisteren eerst dat tooltje van FireDTV (NIT scan tool) gebruikt en opnieuw gescand.... helemaal niets meer te vinden. Nou laat maar dan. Daarna weer een transponderlijst van okt 2008 in het register gezet, opnieuw gescand, en ik zie Net5 weer! Raar hoor... Nu zie ik ook Eurosport HD in de FireDTV viewer, die zag ik eerst ook niet.

[ Voor 17% gewijzigd door psy op 24-12-2008 10:35 . Reden: Linkjes toegevoegd ]

[ArChie]

psy schreef op woensdag 24 december 2008 @ 10:28:
Nou...
Ik heb gisteren eerst dat tooltje van FireDTV gebruikt en opnieuw gescand.... helemaal niets meer te vinden. Nou laat maar dan.

Ik neem aan dat je met dat tooltje de NIT scanner bedoelt die door een zekere Meylof gemaakt is? Volgens mij zijn er nog niet veel mensen die dat tooltje succesvol hebben weten te gebruiken.

Daarna weer een transponderlijst van okt 2008 in het register gezet, opnieuw gescand, en ik zie Net5 weer! Raar hoor... Nu zie ik ook Eurosport HD in de FireDTV viewer, die zag ik eerst ook niet.

Volgens mij zijn het aantal gebruikte frequenties voor digitale TV sinds enige tijd niet meer gewijzigd. Welke kanalen er via die frequenties worden doorgegeven kan wel aan wijzigingen onderhevig zijn. Van tijd tot tijd even opnieuw scannen kan geen kwaad om je kanalenlijst actueel te houden. Eurosport HD zit er toch al weer een tijdje op moet je maar denken.

[psy]

Ik leg de 'schuld' eigenlijk ook bij Media Center. Het is me al vaker gebeurd dat er gewoon kanalen verdwijnen. Heel raar. Het meest vervelende vind ik dat je weer opnieuw moet sorteren.

Heb overigens op een testpartitie TV pack 2008 draaien. Maar ik moet eerst zeker zijn dat dit goed werkt voordat ik dit ook ga gebruiken anders krijg ik geheid problemen thuis

[ Voor 32% gewijzigd door psy op 24-12-2008 10:39 ]

[ArChie]

psy schreef op woensdag 24 december 2008 @ 10:37:
Ik leg de 'schuld' eigenlijk ook bij Media Center. Het is me al vaker gebeurd dat er gewoon kanalen verdwijnen. Heel raar. Het meest vervelende vind ik dat je weer opnieuw moet sorteren.

"Schuld" vind ik een wat moeilijk woord in deze context. Zoals ik al aangaf wijzigt de verdeling van digitale TV kanalen over de frequenties nog wel eens. Van tijd tot tijd komt er wat bij, gaat er wat af en soms verplaatst Ziggo ook kanalen van de ene frequentie naar de andere omdat qua bitrate verdeling beter uitkomt. Ook komt het voor dat de zogenaamde PID's van kanalen wijzigen omdat ze bij Ziggo weer eens een nieuwe nummering bedacht hebben. Bij Ziggo/Casema heb ik zelfs gezien dat ze direct PID's zijn gaan hergebruiken bij een ander kanaal terwijl het originele kanaal dat voorheen die PID gebruikte ook nog gewoon aanwezig was. Media Center houdt intern geen rekening met kanalen wijzigingen, sterker nog Media Center denkt te maken te hebben met een DVB-T signaal waar nog allerlei simulatie software van FireDTV/FloppyDTV tussen zit om de boel aan de praat te krijgen.

Het is dus niet raar, maar vervelend dat je van tijd tot tijd kanalen kwijt bent of niet meer werken omdat Ziggo nu eenmaal wijzigingen blijft doorvoeren in de kanalen. Af en toe opnieuw scannen is de enige manier om de boel actueel te houden.

[The_Doman]

ArChie schreef op woensdag 24 december 2008 @ 10:34:
Ik neem aan dat je met dat tooltje de NIT scanner bedoelt die door een zekere Meylof gemaakt is? Volgens mij zijn er nog niet veel mensen die dat tooltje succesvol hebben weten te gebruiken.

Zo'n NIT scanner tool lijkt mij ook zeer handig voor veel DVB-C gebruikers, jammer alleen dat deze blijkbaar alleen gemaakt is voor de FireDTV kaartjes.
Of is er al een gelijksoortig tool beschikbaar wat wel werkt met standaard BDA drivers?

[ArChie]

The_Doman schreef op woensdag 24 december 2008 @ 11:30:
Zo'n NIT scanner tool lijkt mij ook zeer handig voor veel DVB-C gebruikers, jammer alleen dat deze blijkbaar alleen gemaakt is voor de FireDTV kaartjes.
Of is er al een gelijksoortig tool beschikbaar wat wel werkt met standaard BDA drivers?

Nee, voor zover mij bekend heeft nog niemand een algemene NIT scanner gemaakt die werkt op basis van de BDA drivers. Afgezien van interfacing met de BDA drivers is het probleem in feite wat je dan gaat doen met de output. In welk formaat moet dat. Meylof is verbonden aan het FireDTV/FloppyDTV gebeuren, dus zorgt zijn output er kennelijk voor dat de drivers van FireDTV/FloppyDTV op de juiste manier geconfigureerd worden voor Windows Media Center. Waarschijnlijk past hij een X aantal bestanden aan en zet het één en ander de registry zodat het werkt. Althans dat is de bedoeling. Maar wat nu als iemand i.p.v. Windows Media Center gebruik maakt van bijvoorbeeld Media Portal of DVBViewer. Die gebruikers willen dan het liefst zien dat hun programma's automatisch geconfigureerd worden met zo'n tool.

Bij de output die bijvoorbeeld mijn tooltje produceert heb ik gekozen voor een eenvoudig UTF-8 overzicht omdat het vooral gaat om het leesbaar tonen van zoveel mogelijk informatie in een tabel vorm. Het tooltje is echter geschreven in Java wat achteraf niet zo'n handige keuze was omdat ik tot nu toe nog geen goede Java BDA interface library heb gevonden zodat het tooltje eventueel direct een Transport Stream zou kunnen parsen die uit een DVB-C PC-TV kaart afkomstig is. Tot dusver kan mijn tooltje alleen gebruikt worden met Transport Stream capture files gemaakt met bijvoorbeeld de Twinhan TS Capture tool. Omdat ik dit tooltje voornamelijk gebruik om ervaring met Java op te doen heb ik geen energie gestoken in het porten van één en ander naar C++ waarmee interfacing met de BDA drivers een stuk makkelijker moet gaan.

[ArChie]

Momenteel ben ik bezig met een nieuwe uitbreiding aan mijn tooltje om ook de CA Message Table (CMT) data pakketjes te kunnen parsen. Omdat er uiteraard vrij weinig over de data structuren van de diverse Conditional Access Systems (CAS) wordt gepubliceerd betekent dit het nodige puzzelwerk om er nog wat zinvolle informatie uit te kunnen halen. In principe is er één openbare DVB specificatie over CMT pakketjes waarin wordt aangegeven dat deze uit een lengte veld bestaat gevolgd door X data bytes. De data structuur van die X data bytes zijn per type bericht en per type CAS verschillend.

Er zijn twee table ID's (0x80 en 0x81) gedefinieerd voor de zogenaamde Entitlement Control Messages (ECM) en de overige table ID's in de range van 0x82 t/m 0x8F zijn voor de Entitlement Management Messages (EMM). Tot dusver heb ik eerst een uitbreiding gemaakt om de ECM pakketjes te parsen die door Ziggo verstuurd worden. Deze ECM pakketjes zijn specifiek voor het Irdeto CAS waarbij de X data bytes bestaan uit een header veld zonder encryptie gevolgd door X data bytes met encryptie. De informatie van de header blijkt te bestaan uit een sectie nummering, een zogenaamde channel_ID en wat onbekende bytes die ik nog niet heb weten te herleiden. Voor de ECM pakketjes die verzonden worden met CA PID 4000, behorende bij Motors TV voor de Ziggo/Multikabel abonnees, ziet dat er ongeveer als volgt uit:

├─■  CMT  {  CA  Message  Table  }
│  └─■  transport_stream_ID  =  7
│      ├─■  CA  PID  4000
│      │  ├─■  transport_stream_ID  =  7
│      │  ├─■  CA_PID  =  4000
│      │  └─■  sections:  {  Required  sections:  4,  available  sections:  4  }
│      │      ├─■  section  {  0/3  }
│      │      │  ├─■  unknown_byte_value_1  =  69
│      │      │  ├─■  section_number  =  0
│      │      │  ├─■  last_section_number  =  3
│      │      │  ├─■  channel_ID  =  1
│      │      │  ├─■  unknown_byte_value_2  =  0
│      │      │  ├─■  unknown_byte_value_3  =  8
│      │      │  ├─■  unknown_byte_value_4  =  142
│      │      │  └─■  CA_data  =  0000    42  A3  04  33  98  62  75  67  BC  9D  15  88  45  73  83  36    B..3.bug....Es.6
│      │      │                              0010    76  57  A1  CB  05  C3  7C  5D  92  84  99  DA  CC  2F  00  C9    vW....|]...../..
│      │      │                              0020    1C  53  68  1F  16  70  BE  6F  71  E7  44  FB  1D  C6  21  C7    .Sh..p.oq.D...!.
│      │      ├─■  section  {  1/3  }
│      │      │  ├─■  unknown_byte_value_1  =  69
│      │      │  ├─■  section_number  =  1
│      │      │  ├─■  last_section_number  =  3
│      │      │  ├─■  channel_ID  =  13
│      │      │  ├─■  unknown_byte_value_2  =  0
│      │      │  ├─■  unknown_byte_value_3  =  8
│      │      │  ├─■  unknown_byte_value_4  =  142
│      │      │  └─■  CA_data  =  0000    F6  A5  FB  EC  A9  42  88  D1  8D  FA  E3  4C  4A  DF  5C  68    .....B.....LJ.\h
│      │      │                              0010    C9  D1  27  B5  6D  50  CA  BE  56  A5  0F  CE  B2  5A  D0  31    ..'.mP..V....Z.1
│      │      │                              0020    2E  E3  F7  53  DC  24  93  87  1A  C0  BE  59  F7  9A  99  20    ...S.$.....Y...  
│      │      ├─■  section  {  2/3  }
│      │      │  ├─■  unknown_byte_value_1  =  69
│      │      │  ├─■  section_number  =  2
│      │      │  ├─■  last_section_number  =  3
│      │      │  ├─■  channel_ID  =  17
│      │      │  ├─■  unknown_byte_value_2  =  0
│      │      │  ├─■  unknown_byte_value_3  =  8
│      │      │  ├─■  unknown_byte_value_4  =  142
│      │      │  └─■  CA_data  =  0000    76  EF  93  3E  07  EB  40  A2  73  E9  15  BA  45  7C  75  F9    v..>..@.s...E|u.
│      │      │                              0010    2C  30  9F  F2  20  FE  C9  82  41  94  D9  5B  2B  0F  A0  B9    ,0..  ...A..[+...
│      │      │                              0020    E8  DF  9B  A7  3E  B8  48  6B  28  05  C5  29  EA  56  E8  A3    ....>.Hk(..).V..
│      │      └─■  section  {  3/3  }
│      │          ├─■  unknown_byte_value_1  =  69
│      │          ├─■  section_number  =  3
│      │          ├─■  last_section_number  =  3
│      │          ├─■  channel_ID  =  9999
│      │          ├─■  unknown_byte_value_2  =  0
│      │          ├─■  unknown_byte_value_3  =  2
│      │          ├─■  unknown_byte_value_4  =  136
│      │          └─■  CA_data  =  0000    33  F0  22  BD  12  1D  74  92  EB  1D  0D  16  24  81  29  9A    3."...t.....$.).
│      │                                      0010    14  7A  C7  9E  E9  7F  20  AF  E4  C4  E0  29  9C  51  34  71    .z....  ....).Q4q
│      │                                      0020    77  4D  56  23  73  8E  77  3E  93  A0  C5  20  FB  F6  C1  71    wMV#s.w>...  ...q


De CA_data die van encryptie is voorzien zal wel een deel van de benodigde decryptie sleutels bevatten voor het Motors TV signal. De channel_ID blijkt een verwijzing te zijn naar het abonnement waartoe een kanaal behoort. Uit het bovenstaande voorbeeld blijkt dat Motors TV tot de volgende abonnementen voor Ziggo/Multikabel abonnees behoort:

code:

   1 = Verrassing pakket
  13 = Totaal pakket
  17 = Sport keuze pakket
9999 = Preview pakket

Opvallend is dat voor Ziggo/Casema abonnees de channel_ID nummering in de ECM pakketjes (CA PID 5000) weer afwijkt van deze nummering:

code:

    1 = Verrassing pakket
  212 = Totaal pakket
   22 = Sport keuze pakket
61439 = Preview pakket

Wie weet wat de unknown_byte_value_X waarden voorstellen mag het zeggen, dat helpt mij weer verder met de correcte data definitie voor die header.

Voor de aardigheid heb ik eens een aantal Transport Stream (TS) capture files van TS 7 met elkaar vergeleken van 08/11/2008, 6/12/2008 en 16/12/2008. De eerste datum was voordat Ziggo "iets" gewijzigd had aan het Irdeto CAS waardoor de Cisco en Siemens PVR's niet meer wilden opnemen, de tweede datum was tijdens het optreden van dat opname probleem en de derde datum nadat het probleem was opgelost voor beide PVR's. In TS 7 wordt ook Comedy Central doorgegeven bij Ziggo/Casema en natuurlijk ook Ziggo/Multikabel. Comedy Central behoort tot het zogenaamde basis digitale kanalen pakket (channel_ID = 11 voor Ziggo/Multikabel abonnees en 211 voor Ziggo/Casema abonnees). Met de wijziging aan het Irdeto CAS wilde Ziggo bereiken dat voorlopig alle kanalen uit het basis pakket door iedereen met een smartcard bekeken konden worden zolang hun administratieve systeem een puinhoop is en ze niet in staat blijken om binnen twee weken een smartcard te registreren. Men zou de preview periode kunnen verlengen, maar dat geldt voor alle kanalen en dat geeft waarschijnlijk weer problemen met de leveranciers van die kanalen.

Op 08/11/2008 zag de ECM informatie voor Comedy Central voor de Ziggo/Multikabel abonnees er als volgt uit:
│      ├─■  CA  PID  4001
│      │  ├─■  transport_stream_ID  =  7
│      │  ├─■  CA_PID  =  4001
│      │  └─■  sections:  {  Required  sections:  3,  available  sections:  3  }
│      │      ├─■  section  {  0/2  }
│      │      │  ├─■  unknown_byte_value_1  =  67
│      │      │  ├─■  section_number  =  0
│      │      │  ├─■  last_section_number  =  2
│      │      │  ├─■  channel_ID  =  11
│      │      │  ├─■  unknown_byte_value_2  =  0
│      │      │  ├─■  unknown_byte_value_3  =  8
│      │      │  ├─■  unknown_byte_value_4  =  142
│      │      │  └─■  CA_data  =  0000    3B  F3  72  4D  F7  34  EC  0A  48  BC  FE  B3  08  6E  E9  10    ;.rM.4..H....n..
│      │      │                              0010    DD  B3  4E  30  AE  05  13  46  95  FA  57  4F  75  04  A1  43    ..N0...F..WOu..C
│      │      │                              0020    FE  66  F0  9A  A9  51  FB  29  B9  54  A9  21  94  85  A7  EF    .f...Q.).T.!....
│      │      ├─■  section  {  1/2  }
│      │      │  ├─■  unknown_byte_value_1  =  67
│      │      │  ├─■  section_number  =  1
│      │      │  ├─■  last_section_number  =  2
│      │      │  ├─■  channel_ID  =  13
│      │      │  ├─■  unknown_byte_value_2  =  0
│      │      │  ├─■  unknown_byte_value_3  =  8
│      │      │  ├─■  unknown_byte_value_4  =  142
│      │      │  └─■  CA_data  =  0000    D7  41  9B  44  09  B4  6B  CD  DC  E7  09  09  CF  7F  9E  13    .A.D..k.........
│      │      │                              0010    74  62  CE  7F  15  C8  4B  75  4A  79  19  46  36  04  21  61    tb....KuJy.F6.!a
│      │      │                              0020    C9  00  34  02  F7  AC  9A  9C  32  7F  15  7A  DB  7D  7C  77    ..4.....2..z.}|w
│      │      └─■  section  {  2/2  }
│      │          ├─■  unknown_byte_value_1  =  67
│      │          ├─■  section_number  =  2
│      │          ├─■  last_section_number  =  2
│      │          ├─■  channel_ID  =  9999
│      │          ├─■  unknown_byte_value_2  =  0
│      │          ├─■  unknown_byte_value_3  =  2
│      │          ├─■  unknown_byte_value_4  =  136
│      │          └─■  CA_data  =  0000    6B  1B  81  B3  54  C9  AD  27  57  81  F6  B8  EA  F1  4E  F6    k...T..'W.....N.
│      │                                      0010    DB  83  25  CA  E7  03  63  17  08  3B  E0  95  A0  DD  7E  9D    ..%...c..;....~.
│      │                                      0020    FF  9C  67  A7  E0  5A  34  92  3D  E1  8A  C7  3E  AD  25  0B    ..g..Z4.=...>.%.

Comedy Central behoorde dus tot 3 abonnementsvormen, namelijk het basis pakket (11), het totaal pakket (13) en het preview pakket (9999).

Op 06/12/2008, tijdens de problemen na het wijzigen van het Irdeto CAS, was die informatie als volgt:
│      ├─■  CA  PID  4001
│      │  ├─■  transport_stream_ID  =  7
│      │  ├─■  CA_PID  =  4001
│      │  └─■  sections:  {  Required  sections:  1,  available  sections:  1  }
│      │      └─■  section  {  0/0  }
│      │          ├─■  unknown_byte_value_1  =  67
│      │          ├─■  section_number  =  0
│      │          ├─■  last_section_number  =  0
│      │          ├─■  channel_ID  =  65535
│      │          ├─■  unknown_byte_value_2  =  0
│      │          ├─■  unknown_byte_value_3  =  0
│      │          ├─■  unknown_byte_value_4  =  128
│      │          └─■  CA_data  =  0000    32  93  FD  B8  BF  8C  3E  6E  B5  EA  3E  CD  D9  A9  C3  7E    2.....>n..>....~
│      │                                      0010    54  90  CE  73  2B  7D  31  D7  A0  71  E0  F4  7A  3F  0E  0E    T..s+}1..q..z?..
│      │                                      0020    6B  9E  F0  4B  E7  81  38  E0  92  51  23  80  14  0D  5B  4B    k..K..8..Q#...[K

Comedy Central behoort nog maar tot 1 abonnementsvorm, namelijk 65535 (= 0xFFFF). Kennelijk is die 65535 waarde iets speciaals waarmee Ziggo kan aangeven dat ongeacht het afgesloten abonnement het kanaal bekeken kan worden zolang je maar een smartcard hebt. Toch gaat er iets niet goed omdat de data behorende bij dit channel_ID kennelijk als negatief effect heeft dat de Cisco en de Siemens PVR niet meer willen opnemen.

Op 16/12/2008, na het oplossen van die problemen, is dat als volgt:
│      ├─■  CA  PID  4001
│      │  ├─■  transport_stream_ID  =  7
│      │  ├─■  CA_PID  =  4001
│      │  └─■  sections:  {  Required  sections:  1,  available  sections:  1  }
│      │      └─■  section  {  0/0  }
│      │          ├─■  unknown_byte_value_1  =  71
│      │          ├─■  section_number  =  0
│      │          ├─■  last_section_number  =  0
│      │          ├─■  channel_ID  =  65535
│      │          ├─■  unknown_byte_value_2  =  0
│      │          ├─■  unknown_byte_value_3  =  0
│      │          ├─■  unknown_byte_value_4  =  128
│      │          └─■  CA_data  =  0000    80  7E  B0  FC  E3  D2  6E  7F  DC  48  BB  98  76  BE  8F  B9    .~....n..H..v...
│      │                                      0010    D7  3E  80  87  BD  DE  6D  52  ED  10  B0  D6  3C  C2  56  19    .>....mR....<.V.
│      │                                      0020    28  13  EF  1F  D6  EF  B5  03  4C  99  0C  4B  19  C2  27  24    (.......L..K..'$

Nog steeds maar één 65535 channel_ID voor Comedy Central, maar het lijkt erop dat de unknown_byte_value_1 waarde is gewijzigd van 67 naar 71. Dit afgezien van mogelijke extra data wijzigingen in het CA_data deel dat door de encryptie niet nader te onderzoeken is.

De volgende stap is het maken van een uitbreiding waarmee een overzicht te produceren is voor alle kanalen en de bijbehorende abonnementen op basis van de channel ID. Een subscription lijst dus ala de PID lijst. Daarmee is dan mooi te controleren of Ziggo/Casema nog fouten heeft gemaakt met het toewijzen van kanalen aan abonnementen.

[ArChie]

Op basis van een oude complete set Transport Stream (TS) capture files eens gekeken of de CA Message Table (CMT) uitbreiding het tooltje ook werkt met het parsen van een set TS capture files i.p.v. één file. Dat werkt en heeft direct een overzicht opgeleverd van alle channel_ID's die bij Ziggo/Multikabel en Ziggo/Casema worden gebruikt. Zie de onderstaande overzichten:

Voor de Ziggo/Multikabel abonnees:

code:

   1 = Verrassing pakket
   3 = Film1 pakket
   4 = Sport1 pakket
   5 = HDTV pakket
   6 = Gay Lifestyle pakket
   8 = Film & Entertainment pakket
  10 = Basis HDTV pakket
  11 = Basis pakket
  13 = Totaal pakket
  14 = Kennis & Nieuws pakket
  15 = Muziek pakket
  16 = Kids pakket
  17 = Sport pakket
  19 = Music Choice & XLnt Radio pakket
  28 = Eredivisie Live Voetbal pakket
  33 = ?
  42 = ?
  83 = Hindi pakket
  84 = Chinees pakket
 208 = Turks pakket
 209 = Uitgebreid Turks pakket
9999 = Preview pakket

Voor de Ziggo/Casema abonnees:

code:

    1 = Verrassing pakket
    2 = Basis HDTV pakket
    4 = Film1 pakket
    5 = Sport1 pakket
    6 = HDTV pakket
   21 = Kennis & Nieuws pakket
   22 = Sport pakket
   23 = Film & Entertainment pakket
   24 = Kids pakket
   25 = Muziek pakket
   26 = Music Choice & XLnt Radio pakket
   28 = Eredivisie Live Voetbal pakket
   67 = Chinees pakket
   85 = Gay Lifestyle pakket
  205 = Hindi pakket
  208 = Turks pakket
  209 = Uitgebreid Turks pakket
  211 = Basis pakket
  212 = Totaal pakket
61439 = Preview pakket

Als ik die channel_ID nummering zo zie dan vraag ik me direct af waarom er voor zo'n nummering is gekozen en vraag me af waarom die nummering niet gelijk kan zijn voor Ziggo/Multikabel en Ziggo/Casema. Hierdoor wordt het alleen maar lastiger te onderhouden. Opvallend is ook dat er bij Ziggo/Multikabel kennelijk nog twee oude channel_ID's (33 en 42) in gebruik zijn voor wat kanalen die ook in het Hindi pakket zitten dat channel_ID 83 heeft. Voor channel_ID's 33 en 42 worden in de headend kennelijk nog steeds nutteloos sleutels gegenereerd en doorgegeven via het digitale TV signaal. Voor de channel_ID's die in gebruik zijn voor de Ziggo/Casema abonnees heb ik niet meer gecontroleerd op ongebruikte channel_ID's.

[ArChie]

Aangezien er een hele waslijst met bugs niet is opgelost met de laatste firmware release voor de Humax IR-FOX C was ik wel benieuwd of ze ondertussen al bezig zijn met het testen van een nieuwe firmware versie voor deze ontvanger waarin die zaken nu eindelijk wel eens een keer worden opgepakt. Daarom maar weer eens handmatig de versie nummers van de firmware download kanalen gecontroleerd om te zien waar men op dit moment mee bezig is.

Onderstaand een overzicht van alle firmware download versies die in Ziggo/Multikabel gebied voor de betreffende ontvangers via een firmware download kanaal worden aangeboden:

code:

Humax iPVR-9200C:    29/07/2008 L005
Samsung DCB-P850R:   21/12/2007 L009
Siemens M750 C IR:   17/02/2007 L002
Nokia 119C:          27/02/2007 L004
Samsung DCB-9401R:   10/12/2007 L102
Philips DCR202x/03:  10/04/2007 L006
Samsung DCB-H360R:   01/07/2008 L007
Panasonic TU-DC40RD: 26/06/2006 L004
Samsung DCB-B270R:   28/02/2007 L013 (Test)
Humax IR-FOX C:      21/07/2008 L010
Digi1 STB-85 ir:     06/08/2007 L003
Cisco 8455DVB:       29/08/2008 L009
JVC LT-xxDC9B:       16/07/2008 L003
Humax HDTV PVR:      02/12/2008 L006 (Test)
Samsung HDTV:        21/11/2008 L007 (Test)

Voor de volgende Humax ontvangers/TV's ontbreekt in Ziggo/Multikabel gebied een firmware download kanaal:

code:

Humax IRHD-5000C
Humax LGB-23DC/NLS1
Humax LGB-32DRC/NLL2

Uit bovenstaand overzicht valt min of meer te concluderen dat er momenteel niet getest wordt met een nieuwe IR-FOX C firmware versie. Ook voor de Samsung DCB-9401R ontbreekt ieder spoor van een test firmware versie hoewel door Ziggo helpdeskmedewerkers al voor het uitbrengen van de huidige firmware versie werd gezegd dat Samsung voor deze ontvanger een firmware versie gaat uitbrengen die wel met meer dan 2 dagen aan volledige EPG informatie overweg kan. Maar zo te zien heeft Samsung het weer eens te druk met een nieuwe HDTV ontvanger die de DCB-H360R moet gaan vervangen. Loze toezeggingen dus.

Eigenlijk zou ik bovenstaand overzicht met een uitbreiding van mijn tooltje willen automatiseren. In tegenstelling tot bijvoorbeeld UPC gebruikt Ziggo uiteraard niet het standaard DVB protocol voor het verspreiden van firmware updates voor ontvangers, maar een eigen protocol waarvan ik tot op heden nog geen specificatie heb weten te vinden.

[Anoniem: 248134]

Archie,

Als er geen de software download voorkomt, dan wil dat niet altijd zeggen dat er niet getest wordt. In bepaalde situaties voeren we de testen in een gesloten omgeving uit of genereren we psi/si de-centraal, inclusief additionele TS'n, die anders is dan de streams die jij analyseert.
Voor de 9401 lopen wel testen, in januari wordt een laatste versie verwacht. Ten aanzien van nog aanwezige bugs op de IR-FOX nodig ik je graag uit een lijst met bugs te posten. Ik wil er zeker serieus naar kijken om te zien of er een nieuwe release voorbereid moet worden.

[ArChie]

Anoniem: 248134 schreef op woensdag 31 december 2008 @ 12:49:
Ten aanzien van nog aanwezige bugs op de IR-FOX nodig ik je graag uit een lijst met bugs te posten. Ik wil er zeker serieus naar kijken om te zien of er een nieuwe release voorbereid moet worden.

Sorry Anoniem, maar eerlijk gezegd begrijp ik dit verzoek van je niet. Bij de start van het gebruikers forum heb ik in het Humax IR-FOX C topic voor iedere toen bekende bug opnieuw topics aangemaakt in de hoop dat deze bugs niet vergeten zouden worden bij de overgang van het TV Home forum naar het gebruikers forum. Ik mag dan toch wel hopen dat jij of iemand anders die daarvoor binnen jullie bedrijf is aangewezen die punten op een buglist voor de Humax IR-FOX C zet, zoals dat hopelijk gebeurt voor iedere door jullie toegelaten ontvanger. Aangezien er, voor mijn gevoel tenminste, niets mee gedaan wordt heb ik sinds half december in aantal berichten in dit topic op het Gathering of Tweakers forum nog maar eens een keer alle niet opgeloste bugs voor de Humax IR-FOX C herhaald en nu moet weer een lijstje van gemaakt worden? Dat geeft mij niet bepaald de indruk dat jullie serieus bezig zijn met dit soort dingen. Als ik nu de enige was die opmerkt dat er nog steeds bugs in de Humax IR-FOX C zitten dan kan ik nog begrijpen dat jullie mij niet serieus nemen, maar ook op het gebruikers forum lees ik regelmatig over deze bugs.

Maar goed, ik zal ze nog een keer herhalen:

• De interne klok van de Humax IR-FOX C werkt niet / wordt niet gebruikt om de tijd up-to-date te houden waardoor er tijdens het zappen veelal geen present EPG informatie wordt getoond tot het moment dat er een TDT of TOT langs komt om de gepresenteerde tijd te updaten. Dat duurt bij Ziggo/Casema maximaal 10 seconden afhankelijk van het moment dat je begint met zappen en de tijd die verstreken is sinds het laatst verstuurde TOT of TDT pakketje. Ook tijdens het zappen wordt de interne klok niet door de Humax gebruikt om de aan de gebruiker gepresenteerde tijd in de informatie box bij te werken als die eenmaal een keer geupdate is door een TOT of TDT. Als je namelijk blijft zappen zonder steeds even te wachten op het verschijnen van beeld en geluid heeft de Humax het te druk om de TOT en TDT te verwerken. Voor iemand als ik die door de aan digitale TV inherente vertraging bij de opbouw van beeld en geluid voornamelijk zapt op basis van de getoonde present EPG informatie in de informatie box tijdens het zappen i.p.v. te wachten op beeld is dit een zeer irritante bug. Zie ook ArChie in "Digitale TV frequenties bij Ziggo Casema..."
• Het blijven hangen in de 4:3 aspect ratio wat alleen op te lossen is door of de ontvanger uit en aan te zetten of door even het menu in te gaan en weer te verlaten. Zie ook ArChie in "Digitale TV frequenties bij Ziggo Casema..."
• Na het zoeken in de EPG via de blauwe zoek functie knop is het beeld bevroren als je het EPG Guide overzicht verlaat. Zie ook ArChie in "Digitale TV frequenties bij Ziggo Casema..."
• Regelmatig geen geluid als ik langs het Zenderoverzichtskanaal naar Discovery Channel zap. Zie ook ArChie in "Digitale TV frequenties bij Ziggo Casema..."
• Hoewel ik zelf eigenlijk nooit de Timer functie gebruik vermoed ik dat door het niet gebruiken van een interne hardwarematige klok dat de timers ook wel niet op het juiste moment zullen afgaan in standby stand en/of tijdens het TV kijken (als reminder timers). Maar dat mogen jullie zelf onderzoeken.
• En verder alles wat ik vergeten ben of door mijn manier van gebruik niet ervaar, maar wel door jullie andere klanten genoemd is in het Humax IR-FOX C topic op het gebruikers forum.

[Anoniem: 248134]

bedankt voor je bijdrage

[ArChie]

Vanavond tijdens Mythbusters waren er weer eens haperingen in het beeld van Discovery Channel. Geen freezes, maar eerder het tijdelijk ontbreken van frame updates voor een deel van het beeld. Daarom maar eens besloten om een bitrate meting uit te voeren Transport Stream 12 waar Discovery Channel samen met maar liefst 8 andere kanalen is gepropt. Na een bitrate meting van zo'n 20 minuten zat de gemiddelde vrije ruimte voor het opvangen van bitrate pieken op zo'n 850 Kbps waar de gemiddelde bitrate aan het begin van de meting nog op 1.5 Mbps zat. Je kon de bitrate dus langzaam maar gestaag zien afnemen waarna het een beetje rond die 850 Kbps bleef hangen, maar ook kortstondig na een minuut of 10 zelfs gemiddeld onder de 800 Kbps zat. Het kan dus bijna niet anders dan dat er momenten zijn dat er geen vrije ruimte meer is om de bitrate pieken van de variabele bitrate van de kanalen op te vangen.

Conclusie: Transport Stream 12 zit gewoon te vol. Als Ziggo/Casema nu eens een 3 Mbps kanaal uit deze Transport Stream zou verhuizen naar een andere Transport Stream dan zouden er volgens mij geen problemen zijn met dit soort tijdelijke haperingen. The_Doman heeft het ook al meerdere keren opgemerkt bij ESPN. Bij Discovery Channel staat ook het beperken van de bitrate aan wat af en toe gewoon zichtbaar is als plotselinge optredende kortstondige onscherpheid rond bijvoorbeeld de ondertiteling. Met al die kanalen die zijn komen te vervallen is dit gedoe toch niet nodig?

[The_Doman]

ArChie schreef op donderdag 01 januari 2009 @ 21:38:
Conclusie: Transport Stream 12 zit gewoon te vol. Als Ziggo/Casema nu eens een 3 Mbps kanaal uit deze Transport Stream zou verhuizen naar een andere Transport Stream dan zouden er volgens mij geen problemen zijn met dit soort tijdelijke haperingen. The_Doman heeft het ook al meerdere keren opgemerkt bij ESPN.

Ik heb al een tijdje niet naar de zender EPSN Classic gekeken maar toen ik dit bericht las heb ik deze zender toch maar weer even opgezet.
En inderdaad zijn de eerder gemelde storingen, regelmatig terugkerende blokjes/glitches, dus nog steeds onveranderd aanwezig bij deze zender!

Zie ook deze melding op het Ziggo-Gebruiker Forum van 12 Mei 2008:
Ziggo-Gebruikers.nl Forum: ESPN Classic: Regelmatig Terugkerende Storingen (glitches/dropouts)

[ArChie]

The_Doman schreef op donderdag 01 januari 2009 @ 22:05:
Ik heb al een tijdje niet naar de zender EPSN Classic gekeken maar toen ik dit bericht las heb ik deze zender toch maar weer even opgezet.
En inderdaad zijn de eerder gemelde storingen, regelmatig terugkerende blokjes/glitches, dus nog steeds onveranderd aanwezig bij deze zender!

Het is gewoon triest dat Ziggo/Casema dit probleem maar blijft negeren. Als alle Transport Streams nu vol zouden zitten dan zou je daar misschien nog begrip voor op kunnen brengen, maar dat is zeker niet het geval dus is dit in mijn ogen gewoon een gevalletje van je klanten niet serieus nemen. Een bekend probleem bij Ziggo/Casema.

Edit: Ik heb de geschiedenis van dit gedoe met Transport Stream 12 nog eens teruggelezen op het TV Home forum. Binnenkort op 26 januari 2009 duurt deze klucht alweer een jaar sinds de eerste melding van deze problemen.

[ Voor 13% gewijzigd door ArChie op 01-01-2009 23:04 ]

[ArChie]

Even een korte bitrate meting uitgevoerd om te achterhalen wat de vrije ruimte is in alle Transport Streams. Zie onderstaand overzicht:

code:

TS  1:  7.0 Mbps
TS  2:  4.2 Mbps
TS  3:  0.8 Mbps
TS  4:  5.3 Mbps
TS  5:  5.8 Mbps
TS  6:  6.2 Mbps
TS  7:  8.8 Mbps
TS  8:  3.9 Mbps
TS  9:  5.7 Mbps
TS 10:  4.1 Mbps
TS 11:  1.9 Mbps
TS 12:  0.8 Mbps
TS 13:  8.1 Mbps
TS 14:  6.7 Mbps
TS 15:  4.4 Mbps
TS 16:  2.5 Mbps
TS 17:  3.4 Mbps
TS 18: 16.6 Mbps
TS 19:  4.5 Mbps
TS 20:  2.0 Mbps
TS 21:  4.1 Mbps
TS 22:  2.4 Mbps
TS 23: 15.6 Mbps
TS 24:  6.9 Mbps
TS 25:  5.7 Mbps
TS 26:  7.2 Mbps

Uit bovenstaand lijstje blijkt dat er nog meer Transport Streams zijn die in de gevaren zone zitten, namelijk TS 3 en TS 11. TS 3 spant overigens de kroon voor wat betreft het kanalen proppen door Ziggo/Casema, maar liefst 10 digitale TV kanalen. Transport Streams met 6 Mbps of meer aan vrije ruimte kunnen met gemak een 3 Mbps kanaal uit de te volle Transport Streams overnemen.

[ArChie]

Sowieso blijkt uit het vrije ruimte overzicht van de vorige post dat er bij Ziggo/Casema nu niet bepaald sprake is van een optimale kanalen verdeling over alle beschikbare Transport Streams. Per 1 januari hadden trouwens een zestal kanalen verdwenen moeten zijn waarvoor nog wel steeds een signaal wordt doorgegeven en die dus nog steeds een deel van de beschikbare bitrate in een Transport Stream voor zich opeisen. Het gaat om de volgende kanalen:

code:

Nederland-E:      4.0 Mbps in TS 5
BravaHD:          1.3 Mbps in TS 23
Dier & Natuur TV: 4.0 Mbps in TS 23
3voor12 Central:  0.2 Mbps in TS 24
3Voor12 On stage: 0.2 Mbps in TS 24
Omega TV:         4.0 Mbps in TS 25

Het vrije ruimte overzicht van de vorige post moet nog gecorrigeerd worden met deze informatie. De vrije ruimte in TS 5, 23, 24 en 25 wordt dan:

code:

TS  5:  9.8 Mbps
TS 23: 16.9 Mbps
TS 24:  7.3 Mbps
TS 25:  9.7 Mbps

Verder schijnt binnenkort eindelijk de langverwachte firmware update voor de Samsung DCB-9401R uit te komen zodat dan eindelijk het aantal dagen volledige EPG informatie omhoog kan. Twee dagen volledig EPG informatie neemt bij Ziggo/Casema zo'n 0.5 Mbps aan bitrate in beslag. Bij het opvoeren van het aantal dagen volledige EPG kan je dan al snel rekenen op een bitrate van zo'n 1.5 Mbps. In iedere Transport Stream zal dus rekening moeten worden gehouden met 1 Mbps extra voor de EPG informatie waardoor TS 16, TS 20 en TS 22 ook in de problemen komen, naast de al genoemde TS 3, TS 11 en TS 12.

Het wordt dus hoog tijd dat Ziggo/Casema de verdeling van de kanalen over de beschikbare Transport Streams weer eens gaat optimaliseren gezien de huidige problemen en wijzigingen i.p.v. passief te hopen dat de problemen zich vanzelf oplossen. Bij Ziggo/@Home schijnt men wel een actief beleid te hebben om de kanalen verdeling optimaal te houden waarbij zelfs het streven is om geen bitrate beperkingen op de kanalen te gebruiken zoals bij Ziggo/Casema wel veelvuldig wordt toegepast om zoveel mogelijk kanalen in een Transport Stream te kunnen proppen. Aangezien er bij Ziggo/@home evenveel digitale kanalen worden doorgegeven in dezelfde hoeveelheid Transport Streams lijkt het mij de meest logische en voor de hand liggende oplossing dat Ziggo/Casema dan de optimale kanalen verdeling van Ziggo/@Home overneemt. Dan hoeft Ziggo/Casema niet te experimenteren met een nieuwe kanalenverdeling wat weer tot ergernis bij de klanten gaat leiden door allerlei storingen omdat Ziggo/Casema weer de bitrate beperkingen van allerlei kanalen gaat opschroeven om de boel toch passend te maken met de bekende beeldkwaliteitsproblemen tot gevolg. Bijkomend voordeel is dat er ook direct voor gezorgd kan worden dat de Ziggo/@Home en Ziggo/Casema/Multikabel abonnees dezelfde beeldkwaliteit krijgen wat al tijden wordt beloofd. Het is dan immers niet meer nodig dat Ziggo/Casema de bitrates van kanalen (meer) knijpt terwijl dat bij Ziggo/@Home als het even kan niet gebeurt. Ook lijkt een gelijke kanalen verdeling mij handig als de headends van Ziggo/Casema en Ziggo/@Home elkaars backup moeten kunnen zijn.

[ArChie]

Even gekeken of er op de Storingen pagina van de Ziggo website nog iets gemeld wordt over de problemen met de kanalen in Transport Stream 12. Uiteraard zoals verwacht niets over terug te vinden.

Op de home pagina van de Ziggo website zie ik nog een link staan naar een prijsvraag. Voor de aardigheid eens op geklikt en wat krijg je dan:



Wat blijkt na wat experimenteren: Elke keer dat je op de home pagina van Ziggo terecht komt sturen ze je door naar een andere prijsvraag pagina. Op de Games prijsvraag pagina (http://games.ziggo.nl/prijsvraag.asp) is er geen prijsvraag, maar bijvoorbeeld op de Muziek prijsvraag pagina (http://muziek.ziggo.nl/prijsvraag.asp) wel. Stuur mensen dan dus niet door naar de Games prijsvraag pagina als er toch geen prijsvraag is. Is er dan helemaal niets bij Ziggo dat wel gewoon volgens verwachting werkt?

[ArChie]

Ook vanavond weer een paar haperingen gezien tijdens Overhaulin' op Discovery Channel. Een paar keer een bitrate meting uitgevoerd om te controleren hoe het er voor stond met de vrije ruimte in Transport Stream 12. Daarbij was het dieptepunt van één van de metingen dat er nog een gemiddelde bitrate van 460 Kbps aan vrije ruimte was voor het opvangen van bitrate pieken van de negen kanalen. Ziggo/Casema heeft hier dus vandaag of niets aangedaan of ze zijn weer aan het experimenteren met hogere bitrate beperkingen van de kanalen in deze TS wat niet heeft geholpen.

[The_Doman]

ArChie schreef op woensdag 31 december 2008 @ 14:12:
• Hoewel ik zelf eigenlijk nooit de Timer functie gebruik vermoed ik dat door het niet gebruiken van een interne hardwarematige klok dat de timers ook wel niet op het juiste moment zullen afgaan in standby stand en/of tijdens het TV kijken (als reminder timers). Maar dat mogen jullie zelf onderzoeken.

Zowel de Humax IR-FOX C en Humax IRHD-5000 decoders hebben last van deze timer/standby bugs waardoor ze niet te gebruiken zijn voor (betrouwbare) opnames met een externe HD/DVD recorder!

Hopenlijk worden deze problemen nu eens echt opgelost bij de volgende firware updates!

Zie voor verduidelijking van deze problemen ook de volgende links:

Ziggo-Gebruikers.nl - Vraag: Humax Standby Timer
Ziggo-Gebruikers.nl: digitale TV zenders instellen via timer HDD-recorder

Originally Posted by Roedie
Ik heb het een keer of drie uitgeprobeerd via de timer/standby functie van de Humax en "sychro opname" via de Sony HDD-recorder.

Zoals je al aangaf ging het alle keren niet goed.

Een keer startte de Humax op tijd op maar bleef vervolgens doorgaan na de door mij ingestelde eindtijd.

Twee andere keren deed ie helemaal niks...

Ik ben er van overtuigd dat ik alle instellingen goed had staan.

Ik hoop dat ze deze bug er uit kunnen halen want het is eigenlijk best irritant. Ik kan nu dus geen digi opnames via de timer instellen. De enige mogelijkheid is er zelf terplekke bij zijn...

[ArChie]

The_Doman schreef op zaterdag 03 januari 2009 @ 00:16:
Zowel de Humax IR-FOX C en Humax IRHD-5000 decoders hebben last van deze timer/standby bugs waardoor ze niet te gebruiken zijn voor (betrouwbare) opnames met een externe HD/DVD recorder!

Hopenlijk worden deze problemen nu eens echt opgelost bij de volgende firware updates!

Ik zou er maar niet te veel op rekenen. Ik heb het Humax IRHD-5000C gebeuren een beetje gevolgd op het gebruikers forum en daar zie je precies hetzelfde van de Ziggo medewerkers als waar onlangs ook sprake van was in dit topic over de IR-FOX C. Ze houden zelf namelijk geen bug lijstjes bij voor de door hun goedgekeurde ontvangers waarin ze de punten opnemen die door de gebruikers genoemd worden op de forums. Ook bij de Humax IRHD-5000C moest een klant weer een lijstje maken nadat er gevraagd werd of in de aangekondigde bugfix release ook direct alle andere bugs werden opgelost. De essentie van de bugfix release voor de IRHD-5000C was volgens een Ziggo medewerker immers een aanpassing aan het standby gebeuren zodat de gebruiker nu kan kiezen of er wel of niet gebruik moet worden gemaakt van de "groene" slaapstand omdat de Humax anders wat langzaam opstart wat negatief kan zijn voor de verkoop aantallen. Zeg maar net zo'n soort bugfix als er destijds voor de Samsung DCB-P850R vrij snel na de introductie uitkwam om de fan wat lager te zetten omdat die wat veel herrie maakte.

Als je ook maar enigszins interesse hebt voor hetgeen er over de Humax IRHD-5000C geschreven wordt op de diverse forum dan springen twee dingen eruit, namelijk de tegenvallende beeldkwaliteit bij het kijken naar SD kanalen en het niet (goed) werken van de timers. Beide zaken die niet eenvoudig te fixen zijn, maar al voor de release van deze ontvanger ontdekt hadden moeten worden tijdens het testen. Voor goedkeuring door Ziggo is het alleen van belang of er wat beeld en geluid uit zo'n ontvanger komt. De scaler van de Humax IRHD-5000C is duidelijk slechter dan de scalers die je tegenwoordig in de TV's aantreft. Dat blijkt ook wel als ik lees dat het door de TV opgeschaalde beeld van SD kanalen beter is als de IRHD-5000C die via SCART wordt aangesloten. Dat Ziggo een ontvanger niet afkeurt omdat de beeldkwaliteit tegenvalt is te begrijpen, maar zorg er dan voor dat de Original modus van IRHD-5000C waarover in de handleiding gesproken wordt werkt zodat klanten niet afhankelijk zijn van die inferieure scaler en dat is functionaliteit die ze wel kunnen testen en keuren. Maar als ik de uitspraken van Ziggo medewerkers op het gebruikers forum lees dan kan ik daar niet uit opmaken dat ze er ook voor gaan zorgen dat de Original modus gaat werken zonder dat je daar elke keer opnieuw een workaround achtig truukje voor moet gebruiken om die Original modus toch aan de praat te kijgen.

Ik heb het al vaker geroepen, maar dat hele "gecertificeerde" ontvangers gebeuren en de daaraan gekoppelde "ondersteuning" van Ziggo is een wassen neus. Het enige dat van belang is voor Ziggo is dat de ontvangers eerst bij hun langs komen zodat ze allerlei functionaliteit die ze niet willen kunnen laten uitschakelen en verplicht functionaliteit kunnen laten toevoegen zodat zij meer controle krijgen over de ontvanger krijgen. Dat die ontvanger niet doet wat er in de handleiding staat, of functionaliteit die je normaliter van een ontvanger zoals werkende timers interesseert ze helemaal niets totdat er te veel over geklaagd wordt. Dan wordt er aangegeven dat ze er serieus naar gaan kijken, maar ondertussen gebeurt er weer niets en hopen ze dat het geklaag vanzelf weer zal verstommen.

[ArChie]

Nog een goed voorbeeld van het niet serieus nemen van klachten van klanten over de door Ziggo goedgekeurde ontvangers is de Cisco 8455DVB HDTV VOD PVR. Ziggo/Casema is nu ondertussen al anderhalf jaar bezig met de ontwikkeling van deze ontvanger en de bijbehorende diensten die via het OpenTV middleware platform worden aangeboden zoals Video on Demand toepassingen. Ziggo noemt dat "Interactieve TV", maar deze term is voorlopig nog niet van toepassing op hetgeen Ziggo nu aan diensten biedt. In juli van 2008 zijn de eerste Cisco 8455DVB aan klanten in het Ziggo/Casema gebied uitgeleverd en zoals gewoonlijk was direct al duidelijk dat er snel een firmware update moest komen gezien alle bugs die deze early adopters in dit door Ziggo/Casema "grondig geteste" en "gecertificeerde" product werden gevonden. Ook na die firmware update zijn er nog steeds vele bugs en ontbrekende standaard PVR functionaliteit waar nauwelijks op gereageerd wordt door Ziggo/Casema. Een aantal early adopters van de Cisco 8455DVB zijn daarom van mening dat deze buggy ontvanger nog lang niet gereed en/of niet geschikt is voor grootschalige introductie.

Daar trekt Ziggo/Casema zich uiteraard niets van aan. In plaats van deze ervaringsdeskundigen serieus te nemen en er eerst voor te zorgen dat er weer een firmware update uitkomt waarin alle openstaande punten worden opgelost gaan ze nu via een marketing actie een "testpanel" van klanten inzetten om de Cisco 8455DVB aan de man te brengen waar uiteraard de early adopters niet aan mee mogen doen want die weten allang dat de Cisco 8455DVB niet voldoet. Sterker nog, om onnodig meer test resultaten te krijgen mogen ook de personeelsleden van Ziggo voor een sterk gereduceerd tarief mee doen getuige het volgende bericht op de DutchMedia Weblog:

quote: DutchMedia

“Er is op dit moment maar één apparaat beschikbaar voor interactieve diensten. Dat is de Cisco 8455 DVB. Voor de lancering in ons hele gebied komt er nog een ontvanger van Samsung beschikbaar. Deze zal goedkoper zijn dan de Cisco 8455 DVB, maar heeft daardoor geen PVR-functies,” aldus de Ziggo-woordvoerder. De Cisco-ontvanger is thans alleen via Ziggo verkrijgbaar voor Ziggo-klanten in het Westelijk deel voor de prijs van 408,50 (inclusief verzendkosten). De Ziggo-woordvoerder stelt dat er thans een voorraad van circa 7000 Cisco-ontvangers in huis is, waar de directie van Ziggo van besloten heeft dat personeelsleden deze met korting kunnen aanschaffen, mede als doel om meer ‘testers’ te verkrijgen. De prijs voor de personeelsleden zou 150 euro bedragen.

Leuk van de Ziggo directie natuurlijk dat ze hun personeelsleden een cadeautje geven van 250 euro, maar ik vraag mij af wat de Belastingdienst daar van vindt. Het is volgens mij namelijk een verkapt soort loon. Maar goed, als Ziggo/Casema nu oprecht wilde weten wat er allemaal mis is met hun Cisco 8455DVB ontvanger dan hoeven ze alleen maar op het gebruikersforum te kijken en weten ze dat al deze zogenaamde test acties niet erg zinvol zijn gezien alle bugs en problemen die nu al bekend zijn. Maar het doel is om Cisco ontvangers aan de man te brengen.

[Anoniem: 248134]

ArChie schreef op zaterdag 03 januari 2009 @ 10:21:
[...]

Maar als ik de uitspraken van Ziggo medewerkers op het gebruikers forum lees dan kan ik daar niet uit opmaken dat ze er ook voor gaan zorgen dat de Original modus gaat werken zonder dat je daar elke keer opnieuw een workaround achtig truukje voor moet gebruiken om die Original modus toch aan de praat te kijgen.

Ik heb het al vaker geroepen, maar dat hele "gecertificeerde" ontvangers gebeuren en de daaraan gekoppelde "ondersteuning" van Ziggo is een wassen neus. Het enige dat van belang is voor Ziggo is dat de ontvangers eerst bij hun langs komen zodat ze allerlei functionaliteit die ze niet willen kunnen laten uitschakelen en verplicht functionaliteit kunnen laten toevoegen zodat zij meer controle krijgen over de ontvanger krijgen. Dat die ontvanger niet doet wat er in de handleiding staat, of functionaliteit die je normaliter van een ontvanger zoals werkende timers interesseert ze helemaal niets totdat er te veel over geklaagd wordt. Dan wordt er aangegeven dat ze er serieus naar gaan kijken, maar ondertussen gebeurt er weer niets en hopen ze dat het geklaag vanzelf weer zal verstommen.

De "orginal" mode wordt wel meegenomen in de nieuwe release.
Verder blijf je erg je best doen om het ziggo beleid voortdurend in een kwaad daglicht te stellen en daarbij voordurend halve waarheden te vertellen.

[ArChie]

Het lijkt erop dat ze toch weer iets geprobeerd hebben bij Ziggo/Casema met betrekking tot het haperen van Discovery Channel in Transport Stream 12. En degenen die al sinds 26 januari 2008 dit gedoe met de te vol gepropte Transport Stream 12 volgen kunnen waarschijnlijk wel raden wat Ziggo/Casema geprobeerd heeft, namelijk het verder beperken van de bitrates van sommige kanalen om de boel toch weer passend te krijgen. Er is in ieder geval geen kanaal verplaatst uit deze Transport Stream 12, maar toch is de vrije bitrate ruimte sinds gisteren toegenomen naar zo'n 3.2 Mbps terwijl het de dagen daarvoor nog maar een schamele 0.8 Mbps of zelfs lager was bij diverse metingen. Daaruit kan alleen maar geconcludeerd worden dat de bitrate van de video streams van de kanalen omlaag moet zijn gegaan om die ruimte te maken.

Belangrijkste slachtoffer lijkt TV Flevoland te zijn. Op het moment van de haperingen bij Discovery Channel stond dit kanaal nog bovenaan de bitrate lijst met een gemiddelde bitrate van meer dan 5.1 Mbps en nu is het kanaal opeens gezakt naar de tweede plek van onderen met 2.7 Mbps. Tijdens een fysieke controle van het TV Flevoland kanaal al meerdere keren gezien dat dit kanaal hapert met korte freezes. De bitrate van Discovery Channel lijkt iets verhoogd te zijn aangezien dit kanaal nu rond de 4 Mbps haalt en daarmee op de tweede plek komt, terwijl het tijdens de haperingen nog op de zesde plek in de rangorde van deze Transport Stream stond. Doordat er geen ruimte is gecreëerd voor Discovery Channel door het verplaatsen van een kanaal zal er natuurlijk wel weer een kanaal zijn dat daarvoor heeft moeten inleveren. Omroep Zeeland staat nog steeds op de laatste plaats met een bitrate van 1.7 Mbps. ESPN Classic is niet van plek verandert.

Ook voor Transport Stream 3 met de 10 digitale TV kanalen geldt dat de vrije ruimte opeens is toegenomen naar 2.7 Mbps terwijl het ook 0.8 Mbps was tijdens diverse metingen. Ook daar is geen enkel kanaal verhuist naar een andere Transport Stream, dus ook daar kan dat alleen bereikt zijn door de bitrate van de kanalen verder te beperken.

Deze ingrepen gaan uiteraard niet helpen, dat weet ondertussen iedereen die deze langdurige geschiedenis volgt. Met uitzondering natuurlijk van Ziggo/Casema dat kennelijk maar niet wil leren van dit telkens weer terugkerende gedoe.

[The_Doman]

Houd het geklooi dan nooit op bij Ziggo/Multikabel?
Nu loopt de Siemens PVR decoder hier weer vast wanneer ik langs wat zenders zap??

Ziggo-Gebruikers Forum - Siemens Gigaset M750 C IR (PVR): Error E102-29 -> i34-9

Ziggo/Multikabel, Siemens PVR M750, 06-01-2009

[ Voor 65% gewijzigd door The_Doman op 07-01-2009 12:12 ]

[ArChie]

The_Doman schreef op dinsdag 06 januari 2009 @ 20:11:
Houd het geklooi dan nooit op bij Ziggo/Multikabel?
Nu loopt de Siemens PVR decoder hier weer vast wanneer ik langs wat zenders zap??

Net even een Transport Stream capture file gemaakt van TS 6 waarin Veronica zit. Ik kan niet direct iets vinden waarvan ik met zekerheid kan zeggen dat het niet klopt. Het enige dat me opvalt is het volgende:

├─■  CMT  {  CA  Message  Table  }
│  └─■  transport_stream_ID  =  6
│      ├─■  CA  PID  4000
│      │  ├─■  transport_stream_ID  =  6
│      │  ├─■  CA_PID  =  4000
│      │  └─■  sections:  {  Required  sections:  1,  available  sections:  1  }
│      │      └─■  section  {  0/0  }
│      │          ├─■  unknown_byte_value_1  =  73
│      │          ├─■  section_number  =  0
│      │          ├─■  last_section_number  =  0
│      │          ├─■  channel_ID  =  65535
│      │          ├─■  unknown_byte_value_2  =  0
│      │          ├─■  unknown_byte_value_3  =  0
│      │          ├─■  unknown_byte_value_4  =  128
│      │          └─■  CA_data  =  0000    7A  82  51  00  65  8A  D7  53  DD  5E  F7  71  46  7C  B1  C1    z.Q.e..S.^.qF|..
│      │                                      0010    45  E8  77  6D  00  FC  30  DE  B8  06  5A  9F  D9  77  98  D8    E.wm..0...Z..w..
│      │                                      0020    2E  67  E7  A7  25  AB  FB  BC  DE  15  EA  D9  B4  BD  93  6F    .g..%..........o


De unknown_byte_value_1 waarde van de CA Message Table (CMT) in het bovenstaande voorbeeld voor Veronica is 73, terwijl dit in andere Transport Streams waar ik recent een capture file van had gemaakt nog 71 was voor de kanalen die Ziggo/Casema tijdelijk open heeft gezet voor ongeregistreerde smartcards. Het probleem is dat ik helaas recent niet ook nog een capture file van TS 6 had gemaakt zodat ik niet met zekerheid kan zeggen dat die waarde een paar dagen geleden bijvoorbeeld ook op 71 stond bij Veronica i.p.v. 73 zoals dat nu is. Verder is de betekenis van dat unknown_byte_value_1 mij niet bekend, dus misschien zit ik wel op een totaal verkeerd spoor.

Ze blijven helaas maar klooien bij Ziggo/Casema zonder dat ze eens een keer eerlijk tekst en uitleg komen geven wat er nu precies fout gaat met de I34-9 foutmelding die met enige regelmaat te voorschijn komt bij de Siemens PVR.

[The_Doman]

ArChie schreef op dinsdag 06 januari 2009 @ 21:18:
[...]

Net even een Transport Stream capture file gemaakt van TS 6 waarin Veronica zit. Ik kan niet direct iets vinden waarvan ik met zekerheid kan zeggen dat het niet klopt.

Het probleem treedt ook niet alleen op bij de zender veronica merk ik nu.
Ook bij het rondzappen langs diverse andere zenders loopt de Siemens PVR momenteel al snel totaal vast.
Zappen kan dan nog wel en er is beeld bij het Ziggo overzichtskanaal (12) en regio22 (975) maar de softcam/decoder lijkt er dan mee op te zijn gehouden aangezien het ledje van de smartcardlezer dan ook geen activiteit meer laat zien?.
Volledig uitschakelen is dan nog de enige oplossing om de boel weer (even) aan de gang te krijgen.
Afwachten dus maar weer of ze kunnen achterhalen wat er nu weer is gewijzigd in het systeem?

[ArChie]

The_Doman schreef op dinsdag 06 januari 2009 @ 21:42:
Het probleem treedt ook niet alleen op bij de zender veronica merk ik nu.
Ook bij het rondzappen langs diverse andere zenders loopt de Siemens PVR momenteel al snel totaal vast.

Loopt hij ook vast bij Discovery Channel? Want daar het ik wel een recente TS capture file van die dateert van 4 januari. Als het daar nu ook optreed dan zou ik een nieuwe capture file kunnen maken om te vergelijken.

Zappen kan dan nog wel en er is beeld bij het Ziggo overzichtskanaal (12) en regio22 (975) maar de softcam/decoder lijkt er dan mee op te zijn gehouden aangezien het ledje van de smartcardlezer dan ook geen activiteit meer laat zien?.

Sowieso zijn I34 of E34 altijd aanwijzingen dat de ontvanger om wat voor een reden dan ook het kanaal niet (goed) kan decrypten. Kennelijk gaat de Siemens PVR volledig over zijn nek van iets dat niet lekker zit in de data waardoor SoftCell softCAM library ook de smartcardlezer niet meer aanspreekt om de smartcard te benaderen.

[The_Doman]

The_Doman schreef op dinsdag 06 januari 2009 @ 20:11:
Houd het geklooi dan nooit op bij Ziggo/Multikabel?
Nu loopt de Siemens PVR decoder hier weer vast wanneer ik langs wat zenders zap??

Ziggo-Gebruikers Forum - Siemens Gigaset M750 C IR (PVR): Error E102-29 -> i34-9

De bewuste storing is zo te zien weer (snel) opgelost?
Momenteel heb ik hier geen problemen meer bij het zappen.
Blijkbaar is er toch weer iets ten goede gewijzigd waardoor de Siemens PVR niet meer vastloopt.

[ArChie]

The_Doman schreef op woensdag 07 januari 2009 @ 12:06:
De bewuste storing is zo te zien weer (snel) opgelost?
Momenteel heb ik hier geen problemen meer bij het zappen.
Blijkbaar is er toch weer iets ten goede gewijzigd waardoor de Siemens PVR niet meer vastloopt.

Het heeft dan in ieder geval niets te maken met die unknown_byte_value_1 in de CA Message Table (CMT), want die is nog hetzelfde als gisteren.

De enige wijziging die ik op dit moment zie is dat de volgorde van de Irdeto CA_system_ID's in de Conditional Access Table (CAT) zijn omgedraaid van Transport Stream 6 waar Veronica en RTL 8 in zitten. Gisteren was het eerst de CA_system_ID voor het Multikabel Irdeto CAS (1540) en daarna die van Casema Irdeto CAS (1538).

Vandaag is het eerst het Casema Irdeto CAS en daarna het Multikabel CAS, zie onder:

├─■  CAT  {  Conditional  Access  Table  }
│  └─■  transport  stream  ID  6,  version  2
│      ├─■  transport_stream_id  =  6
│      ├─■  version_number  =  2
│      └─■  sections:  {  Required  sections:  1,  available  sections:  1  }
│          └─■  section  {  0/0  }
│              ├─■  section_number  =  0
│              ├─■  last_section_number  =  0
│              └─■  descriptors:
│                  ├─■  ca_descriptor
│                  │  ├─■  CA_system_ID  =  1538
│                  │  └─■  CA_PID  =  48
│                  └─■  ca_descriptor
│                      ├─■  CA_system_ID  =  1540
│                      └─■  CA_PID  =  53

Misschien kan de Siemens er niet tegen als de CA_system_ID's in de CAT niet in een oplopende volgorde staan? In Transport Stream 19 voor de overige RTL's en SBS 6 stond die volgorde in de CAT gisterenavond wel gewoon oplopend en daar hadden jullie geen last met een vastlopende Siemens PVR. Iets om in de gaten te houden als het weer eens fout gaat met die I34 meldingen bij de Siemens. Als het er dan weer iets veranderd is in de CAT dan zal het er waarschijnlijk wel iets mee te maken hebben.

[B.A.L.]

Ik weet niet of dit wel het goeie topic is voor mn vraag maar kon even snel geen betere vinden, en het leek me geen eigen topic waard, dus ik stel hem hier maar.

We hebben thuis een kabelverbinding van Ziggo, die wordt gesplit, 1 beneden en 1 gaat naar boven. We hebben het digitale televisie abonnement, en hebben daar een decoder en smartcard bij gekregen, en die staat beneden te shinen. Boven wil ik echter ook digitale kwaliteit. Paar vraagjes;

-Kan ik met het digitale televisie abonnement 2 TV's digitaal krijgen? ( ik geloof het wel, maar even voor de zekerheid vragen)
-Zo ja, heb ik dan alleen een decoder nodig, of moet er ook een smartcard in?
-Weet iemand waar ik een decoder (en eventuele smartcard) goedkoop kan halen?
-Bij digitaal zit standaard 2 HD zenders dacht ik, is het het dan waard om een HD decoder te halen of zijn die echt veel duurder?

Ik zag wel dat Ziggo nu een geld terug actie heeft (http://www.ziggo.nl/producten/televisie/digitale-ontvangers/), maar dan nog is het digitale pakket 75 eu, en HD 150 eu...vind ik wat veel.

[Friedchicken]

B.A.L. schreef op donderdag 08 januari 2009 @ 15:58:
1) Kan ik met het digitale televisie abonnement 2 TV's digitaal krijgen? ( ik geloof het wel, maar even voor de zekerheid vragen)
2) Zo ja, heb ik dan alleen een decoder nodig, of moet er ook een smartcard in?
3) Weet iemand waar ik een decoder (en eventuele smartcard) goedkoop kan halen?
4) Bij digitaal zit standaard 2 HD zenders dacht ik, is het het dan waard om een HD decoder te halen of zijn die echt veel duurder?

Ik zag wel dat Ziggo nu een geld terug actie heeft (http://www.ziggo.nl/producten/televisie/digitale-ontvangers/), maar dan nog is het digitale pakket 75 eu, en HD 150 eu...vind ik wat veel.

1) Ja
2) Decoder + Smartcard + (eventueel extra) abbonement
3) Lokale boer, prijzen rond 99 SD decoder en 199 HD decoder
4) Ik zou HD decoder kiezen, momenteel maar 1 HD zender vrij te ontvangen en dat is Eurosport. Rest zit in HD pakket. Eind maart Ned 1,2 en 3 ook in HD te ontvangen. Of die in een pakket komen? Geen idee

Update: Op het ziggo-gebruikers.nl forum lees ik dat abbonementen gelijk getrokken worden op alle smartcards binnen 1 registratie-adres. Dus je neemt Film1 abbo, dan heb je dit op al je smartcards. Dit zou in moeten gaan per 1 maart. Ziggo kennende, ik ben erg benieuwd. Ze zullen wel met een extra vast bedrag per maand per kaart gaan komen...

[ Voor 14% gewijzigd door Friedchicken op 08-01-2009 19:17 ]

[Anoniem: 261170]

Friedchicken schreef op donderdag 08 januari 2009 @ 16:56:
[...]


1) Ja
2) Decoder + Smartcard + (eventueel extra) abbonement
3) Lokale boer, prijzen rond 99 SD decoder en 199 HD decoder
4) Ik zou HD decoder kiezen, momenteel maar 1 HD zender vrij te ontvangen en dat is Eurosport. Rest zit in HD pakket. Eind maart Ned 1,2 en 3 ook in HD te ontvangen. Of die in een pakket komen? Geen idee

Over punt 2.
In december kreeg ik van de Ziggo helpdesk te horen dat vanaf 1 januari 2009 ook alle extra paketten waarvoor je al betaalde op je 1ste smartcard, kosteloos op je 2de smartcard geactivieerd worden.
Telefoontje naar helpdesk Ziggo zou voldoende moeten zijn. Ik heb nog geen tijd gehad om het aan te vragen maar ga het op korte termijn zeker doen.

[B.A.L.]

Ok, het is duidelijk, bedankt!

Ik zag trouwens dat als je bij Ziggo een alles-in-1 pakket neemt (we hebben nu televisie, internet en telefonie los), dat de HD decoder dan maar 99 eu is...da's helemaal ideaal. Morgen maar eens even met paps overleggen of hij zin heeft om het abonnement over te zetten

[ArChie]

Ondertussen zijn we weer vier dagen verder en de problemen met Transport Stream blijven maar voortduren. Zojuist weer even een bitrate meting gehouden en ze hebben het bij Ziggo/Casema nu voor elkaar om zo'n 4.2 Mbps aan vrije ruimte te creëeren zonder kanalen te verplaatsen. Met andere woorden nog meer bitrate beperkingen en kennelijk hebben ze ook bovengrenzen voor de maximum bitrate van de kanalen ingesteld want nog steeds loopt TV Flevoland van tijd tot tijd vast en ook al weer een paar haperingen op Discovery Channel gezien. Het interesseert ze gewoon totaal niets daar bij Ziggo/Casema.

[ArChie]

Sinds Ziggo/Casema weer aan het klooien is met extra bitrate beperkingen voor de kanalen in onder andere de Transport Stream 12 is er bij Discovery Channel weer goed zichtbaar wat dat voor een consequenties heeft voor de beeldkwaliteit. Tegenwoordig zijn weer alle nuances in rode kleur vlakken in het beeld verdwenen waardoor het de kleur rood zeer nadrukkelijk en onwerkelijk in het beeld aanwezig is. Het is net alsof iemand met PaintShop alles wat rood is in het beeld vervangen heeft door één egale rood tint waarmee het diepte effect verloren gaat doordat schaduwen en lichtere en donkere delen in de rode vlakken ontbreken.

Rode vlakken worden doordat het één egaal rood vlak is geworden zonder lichtere en donkere roodtintend ook zeer onrustig in het beeld. Normaal zijn er immers door de verschillende roodtinten geleidelijke overgangen van de rode vlakken in het beeld naar andere kleuren, maar nu zijn die geleidelijke overgangen verdwenen waardoor het rode vlak zich schokkend beweegt t.o.v. de rest van het beeld bij camera bewegingen.


Het programma Overhaulin' dat te zien is op Discovery Channel heeft bijvoorbeeld veel rood in het logo en dat logo is nogal veel in beeld waardoor dit negatieve effect van het gerommel aan de bitrates door Ziggo/Casema behoorlijk irritant begint te worden. Helaas interesseert het ze bij Ziggo/Casema geen moer dat ze met hun bitrate beperkingen de beeldkwaliteit vernaggelen.

[The_Doman]

ArChie schreef op donderdag 08 januari 2009 @ 20:06:
Ondertussen zijn we weer vier dagen verder en de problemen met Transport Stream blijven maar voortduren. Zojuist weer even een bitrate meting gehouden en ze hebben het bij Ziggo/Casema nu voor elkaar om zo'n 4.2 Mbps aan vrije ruimte te creëeren zonder kanalen te verplaatsen. Met andere woorden nog meer bitrate beperkingen en kennelijk hebben ze ook bovengrenzen voor de maximum bitrate van de kanalen ingesteld want nog steeds loopt TV Flevoland van tijd tot tijd vast en ook al weer een paar haperingen op Discovery Channel gezien. Het interesseert ze gewoon totaal niets daar bij Ziggo/Casema.

De storingen bij ESPN Classic duren ook nog steeds onverminderd voort.
Naast de dramatisch slechte beeldkwaliteit zijn de regelmatig terugkerende A/V glitches/dropouts nog steeds aanwezig.

Ziggo/Multikabel, ESPN Classic, 08-01-2009


Ziggo/Multikabel, ESPN Classic, 08-01-2009


Ziggo/Multikabel, ESPN Classic, 08-01-2009


Ziggo/Multikabel, ESPN Classic, 08-01-2009


Ziggo/Multikabel, ESPN Classic, 08-01-2009


Ziggo/Multikabel, ESPN Classic, 08-01-2009


Ziggo/Multikabel, ESPN Classic, 09-01-2009


Ziggo/Multikabel, ESPN Classic, 09-01-2009

[ArChie]

Het overzicht in de start post is weer eens bijgewerkt. Op hoofdlijnen hebben de laatste tijd de volgende wijzigingen plaatsgevonden:

1. SDTV versie van History Channel heet nu HISTORY en de HDTV versie HISTORY HD;
2. VRT Radio Donna heet nu MNM;
3. Download kanalen zijn toegevoegd voor de nieuwe Humax iHDR-5050C HDTV PVR (HumaxPvrHD) en de nieuwe Samsung HDTV ontvanger (Samsung HD G2);
4. Radio Rembrandt heeft nu ook geen LCN nummer meer in Ziggo/Multikabel gebied;
5. City FM heet nu Decibel;
6. XLnt Radioboek is vervangen door XLnt Dance Classics;
7. Weerkanaal heet nu Weer en Verkeer;
8. InfoTV & Preview kanaal heet nu Ziggo TV;
9. Etalagekanaal is toegevoegd in Transport Stream 23;
10. Brava HD Promo is verwijderd uit Transport Stream 23;
11. Action Now is verwijderd uit Transport Stream 24;
12. /Geloven heet nu Spirit 24;
13. InfoThuis TV is toegevoegd aan de lokale Transport Stream 60 voor Ziggo/Casema abonnees in de omgeving van Den Haag;
14. SchagenFM en TEST Seaport zijn toegevoegd aan de lokael Transport Stream 150 voor de Ziggo/Multikabel abonnees.

Waarschijnlijk heeft die Dombo marketing manager van Ziggo bedacht dat het wel handig is om Ziggo TV kanaal, dat alleen maar reclame maakt voor de diensten van Ziggo, op LCN positie 11 te zetten zodat de klanten lekker veel lastig gevallen worden met dit kanaal. Nog meer niets toevoegende kanalen aan het begin van de LCN lijst waar je langs moet zappen als je geen gebruik maakt van favorieten lijstjes. Persoonlijk had ik liever gezien dat ze het Zenderoverzicht kanaal hadden verhuisd naar de zeer hoge nummers i.p.v. nog zo'n reclame kanaal erbij in de lage nummers.

Het Etalagekanaal is weer zo'n bitrate verspillende oplossing van Ziggo. Het kanaal dat namelijk wordt getoond in het Etalagekanaal wordt gewoon voor de tweede keer doorgegeven i.p.v. dat ze het kanaal voor iedereen openzetten via het Irdeto toegangssysteem en via bijvoorbeeld het Ziggo TV kanaal melden welk kanaal er door iedereen bekeken kan worden in een bepaalde periode. Met die Verrassingskanalen voor de combi pakket klanten doen ze dat toch ook? Of ze gaan op zoek naar een manier om via de DVB Service Informatie (DVB-SI) de Etalagekanaal service logisch te laten verwijzen naar de Transport Stream waar het getoonde kanaal al wordt doorgegeven zodat het ook niet nodig is om kanalen twee keer door te geven. Ondertussen worden wel de bitrates geknepen omdat er kennelijk volgens Ziggo/Casema geen ruimte is om kanalen her te verdelen zodat het knijpen van bitrates niet nodig is. Als ze dan op deze manier die zogenaamd schaarse ruimte aan het verspillen zijn dan gaat dat natuurlijk wel ten koste van hun geloofwaardigheid.

Per 1 januari zouden er een aantal kanalen gestopt zijn met uitzenden, maar die staan nog steeds in de kanalenlijst.

[ArChie]

EPG blijft moeilijk voor Ziggo/Casema en het controleren van de EPG die versturen doen ze zelf kennelijk nooit. Maar weer eens een greep uit de vele fouten in de EPG informatie die door het grootste kabelbedrijf van Nederland verzonden wordt:

Cartoon Network
Dit kanaal wordt bij Ziggo niet de gehele dag doorgegeven, dus moet Ziggo/Casema EPG informatie toevoegen voor de duur dat dit kanaal op zwart gaat. Die periode loopt van 20:00 uur tot 06:00 uur en duurt dus 10 uur. Ziggo/Casema denkt echter dat de duur van die periode maar 9 uur is waardoor er een gat van 1 uur in de EPG informatie ontstaat. Zie onderstaande EPG data voor Cartoon Network zoals doorgegeven door Ziggo/Casema. De aanvangstijden zijn in GMT, dus daar moet nog één uur bij geteld worden voor onze tijdzone (uiteraard wordt er niet bij de duur één uur opgeteld, iets waarvan het Ziggo/Casema personeel kennelijk verkeerd denkt dat het wel moet):

code:

- EPG gap detected for service ID: 2002, service name: Cartoon Network
  Event:
    Name:       Uitzending begint om 06:00 uur
    ID:         1
    Start time: 10-1-09 19:00:00 GMT
    Duration:   09:00:00

  Gap:
    Duration:   01:00:00

  Event:
    Name:       Looney Tunes
    ID:         294
    Start time: 11-1-09 5:00:00 GMT
    Duration:   00:25:00

Playboy TV
Ook voor dit kanaal geldt dat er niet de hele dag wordt uitgezonden. Volgens Ziggo/Casema begint de uitzending weer om 21:00 uur wat ik niet kan controleren omdat dit kanaal niet in het basis pakket zit. Als dat al zou kloppen en het laatste programma eindigt om 05:30 uur dan denkt Ziggo/Casema wederom foutief dat het maar 14 uur en 30 minuten duurt dat de uitzending is onderbroken terwijl dit 15 uur en 30 minuten moet zijn. Sowieso een gat van 1 uur dus, maar de eerste programma informatie die ze doorgegeven voor Playboy TV is pas voor 23:00 uur wat het gat met nog eens 2 uur vergroot:

code:

- EPG gap detected for service ID: 2007, service name: Playboy TV
  Event:
    Name:       Uitzending begint om 21:00 uur
    ID:         19
    Start time: 10-1-09 4:30:00 GMT
    Duration:   14:30:00

  Gap:
    Duration:   03:00:00

  Event:
    Name:       Free View
    ID:         50
    Start time: 10-1-09 22:00:00 GMT
    Duration:   00:10:00

- EPG gap detected for service ID: 2007, service name: Playboy TV
  Event:
    Name:       Uitzending begint om 21:00 uur
    ID:         20
    Start time: 11-1-09 4:30:00 GMT
    Duration:   14:30:00

  Gap:
    Duration:   03:00:00

  Event:
    Name:       Free View
    ID:         72
    Start time: 11-1-09 22:00:00 GMT
    Duration:   00:10:00

RTBF Sat
Bij dit kanaal is er 's nachts kennelijk sprake van een doorlopende herhaling, maar de eerste programma's van de volgende dag sluiten weer niet aan op de duur van die doorlopende herhaling:

code:

- EPG gap detected for service ID: 5003, service name: RTBF Sat
  Event:
    Name:       Doorlopende herhaling
    ID:         149
    Start time: 10-1-09 0:15:00 GMT
    Duration:   07:45:00

  Gap:
    Duration:   01:15:00

  Event:
    Name:       Affaires à suivre
    ID:         118
    Start time: 10-1-09 9:15:00 GMT
    Duration:   00:10:00

- EPG gap detected for service ID: 5003, service name: RTBF Sat
  Event:
    Name:       Doorlopende herhaling
    ID:         177
    Start time: 10-1-09 23:40:00 GMT
    Duration:   04:20:00

  Gap:
    Duration:   04:00:00

  Event:
    Name:       Basket 1
    ID:         178
    Start time: 11-1-09 8:00:00 GMT
    Duration:   00:15:00

BBC three & four
Ik heb er al veel over geschreven en nog steeds is het niet goed (komende week duur het geklooi van Ziggo/Casema met deze twee kanalen al een half jaar):

code:

- EPG gap detected for service ID: 11001, service name: BBC three
  Event:
    Name:       Uitzending begint om 20:00 uur
    ID:         3
    Start time: 10-1-09 5:00:00 GMT
    Duration:   13:00:00

  Gap:
    Duration:   01:00:00

  Event:
    Name:       The Real Hustle
    ID:         127
    Start time: 10-1-09 19:00:00 GMT
    Duration:   00:15:00

- EPG gap detected for service ID: 11001, service name: BBC three
  Event:
    Name:       Uitzending begint om 20:00 uur
    ID:         4
    Start time: 11-1-09 5:00:00 GMT
    Duration:   13:00:00

  Gap:
    Duration:   01:00:00

  Event:
    Name:       Look Who's Talking Now
    ID:         149
    Start time: 11-1-09 19:00:00 GMT
    Duration:   01:35:00

- EPG gap detected for service ID: 13002, service name: BBC four
  Event:
    Name:       Charlie Brooker's Screenwipe
    ID:         145
    Start time: 10-1-09 3:20:00 GMT
    Duration:   00:30:00

  Gap:
    Duration:   01:10:00

  Event:
    Name:       Uitzending begint om 20:00 uur
    ID:         3
    Start time: 10-1-09 5:00:00 GMT
    Duration:   13:00:00

- EPG gap detected for service ID: 13002, service name: BBC four
  Event:
    Name:       Uitzending begint om 20:00 uur
    ID:         3
    Start time: 10-1-09 5:00:00 GMT
    Duration:   13:00:00

  Gap:
    Duration:   01:00:00

  Event:
    Name:       Little Dorrit
    ID:         107
    Start time: 10-1-09 19:00:00 GMT
    Duration:   00:30:00

- EPG gap detected for service ID: 13002, service name: BBC four
  Event:
    Name:       Little Dorrit
    ID:         117
    Start time: 11-1-09 3:35:00 GMT
    Duration:   00:25:00

  Gap:
    Duration:   01:00:00

  Event:
    Name:       Uitzending begint om 20:00 uur
    ID:         4
    Start time: 11-1-09 5:00:00 GMT
    Duration:   13:00:00

- EPG gap detected for service ID: 13002, service name: BBC four
  Event:
    Name:       Uitzending begint om 20:00 uur
    ID:         4
    Start time: 11-1-09 5:00:00 GMT
    Duration:   13:00:00

  Gap:
    Duration:   01:00:00

  Event:
    Name:       Stephen Fry in America
    ID:         118
    Start time: 11-1-09 19:00:00 GMT
    Duration:   01:00:00

BBC World News
Elke dag is het programma zoek dat 's morgens om 07:00 uur wordt uitgezonden en 30 minuten duurt:

code:

- EPG gap detected for service ID: 12002, service name: BBC World News
  Event:
    Name:       India business report
    ID:         227
    Start time: 11-1-09 5:30:00 GMT
    Duration:   00:30:00

  Gap:
    Duration:   00:30:00

  Event:
    Name:       Fast track
    ID:         116
    Start time: 11-1-09 6:30:00 GMT
    Duration:   00:40:00

Nederland-E
Dit kanaal is gestopt en dus is er geen EPG informatie meer. Kennelijk weet Ziggo/Casema dit nog niet want in de DVB Service Information (DVB-SI) is er nog steeds geconfigureerd dat er EPG informatie voor dit kanaal wordt doorgegeven.

code:

- Present/Following EIT does not contain events for service ID: 59, service name: Nederland-E
- Schedule EIT does not contain events for service ID: 59, service name: Nederland-E

TV Gelderland
Bij dit kanaal ontbreekt elke dag voor de duur van 3 uur aan EPG informatie voordat op 09:00 uur de nieuwe programmering begint:

code:

- EPG gap detected for service ID: 3010, service name: TV Gelderland
  Event:
    Name:       Levende herinnering. Herh.
    ID:         151
    Start time: 10-1-09 4:20:00 GMT
    Duration:   00:40:00

  Gap:
    Duration:   03:00:00

  Event:
    Name:       Gisteren gemist?
    ID:         120
    Start time: 10-1-09 8:00:00 GMT
    Duration:   03:00:00

- EPG gap detected for service ID: 3010, service name: TV Gelderland
  Event:
    Name:       Quizcafé.
    ID:         176
    Start time: 11-1-09 4:15:00 GMT
    Duration:   00:45:00

  Gap:
    Duration:   03:00:00

  Event:
    Name:       Gisteren gemist?
    ID:         119
    Start time: 11-1-09 8:00:00 GMT
    Duration:   03:00:00

Dat een klein kabelbedrijf niet de mankracht en kennis heeft om de EPG goed op orde te hebben kan ik nog wel begrijpen, maar van het grootste kabelbedrijf verwacht ik dat ze dit soort dingen zelf in de gaten houden en geconstateerde afwijkingen ook snel oplossen. Het is gewoon belachelijk dat Ziggo/Casema hier niets aan doet terwijl ze de fouten op een presenteerblaadje aangereikt krijgen.

[ArChie]

De Logical Channel Numbering (LCN) is bij Ziggo/Casema ook nog steeds een rommeltje. Ook daarvoor ontbreekt kennelijk de kennis om dit goed op te lossen en ook goed te houden:

code:

- Service ID (4056) not found in TS (4) of NIT (500) for LCN (861)
- Service ID (6008) not found in TS (6) of NIT (500) for LCN (114)
- LCN (0) should not be assigned to data Service ID (7002) in TS (7) of NIT (500)
- LCN (0) should not be assigned to data Service ID (7003) in TS (7) of NIT (500)
- LCN (0) should not be assigned to data Service ID (7004) in TS (7) of NIT (500)
- LCN (0) should not be assigned to data Service ID (7005) in TS (7) of NIT (500)
- LCN (0) should not be assigned to data Service ID (7006) in TS (7) of NIT (500)
- LCN (0) should not be assigned to data Service ID (7007) in TS (7) of NIT (500)
- LCN (0) should not be assigned to data Service ID (7008) in TS (7) of NIT (500)
- LCN (0) should not be assigned to data Service ID (7009) in TS (7) of NIT (500)
- LCN (0) should not be assigned to data Service ID (7010) in TS (7) of NIT (500)
- LCN (0) should not be assigned to data Service ID (7011) in TS (7) of NIT (500)
- LCN (0) should not be assigned to data Service ID (7012) in TS (7) of NIT (500)
- LCN (0) should not be assigned to data Service ID (7013) in TS (7) of NIT (500)
- LCN (0) should not be assigned to data Service ID (7014) in TS (7) of NIT (500)
- LCN (0) should not be assigned to data Service ID (7015) in TS (7) of NIT (500)
- LCN (0) should not be assigned to data Service ID (7016) in TS (7) of NIT (500)
- LCN (0) should not be assigned to data Service ID (7017) in TS (7) of NIT (500)
- LCN not defined in TS (7) of NIT (500) for Service ID (7061)
- Service ID (20001) not found in TS (20) of NIT (500) for LCN (364)
- LCN not defined in TS (50) of NIT (500) for Service ID (401)
- LCN (0) should not be assigned to data Service ID (7002) in TS (7) of NIT (2222)
- LCN (0) should not be assigned to data Service ID (7003) in TS (7) of NIT (2222)
- LCN (0) should not be assigned to data Service ID (7004) in TS (7) of NIT (2222)
- LCN (0) should not be assigned to data Service ID (7005) in TS (7) of NIT (2222)
- LCN (0) should not be assigned to data Service ID (7006) in TS (7) of NIT (2222)
- LCN (0) should not be assigned to data Service ID (7007) in TS (7) of NIT (2222)
- LCN (0) should not be assigned to data Service ID (7008) in TS (7) of NIT (2222)
- LCN (0) should not be assigned to data Service ID (7009) in TS (7) of NIT (2222)
- LCN (0) should not be assigned to data Service ID (7010) in TS (7) of NIT (2222)
- LCN (0) should not be assigned to data Service ID (7011) in TS (7) of NIT (2222)
- Service ID (6008) not found in TS (6) of NIT (5555) for LCN (114)
- LCN (0) should not be assigned to data Service ID (7002) in TS (7) of NIT (5555)
- LCN (0) should not be assigned to data Service ID (7003) in TS (7) of NIT (5555)
- LCN (0) should not be assigned to data Service ID (7004) in TS (7) of NIT (5555)
- LCN (0) should not be assigned to data Service ID (7005) in TS (7) of NIT (5555)
- LCN (0) should not be assigned to data Service ID (7006) in TS (7) of NIT (5555)
- LCN (0) should not be assigned to data Service ID (7007) in TS (7) of NIT (5555)
- LCN (0) should not be assigned to data Service ID (7008) in TS (7) of NIT (5555)
- LCN (0) should not be assigned to data Service ID (7009) in TS (7) of NIT (5555)
- LCN (0) should not be assigned to data Service ID (7010) in TS (7) of NIT (5555)
- LCN (0) should not be assigned to data Service ID (7011) in TS (7) of NIT (5555)
- LCN (0) should not be assigned to data Service ID (7012) in TS (7) of NIT (5555)
- LCN (0) should not be assigned to data Service ID (7013) in TS (7) of NIT (5555)
- LCN (0) should not be assigned to data Service ID (7014) in TS (7) of NIT (5555)
- LCN (0) should not be assigned to data Service ID (7015) in TS (7) of NIT (5555)
- LCN (0) should not be assigned to data Service ID (7016) in TS (7) of NIT (5555)
- LCN (0) should not be assigned to data Service ID (7017) in TS (7) of NIT (5555)
- LCN (0) should not be assigned to data Service ID (7018) in TS (7) of NIT (5555)
- LCN not defined in TS (7) of NIT (5555) for Service ID (7061)
- Service ID (20001) not found in TS (20) of NIT (5555) for LCN (364)
- LCN (0) should not be assigned to data Service ID (7002) in TS (7) of NIT (8888)
- LCN (0) should not be assigned to data Service ID (7003) in TS (7) of NIT (8888)
- LCN (0) should not be assigned to data Service ID (7004) in TS (7) of NIT (8888)
- LCN (0) should not be assigned to data Service ID (7005) in TS (7) of NIT (8888)
- LCN (0) should not be assigned to data Service ID (7006) in TS (7) of NIT (8888)
- LCN (0) should not be assigned to data Service ID (7007) in TS (7) of NIT (8888)
- LCN (0) should not be assigned to data Service ID (7008) in TS (7) of NIT (8888)
- LCN (0) should not be assigned to data Service ID (7009) in TS (7) of NIT (8888)
- LCN (0) should not be assigned to data Service ID (7010) in TS (7) of NIT (8888)
- LCN (0) should not be assigned to data Service ID (7011) in TS (7) of NIT (8888)
- LCN (0) should not be assigned to data Service ID (7012) in TS (7) of NIT (8888)
- LCN (0) should not be assigned to data Service ID (7014) in TS (7) of NIT (8888)
- LCN (0) should not be assigned to data Service ID (7016) in TS (7) of NIT (8888)
- LCN not defined in TS (7) of NIT (8888) for Service ID (7061)
- LCN not defined in TS (150) of NIT (8888) for Service ID (405)

[ArChie]

Nog steeds staat de default "parental rating" in de EPG informatie op 1 wat overeenkomt met een minimum leeftijd van 4 jaar in plaats van een veel hogere instelling zodat de kindersloten op schadelijke programma's niet werken. En bedrijfsfantast Gradus Vos maar beweren dat de Ziggo klanten zelf hun verantwoordelijkheid moeten nemen om dit soort beveiligingen ook in te schakelen. Wat heeft dat voor zin als Ziggo/Casema haar verantwoordelijkheid niet door dit soort dingen op te lossen:

    │  ├─■  service  ID  41,  version  10
    │  │  ├─■  service_id  =  41
    │  │  ├─■  version_number  =  10
    │  │  ├─■  transport_stream_id  =  9
    │  │  ├─■  original_network_id  =  500
    │  │  └─■  sections:  {  Required  sections:  2,  available  sections:  2  }
    │  │      ├─■  section  {  0/1,  present  event  }
    │  │      │  ├─■  section_number  =  0
    │  │      │  ├─■  last_section_number  =  1
    │  │      │  ├─■  segment_last_section_number  =  1
    │  │      │  ├─■  last_table_id  =  79
    │  │      │  └─■  events:
    │  │      │      └─■  event
    │  │      │          ├─■  event_id  =  303
    │  │      │          ├─■  start_time  {  10-1-09  14:30:00  GMT  }
    │  │      │          │  ├─■  MJD  =  54841
    │  │      │          │  └─■  UTC  =  0x143000
    │  │      │          ├─■  duration  =  01:50:00
    │  │      │          ├─■  running_status  =  running
    │  │      │          ├─■  free_CA_mode  =  one  or  more  elementary  streams  CA  controlled
    │  │      │          └─■  descriptors:
    │  │      │              ├─■  short_event_descriptor
    │  │      │              │  ├─■  ISO_639_language_code  =  und
    │  │      │              │  ├─■  event_name
    │  │      │              │  │  ├─■  character_coding  =  Latin  alphabet  No.  5
    │  │      │              │  │  └─■  text  =  The  Postman  Always  Rings  Twice
    │  │      │              │  └─■  text
    │  │      │              │      ├─■  character_coding  =  Latin  alphabet  No.  5
    │  │      │              │      └─■  text
    │  │      │              ├─■  extended_event_descriptor
    │  │      │              │  ├─■  descriptor_number  =  0
    │  │      │              │  ├─■  last_descriptor_number  =  1
    │  │      │              │  ├─■  ISO_639_language_code  =  und
    │  │      │              │  ├─■  event  items:
    │  │      │              │  └─■  text
    │  │      │              │      ├─■  character_coding  =  Latin  alphabet  No.  5
    │  │      │              │      └─■  text  =  Een  immorele  zwerver  begint  te  werken  als  manusje-van-alles  in  een  verafgelegen  wegrestaurant  en  begint  een  affaire  met  de  gefrustreerde  jonge  vrouw  van  de  oudere  eigenaar.  Hun  passie  leidt  uiteindelijk  tot  moord  en  samen  beginnen  ze  aan  een  gevaar
    │  │      │              ├─■  extended_event_descriptor
    │  │      │              │  ├─■  descriptor_number  =  1
    │  │      │              │  ├─■  last_descriptor_number  =  1
    │  │      │              │  ├─■  ISO_639_language_code  =  und
    │  │      │              │  ├─■  event  items:
    │  │      │              │  └─■  text
    │  │      │              │      ├─■  character_coding  =  Latin  alphabet  No.  5
    │  │      │              │      └─■  text  =  lijke  reis.  Gebaseerd  op  de  roman  van  James  M.  Cain.
    │  │      │              ├─■  parental_rating_descriptor
    │  │      │              │  └─■  parental  ratings:
    │  │      │              │      └─■  parental  rating  {  minimum  age  4  years  }
    │  │      │              │          ├─■  country_code  =  NLD
    │  │      │              │          └─■  rating  =  1
    │  │      │              ├─■  content_descriptor
    │  │      │              │  └─■  contents:
    │  │      │              │      └─■  content  {  movie/drama  (general)  }
    │  │      │              │          ├─■  content_nibble_level_1  =  1
    │  │      │              │          ├─■  content_nibble_level_2  =  0
    │  │      │              │          ├─■  user_nibble_1  =  0
    │  │      │              │          └─■  user_nibble_2  =  0
    │  │      │              ├─■  component_descriptor  {  MPEG-2  video,  4:3  aspect  ratio,  25  Hz  }
    │  │      │              │  ├─■  stream_content  =  1
    │  │      │              │  ├─■  component_type  =  1
    │  │      │              │  ├─■  component_tag  =  1
    │  │      │              │  └─■  ISO_639_language_code  =  und
    │  │      │              └─■  component_descriptor  {  MPEG-1  Layer  2  audio,  surround  sound  }
    │  │      │                  ├─■  stream_content  =  2
    │  │      │                  ├─■  component_type  =  5
    │  │      │                  ├─■  component_tag  =  2
    │  │      │                  └─■  ISO_639_language_code  =  und

[ArChie]

Voor de aardigheid eens een vergelijkend waren onderzoekje gedaan om te zien wat de verschillen tussen Ziggo/Casema/Multikabel en Ziggo/@Home zijn voor wat betreft de EPG voorziening. Het meest in het oogspringende verschil is uiteraard dat de EPG bij Ziggo/Casema/Multikabel maar beperkt is tot 2 dagen EPG terwijl dit bij Ziggo/@Home 4 dagen is. Er wordt al jaren gezegd dat Ziggo/Casema/Multikabel dezelfde EPG voorziening als bij Ziggo/@Home gaan krijgen, maar er wordt alleen niet bij verteld in welk jaar dat dan gaat plaatsvinden. Maar als je de uitspraken van de Ziggo managers in diverse media mag geloven dan is de dienstverlening voor alle Ziggo abonnees gelijkgetrokken. Bij beide bedrijven is inderdaad sprake van EPG, maar de inhoud en hoeveelheid verschilt weldegelijk.

Bij Ziggo/Casema/Multikabel ontbreekt verder EPG informatie voor de volgende kanalen waarvoor Ziggo/@Home wel EPG informatie doorgeeft:

• Goed TV
• Garuda TV
• ATV
• FOX Turk
• Haberturk
• STAR TV
• Baby TV
• Zee Cinema

Bij Ziggo/@Home zitten er veel gaten in de EPG bij de derde en vierde dag die ze extra doorgeven t.o.v. Ziggo/Casema/Multikabel, maar dat zijn allemaal korte en veel herhalende programma's die ze met opzet uit de EPG informatie halen om de hoeveelheid EPG data niet te groot te laten worden. Gaten in de EPG zoals bij Ziggo/Casema/Multikabel die dagelijks op min of meer vaste tijden terugkeren zoals bij BBC Three & Four zijn er niet bij Ziggo/@Home.

Bij Ziggo/@Home worden de component_descriptors uit de Present/Following EPG informatie gefilterd terwijl Ziggo/Casema/Multikabel wel de component_descriptors doorgeeft hoewel die component descriptors niet mappen op de stream_identifier_descriptors bij de Program Map Table (PMT) informatie van de kanalen. Bij Ziggo/Casema/Multikabel waar de component_descriptors wel in de EPG informatie zitten komen de gekozen standaardwaarden niet overeen met de werkelijkheid. Kost ze waarschijnlijk te veel tijd en moeite om dat eens een keertje goed in te vullen voor alle kanalen.

Bij Ziggo/@Home voeren ze standaard overal als ISO_639_language_code van de events (= programma's) "dut" in terwijl dat veld bedoeld is om de gebruikte taal van de programma tekst aan te geven. Bij Ziggo/Casema/Multikabel is bij sommige kanalen die ISO_639_language_code correct ingevuld, maar bij de meeste kanalen zetten ze ISO_639_language_code op de niet bestaande taalcode "und". Het is natuurlijk een "hele klus" om voor al die kanalen de waarde één keer goed te zetten in de default configuratie van een kanaal. Natuurlijk een veel te vermoeiende bezigheid.

Zowel voor Ziggo/Casema/Multikabel als voor Ziggo/@Home geldt dat de standaard waarde van de parental_rating_descriptor op 1 staat, wat overeenkomt met een minimum leeftijd van 4 jaar en te laag is om het kinderslot mechanisme goed zijn werk te laten doen. Men zou de informatie van de content_descriptor van ieder programma kunnen gebruiken om een juiste standaard waard in te vullen als de leeftijdsgrens niet expliciet is opgegeven in de EPG data die zij importeren, maar dat is kennelijk te veel moeite. Content type detective/thriller mag dus bij beide onderdelen van Ziggo gewoon door 4 jarigen bekeken worden.

Of Ziggo/@Home wel meerdere keren per dag de EPG informatie actualiseert is mij niet bekend. Bij Ziggo/Casema/Multikabel wordt er alleen 's morgens om 6 uur een keer een soort van update uitgevoerd die voornamelijk als gevolg heeft dat de event_id waarden van diverse programma's opeens wijzigen zodat een ontvanger niet meer kan achterhalen dat de aanvangstijd of duur van een bepaald programma gewijzigd is.

[The_Doman]

ArChie schreef op zondag 11 januari 2009 @ 11:27:Of Ziggo/@Home wel meerdere keren per dag de EPG informatie actualiseert is mij niet bekend. Bij Ziggo/Casema/Multikabel wordt er alleen 's morgens om 6 uur een keer een soort van update uitgevoerd die voornamelijk als gevolg heeft dat de event_id waarden van diverse programma's opeens wijzigen zodat een ontvanger niet meer kan achterhalen dat de aanvangstijd of duur van een bepaald programma gewijzigd is.

Aha!
Dat verklaart dan waarschijnlijk ook het feit dat ProgDVB elke dag bij bijna elke zender aangeeft dat er iets gewijzigd is.
Ik vroeg me dat al steeds af.

[ArChie]

The_Doman schreef op zondag 11 januari 2009 @ 12:38:

Aha!
Dat verklaart dan waarschijnlijk ook het feit dat ProgDVB elke dag bij bijna elke zender aangeeft dat er iets gewijzigd is.
Ik vroeg me dat al steeds af.

Zoals bijna alle "tables" van de DVB Service Information (DVB-SI) heeft ook de Event Information Table (EIT) waarmee de EPG informatie verzonden wordt een versie nummer. Zie onderstaand voorbeeld van de EIT voor één van de events van het ShopZo|SUUS kanaal:

    └─■  Schedule
        ├─■  service  ID  13,  version  3
        │  ├─■  service_id  =  13
        │  ├─■  version_number  =  3
        │  ├─■  transport_stream_id  =  24
        │  ├─■  original_network_id  =  500
        │  └─■  sections:  {  Required  sections:  16,  available  sections:  16  }
        │      ├─■  section  {  0/120,  segment  0,  day  1,  period  00:00:00  -  02:59:59  }
        │      │  ├─■  section_number  =  0
        │      │  ├─■  last_section_number  =  120
        │      │  ├─■  segment_last_section_number  =  0
        │      │  ├─■  last_table_id  =  96
        │      │  └─■  events:
        │      │      ├─■  event
        │      │      │  ├─■  event_id  =  280
        │      │      │  ├─■  start_time  {  10-1-09  0:00:00  GMT  }
        │      │      │  │  ├─■  MJD  =  54841
        │      │      │  │  └─■  UTC  =  0x000000
        │      │      │  ├─■  duration  =  01:00:00
        │      │      │  ├─■  running_status  =  undefined
        │      │      │  ├─■  free_CA_mode  =  one  or  more  elementary  streams  CA  controlled
        │      │      │  └─■  descriptors:
        │      │      │      ├─■  short_event_descriptor
        │      │      │      │  ├─■  ISO_639_language_code  =  dut
        │      │      │      │  └─■  event_name
        │      │      │      │      ├─■  character_coding  =  Latin  alphabet  No.  5
        │      │      │      │      └─■  text  =  Nachtprogrammering
        │      │      │      ├─■  extended_event_descriptor
        │      │      │      │  ├─■  descriptor_number  =  0
        │      │      │      │  ├─■  last_descriptor_number  =  0
        │      │      │      │  ├─■  ISO_639_language_code  =  dut
        │      │      │      │  ├─■  event  items:
        │      │      │      │  └─■  text
        │      │      │      │      ├─■  character_coding  =  Latin  alphabet  No.  5
        │      │      │      │      └─■  text  =  Erotiek.  Kijkwijzer  indicatie:  afgeraden  voor  personen  jonger  dan  16  jaar,  programma  bevat  seks,  programma  bevat  grof  taalgebruik.
        │      │      │      ├─■  parental_rating_descriptor
        │      │      │      │  └─■  parental  ratings:
        │      │      │      │      └─■  parental  rating  {  minimum  age  16  years  }
        │      │      │      │          ├─■  country_code  =  NLD
        │      │      │      │          └─■  rating  =  13
        │      │      │      └─■  content_descriptor
        │      │      │          └─■  contents:
        │      │      │              └─■  content  {  adult  movie/drama  }
        │      │      │                  ├─■  content_nibble_level_1  =  1
        │      │      │                  ├─■  content_nibble_level_2  =  8
        │      │      │                  ├─■  user_nibble_1  =  0
        │      │      │                  └─■  user_nibble_2  =  0


Het versie nummer van de Schedule informatie voor dit kanaal staat nu op 3. 's nachts om 00:00 uur GMT vindt er een update plaats om alle EPG data van de huidige dat uit die EIT set te verwijderen en de EPG informatie voor de nieuwe volgende dat toe te voegen. Dat is normaal en gebeurt ook bij Ziggo/@Home op dezelfde manier. Bij Ziggo/Casema volgt er echter om 06:00 GMT weer een update van de EIT sets voor alle kanalen waarbij het versie nummer met één verhoogd wordt ongeacht of er nu wel of niet daadwerkelijk een update van de EPG informatie heeft plaatsgevonden voor het betreffende kanaal. Die update lijkt voornamelijk plaats te vinden om de EPG data van 00:00 GMT 's nachts tot 06:00 GMT 's morgens uit de EIT set te halen, maar dat gebeurt weer niet voor alle kanalen. Even terugzoeken in dit topic naar de berichten waar ik zo goed mogelijk probeer uit te leggen hoe de EPG update cycle bij Ziggo/Casema werkt en wat daar allemaal fout gaat.