[Ziggo] Picons voor Regio Utrecht?

[ArChie]

Origineel bericht van: pieterg

Op de kabel, wellicht.
Maar het moet ook op de satelliet gebruikt kunnen worden, en daar heb je helaas veel duplicate nid/tsid/sid's, en combinaties daarvan.

Het gaat dus om de combinatie van die drie gegevens die de boel uniek maakt. Je kan dus inderdaad niet naar de afzonderlijke items kijken om een service uniek te identificeren, en alleen de combinatie van TSID en SID is ook niet voldoende, daarom is de ONID toegevoegd. Die ONID moet namelijk volgens de DVB specificaties uniek zijn binnen het DVB systeem. Dat geldt ook op de satelliet. Een goed voorbeeld van een descriptor waar deze combinatie gebruikt wordt is de service_move_descriptor om aan een ontvanger te vertellen dat gezochte service verplaatst is naar een andere Transport Stream waarbij het mogelijk is dat de SID en ONID ook anders zijn voor de nieuwe bron van dat kanaal:

Citaat:

If it is required to move a service from one TS to another, a mechanism is provided which enables an IRD to track the service between TSs by means of a service_move_descriptor.

Table 84: Service move descriptor
service_move_descriptor() {
descriptor_tag
descriptor_length
new_original_network_id
new_transport_stream_id
new_service_id
}

Semantics for the service move descriptor:
new_original_network_id: This field contains the original_network_id of the TS in which the service is found after the move.
new_transport_stream_id: This field contains the transport_stream_id of the TS in which the service is found after the move.
new_service_id: This field contains the service_id of the service after the move. If the service remains within the same original network, then the new_service_id is the same as the previous service_id.

Zie ook: http://www.ses-astra.com/resources/pdf/en-shared/technical_support/DVB_service_moves_1_0_0.pdf

[Gast pieterg]

helaas houden veel providers zich niet aan de dvb standaard.

Wat betreft de (t)sid gaat dat op de astra's nog wel goed, maar volgens mij kom je zelfs op de hotbird (13.0) al dubbele tegen.

En dan praten we nog niet over de echt exotische sats.

[ArChie]

Origineel bericht van: pieterg

helaas houden veel providers zich niet aan de dvb standaard.
Wat betreft de (t)sid gaat dat op de astra's nog wel goed, maar volgens mij kom je zelfs op de hotbird (13.0) al dubbele tegen.
En dan praten we nog niet over de echt exotische sats.

Het gaat om de combinatie van die drie gegevens, die moet uniek zijn. Als dat niet zo zou zijn dan kan een ontvanger nooit een service uniek adresseren en weergeven.

[Gast pieterg]

Origineel bericht van: ArChie

Origineel bericht van: pieterg

helaas houden veel providers zich niet aan de dvb standaard.
Wat betreft de (t)sid gaat dat op de astra's nog wel goed, maar volgens mij kom je zelfs op de hotbird (13.0) al dubbele tegen.
En dan praten we nog niet over de echt exotische sats.

Het gaat om de combinatie van die drie gegevens, die moet uniek zijn. Als dat niet zo zou zijn dan kan een ontvanger nooit een service uniek adresseren en weergeven.

Bij de meeste ontvangers bevat de zenderlijst om deze reden (en om redenen van sneller tunen) per zender alle tuner parameters.

Kijk bijvoorbeeld maar eens naar de fastscan tabel van cds.

Ik geef toe dat het voor picons niet strict noodzakelijk geweest zou zijn om op alle parameters te matchen, maar die zgn 'serviceref' is binnen enigma(1/2) nu eenmaal hetgene wat een service 100% uniek identificeert.

[ArChie]

Origineel bericht van: pieterg

Ik geef toe dat het voor picons niet strict noodzakelijk geweest zou zijn om op alle parameters te matchen, maar die zgn 'serviceref' is binnen enigma(1/2) nu eenmaal hetgene wat een service 100% uniek identificeert.

Die tuner parameters voegen echter niets toe aan het uniek identificeren van een service. Het kan handig zijn om die tuning parameters in de service lijst op te nemen zodat een ontvanger niet steeds op basis van de TSID in de Network Information Tables (NIT) opzoek moet naar de juiste frequentie en instellingen tijdens het zappen, maar dat is een implementatie keuze in de ontvanger om het zappen sneller te krijgen. De service met bepaalde SID wordt echter nog steeds geboden door een digitale TV provider geïdentificeerd met een bepaalde ONID via een transport stream met een bepaalde TSID.

Dat een transport stream van een digitale TV provider zich dan op een bepaalde frequentie bevindt met bepaalde instellingen is voor het matchen van allerlei data verzonden via de "tables" in het DVB systeem niet relevant. Bij een service hoort meestal ook EPG informatie die verzonden wordt via de Event Information Tables (EIT) en in die tables worden de events ook weer gekoppeld aan de juiste service via de ONID, TSID en SID. Als het niet mogelijk was geweest om alleen op basis van die drie gegevens een service uniek te identificeren in een DVB systeem dan was er in de DVB specificatie ook opgenomen dat de tuning parameters noodzakelijk zijn.

Het nadeel van het wel opnemen van de tuning parameters in de zogenaamde 'serviceref' van enigma wordt al duidelijk bij deze discussie die wij nu hebben over het aantal benodigde sets picons. Bij unieke identificatie van services op basis van de ONID, TSID en SID zoals gedefinieerd in de DVB specificaties zijn twee sets voldoende voor Ziggo aangezien Ziggo twee ONID's ingebruik heeft met ieder hun eigen TS nummering en service nummering. Ga je echter ook de tuning parameters opnemen in de 'serviceref', dan zijn er maximaal 18 sets nodig op basis van het aantal verschillende netwerk ID's (niet te verwarren met het original network ID's) dat bij Ziggo gedefinieerd is. Ga je echter dan handmatig uitzoeken hoeveel verschillende frequentie sets en parameters er werkelijk nodig zijn dan kan dat iets minder zijn omdat sommige Ziggo NIT's tegenwoordig hetzelfde frequentie plan bevatten. Vanuit picon set distributie oogpunt is het al een drama om aannames te doen over een door de digitale TV provider gebruikte ONID, TSID en SID nummering als je het tot twee sets zou beperken, laat staan dat je de tuning params ook nog eens gaat meenemen en dus 18 verschillende sets zou moeten gaan onderhouden en verspreiden.

Maar goed, we verschillen op dit punt duidelijk van mening. Ik houd me bij dit soort zaken liever aan de DVB specificaties aangezien daar langdurig over nagedacht is in allerlei commissies voordat dergelijke specificaties worden vrijgegeven. Op het moment dat partijen gaan afwijken van die DVB specifcaties omdat ze dat voor een bepaald implementatie detail wel handig lijkt, dan leidt dat negen van de tien keer tot problemen als men later ook een ander deel van de DVB specificaties wil gaan toepassen en blijkt dat die "kleine" afwijking grote gevolgen heeft. Kijk maar naar de afwijking van de specificaties die Ziggo toepast met het niet standaard gebruik van de zogenaamde "actual en other NIT" en wat dat voor een effect heeft op allerlei ontvangers die gewoon de DVB specificaties volgen bij het zoeken naar services of wat voor een gevolgen die beslissing heeft bij het updaten van services in de kanalenlijst. Zelfs door Ziggo goedgekeurde ontvangers struikelen hier regelmatig over omdat het allerlei compliserende consequenties heeft die niet goed overzien zijn toen men zelf een handigere/goedkopere oplossing gevonden dacht te hebben.

[Gast pieterg]

volgens mij verschillen we niet van mening.

Ik leg me er alleen (met tegenzin) bij neer dat er talloze providers zijn die zich niet aan de dvb standaarden houden.

Moet je voor de grap eens in de enigma internals kijken, daar word je niet vrolijk van.

Maar je kunt de wereld niet veranderen.

 

En die servicerefs, die er nu eenmaal zijn, en al dan niet iets meer data bevatten dan strict noodzakelijk is om uniek te zijn, zijn gewoon een handige manier om picons te identificeren.

Dus ja, noem me een luie programmeur. (maar liever geen domme programmeur)

[ArChie]

Origineel bericht van: pieterg

En die servicerefs, die er nu eenmaal zijn, en al dan niet iets meer data bevatten dan strict noodzakelijk is om uniek te zijn, zijn gewoon een handige manier om picons te identificeren.
Dus ja, noem me een luie programmeur. (maar liever geen domme programmeur)

Ah, ik heb de programmeur aan de lijn. Vandaar die volhardende verdediging van de in mijn ogen vreemd opgebouwde servicerefs. Wat is dan precies het format van zo'n serviceref? Is het bijvoorbeeld een string waarbij de bepaalde posities gevuld worden met de ONID, TSID, SID, frequency, FEC, symbolrate, modulation, etc.? Ofwel zijn de ONID, TSID en SID weer te herleiden uit zo'n serviceref? Zoja, dan kan je die herleide ONID, TSID en SID informatie natuurlijk weer formateren tot een string die de filename van de picon identificeert. Zo'n routine zal er toch al moeten zijn om de ONID, TSID en SID uit die intern gebruikte serviceref te kunnen halen zodat de EPG info gekoppeld kan worden. Op die manier kan je dan toch volstaan met twee sets picons voor Ziggo.

[Gast pieterg]

weet je wat, het is veel minder erg dan we dachten.

Een serviceref bevat naast sid, tid en netwerk id eigenlijk alleen nog maar een 'namespace' veld, wat de orbital positie bevat.

 

En nog wat velden die je redelijk als constant kunt opvatten als het om picons gaat.

 

edit: hier, ongeveer halverwege de pagina, staat een voorbeeld

http://www.pli-images.org/modules/wiki/index.php?wakka=E1SoftwareDownloadsPlicons

 

Dus eigenlijk zou je verwachten dat het al werkt, als alle netwerk id's, sids en tids gelijk zouden zijn in de verschillende ziggo regios.

Toen ik de bestaande sets samengesteld heb, was dat nog niet het geval.

Sinds die tijd heb ik me niet meer zo verdiept in wat ziggo allemaal veranderd heeft.

[ArChie]

Origineel bericht van: pieterg

weet je wat, het is veel minder erg dan we dachten.
Een serviceref bevat naast sid, tid en netwerk id eigenlijk alleen nog maar een 'namespace' veld, wat de orbital positie bevat.

Het zal wel met mijn onbekendheid met digitale TV via de satelliet te maken hebben, maar het veld 'namespace' begrijp ik niet. Wat wordt er bedoelt met orbital position 1600? En waarom vertaald zich dat dan tot een waarde van 6400000 voor dat veld terwijl de hex waarde gelijk is aan 0x0640? En wat moet er dan in geval van digitale kabel TV worden ingevuld in dat 'namespace' veld?

Citaat:

Dus eigenlijk zou je verwachten dat het al werkt, als alle netwerk id's, sids en tids gelijk zouden zijn in de verschillende ziggo regios.

Dat hangt er vanaf over welke netwerk ID we het hebben. Als dat de original network ID (ONID) is, dan zijn alle TSID's en SID's gelijk binnen iedere door Ziggo gebruikte ONID (dus ONID 500 voor Ziggo/Casema/Multikabel gebied en ONID 1000 voor Ziggo/@Home gebied), wat dan leidt tot twee sets. Voorbeeld voor Nederland 1:

Nederland 1 in Ziggo/Casema/Multikabel gebied:
ONID = 500
SID = 8004
TSID = 8

Nederland 1 in Ziggo/@Home gebied:
ONID = 1000
SID = 10001
TSID = 10

Als die network ID echter de actual network ID is uit één van de other NIT's zoals dat door Ziggo wordt toegepast, dan heb je alsnog voor iedere bij Ziggo bekende network ID (in totaal 18 stuks) een aparte set nodig. Voor alle duidelijkheid: De "actual NIT" bij Ziggo is altijd de NIT waarvan de network ID gelijk is aan het original network ID. De NIT's voor alle andere netwerk ID's worden altijd als "other NIT" doorgegeven. Dit is niet in overeenstemming met de DVB specificatie waar een ontvanger mag aannemen dat de aangetroffen "actual NIT" altijd van toepassing is voor het (sub)netwerk waar de ontvanger gebruikt wordt.

Verder hangt het ook af van wat PLi verwacht als waarde van het 'namespace' veld bij kabel ontvangst. Als die per deelgebied anders blijkt te zijn, dan heb je dus ook 18 sets nodig.

Citaat:

Toen ik de bestaande sets samengesteld heb, was dat nog niet het geval.
Sinds die tijd heb ik me niet meer zo verdiept in wat ziggo allemaal veranderd heeft.

Ga er maar vanuit dat de picon sets blijven veranderen aangezien Ziggo om de haverklap wijzigingen doorvoert in de beide netwerken met het toevoegen, verwijderen en wijzigen van services. Onlangs zijn er weer complete transport streams verhuisd van frequentie, maar ook de inhoud wijzigt nog wel eens waarbij ook de service ID's van services kunnen wijzigen. Vandaar dat ik je ook adviseer om zo min mogelijk van die sets te maken als het even kan omdat onderhoud anders een ramp is.

[Gast pieterg]

namespace is constant bij cable: FFFF0000. Een waarde buiten de geldige orbital positions bij sat.

 

En idd, als ik hier in een ziggo set kijk (zwolle), zijn alle ONIDs 3E8 (=1000).

Dus eigenlijk zou deze set in het hele @home gebied moeten werken.

Vraag mij af waarom we dan aparte brabant/drenthe/groningen sets hebben gemaakt... (heb deze sets zelf niet kunnen testen, zijn volgens mij door PLi gebruikers uit de betreffende regios aangemaakt, edits van de regio zwolle set)

[ArChie]

Origineel bericht van: pieterg

namespace is constant bij cable: FFFF0000. Een waarde buiten de geldige orbital positions bij sat.

En idd, als ik hier in een ziggo set kijk (zwolle), zijn alle ONIDs 3E8 (=1000).
Dus eigenlijk zou deze set in het hele @home gebied moeten werken.

Dat lijkt mij ook aangezien alleen de tuning parameters voor de Transport Streams verschillen in de diverse regio's van het Ziggo/@Home gebied. De TSID's en SID's blijven in al die regio's gelijk en uiteraard is in het hele Ziggo/@Home gebied de ONID gelijk aan 1000.

Citaat:

Vraag mij af waarom we dan aparte brabant/drenthe/groningen sets hebben gemaakt... (heb deze sets zelf niet kunnen testen, zijn volgens mij door PLi gebruikers uit de betreffende regios aangemaakt, edits van de regio zwolle set)

Gezien onze discussie vind ik het niet zo vreemd dat andere PLi gebruikers ook denken dat er per regio in het Ziggo/@Home gebied een aparte picon set nodig is. Vergeet niet dat de meeste PLi gebruikers geen idee hebben wat DVB specificaties zijn en hoe die door Ziggo worden toegepast. Als men de set voor @Home download waarvan door allerlei TSID en SID updates van services een deel van picons niet meer geladen worden of ontbreken omdat de services nog niet bestonden op het moment van het aanmaken van de picons set, dan zal bij de gebruiker al snel de indruk ontstaan dat dit komt door regionale verschillen. De gebruiker denkt dan aanpassingen te hebben gemaakt voor zijn eigen regio en upload die "nieuwe" set onder een andere naam.

Ik ken het picon dowload/upload systeem verder niet aangezien ik geen Dreambox of PLi gebruiker ben, maar is het uberhaupt mogelijk voor gebruikers om een picon set op de download server te updaten met de laatste stand van zaken of kan alleen de originele uploader zijn eigen set updaten? En misschien is het handig dat er tijdens het downloaden van een picon set een soort van gebruiksaanwijzing aan de gebruiker wordt getoond waarin dan wordt uitgelegd dat de set van toepassing is op alle regio's van het betreffende voormalige deel van het Ziggo kabelgebied met het verzoek om eventuele gemaakte wijzigingen weer onder dezelfde naam te uploaden (als dat al mogelijk is). Zo'n picon set is nu eenmaal niet statisch gezien het dynamische karakter van de Ziggo Transport Streams en de services in die Transport Streams.

[Gast pieterg]

in het begin was de eerste ziggo set 'regioloos', de indeling in regios is gekomen omdat deze naar verluid niet overal werkte.

 

Nu we beredeneerd hebben dat dat op een misverstand moet berusten, stel ik de volgende werkwijze voor:

terug naar 2 sets, voor beide ONIDs.

Laatste wijzigingen meenemen.

 

Vrijwilligers om een tarball te maken met de juiste serviceref symlinks er in?

Dan zal ik de ipkg paketten met de de juiste namen genereren en online zetten.

[ArChie]

Origineel bericht van: pieterg

in het begin was de eerste ziggo set 'regioloos', de indeling in regios is gekomen omdat deze naar verluid niet overal werkte.

Misschien is het verstandig om eerst de huidige picon filesets van twee uithoeken van het Ziggo/@Home gebied met elkaar te vergelijken, bijvoorbeeld Groningen en Limburg, om er absoluut zeker van te zijn dat de ONID overal gelijk is aan 1000? Stel dat er in de Enigma code een truukje bedacht is om bij het scannen naar services een (sub)netwerk ID op te kunnen geven i.p.v. de "actual NIT" te nemen waarbij die (sub)netwerk ID in de Enigma code dan mogelijk gebruikt wordt als de ONID i.p.v. de echte ONID.

[Gast pieterg]

ja hoor, ze zijn gewoon gelijk, op minieme verschillen na (foutjes waarschijnlijk). Lekker handig

 

@home regio moet dus hier en daar gecorrigeerd worden, casema regio moet nog samengesteld worden.

[Dream1975]

Met uitgebreide hulp van Pieterg heb ik gisteren de Ziggo Picons samengesteld voor het voormalig Casema/Multikabel gebied. Ze zitten in de PLI downloads van Enigma2