:fill(white):strip_exif()/i/1244533535.jpeg?f=thumbmini)
:fill(white):strip_exif()/i/1261384181.jpeg?f=thumbmini)
:fill(white):strip_exif()/i/1249026710.jpeg?f=thumbmini)
:fill(white):strip_exif()/i/1253531017.jpeg?f=thumbmini)
:fill(white):strip_exif()/i/1232195031.jpeg?f=thumbmini)
:fill(white):strip_exif()/i/1297245205.jpeg?f=thumbmini)
:fill(white):strip_exif()/i/1227782084.jpg?f=thumbmini)
:fill(white):strip_exif()/i/1227514227.jpg?f=thumbmini)
:fill(white):strip_exif()/i/1227515266.jpg?f=thumbmini)
:fill(white):strip_exif()/i/1227516294.jpg?f=thumbmini)
:fill(white):strip_exif()/i/1227516617.jpg?f=thumbmini)
Ik heb de frequentielijst voor Den Haag verwerkt in een XML voor Mediaportal en de boel gescand, op 122000 krijg ik "no signal" , geen film1 dus. Ook als ik met transedit (free) de frequentie scan komt er niets naar voren, op de andere frequenties wordt alles gevonden. Ik heb maar beperkt inzicht in deze materie en heb geen flauw idee waar te zoeken. Met de gratis transedit kan je helaas niet de 474 analyseren.
:strip_icc():strip_exif()/u/37421/kt666.jpg?f=community)
Wtf.. Ik heb dit probleem al sinds 1 maart, de start van die zender. En nu opeens werkt de SD-versie wel goed!
Dit is een sample van de HD-variant: https://mega.nz/#!9VpSUTg...p_2nnihtQeUxehe3KarzETVSg
Log hiervoor was:
Roosendaal: 690,750 kHz/Viceland HD: H264 @ #4401: Continuity counter error, 175 duplicate log lines suppressed
Bijna 200 errors. (er waren nog 18 niet-suppressed regels die ik voor de leesbaarheid hier achterwege heb gelaten) 0 errors in audio en ca.
Als deze het nu over een paar dagen opeens ook probleemloos doet dan weet ik zeker dat er hier een engeltje meeleest.
Verstuurd vanaf mijn Computer®
Voor de zekerheid: Een transport stream wordt niet per apparaat of per kanaal gemaakt. Een transport stream is een eindeloze reeks van bits die samen MPEG packets vormen van 188 bytes. Een transport stream die in gebruik is bevat een meerdere elementary streams met ieder een eigen Packet ID (PID) en een service (bijvoorbeeld een TV kanaal) omvat een subset van die elementary streams.
Om de afzonderlijke packets te kunnen onderscheiden is ieder packet voorzien van een zogenoemde header (vier bytes lang). Zo'n MPEG header is een verzameling velden waarin o.a. een synchronisatie byte, packet ID en de continuity counter zit. Dergelijke informatie wordt door de multiplexer gezet die de volledige transport stream maakt. Iedere elementary stream die geïdentificeerd wordt met een bepaalde PID heeft dus een eigen continuity counter.
Een ontvanger is in feite een packet filter die alleen die packets uit de transport stream haalt die nodig zijn voor de weergave van het door de gebruiker gekozen kanaal zodat die aan de MPEG decompressie component kunnen worden aangeboden. Voor de weergave van bijvoorbeeld Viceland HD zal de ontvanger dus een minimaal de video packets met PID 4401 en audio packets met PID 4411 uit de transport stream moeten halen naast nog een aantal administratieve packets met verschillende PID's om te weten hoe Viceland HD uberhaupt is opgebouwd.
Hieronder zie je een aantal packets van de video elementary stream van Viceland HD:
De vier bytes header van de packets wordt door TransEdit blauw gemarkeerd. Het eerste byte met waarde 0x47 is de synchronisatie byte zodat de ontvanger het begin van de packets kan vinden. De waarde van de continuity counter in de header heb ik geel gemarkeerd. Ze doorlopen sequentieel de waarden van 0x0..0xF. In bovenstaande afbeelding zie je het omslag punt (0xE, 0xF, 0x0, 0x1).
Als een ontvanger een waarde mist in die eindeloze reeks, dan is er sprake van een continuity counter error en is er dus sprake van een missing MPEG packet. Zo'n missing MPEG packet zal zich vertalen in een verstoring tijdens weergave. Er ontbreekt immers MPEG data die niet omgezet kan worden in een uitgangssignaal.
De enige plek waar er iets mis zou kunnen gaan met die continuity counter voor het sequentieel doornummeren van de packets met een bepaalde PID is in de multiplexer. Dat zou dan echter alle klanten van Ziggo/UPC raken. De enige andere verklaring voor continuity counter errors is dat er door verstoring van de transport stream tussen verzender (digitale TV headend) en ontvanger (bij de klant) packets verloren gaan. Hoeveel klanten daarbij geraakt worden hangt af van het punt waar de verstoring van het signaal optreedt. Aangezien je zelf aangeeft dat de Humax het signaal foutloos kan weergeven, ofwel de Humax ontvangt wel alle door de digitale TV headend verzonden MPEG packets, kan je daaruit de conclusie trekken dat het probleem ergens in het signaal pad tussen de aftakking voor de PC zit of een bug is in de DVB software. De vanuit de digitale TV headend verstuurde transport stream is immers gelijk voor alle ontvangers.
Om te achterhalen of het signaal verstoord binnenkomt op de tuner in de PC zal je de transport stream direct na de tuner moeten onderzoeken met een transport stream analyser om na te gaan of de missing packets dan ook gedetecteerd worden en op die plek zal je die missing packets dan ook zien in meerdere elementary streams. Als het een bug zou zijn in de DVB software op de PC dan is een mogelijke verklaring dat de DVB software het tijdens de weergave van Viceland zodanig druk heeft dat het packet filter in de software de transport stream niet meer kan bijbenen en packets gaat missen. Ik vind dat laatste echter niet waarschijnlijk. Ook omdat het continuity counter error probleem bij de SD van Viceland weer is verdwenen vermoed ik dat je signaal problemen hebt.
Dat wist ik.
Van weergave is geen sprake, ik neem het gewoon op. Komt geen (video) decoder aan te pas dus cpu/ram/etc zitten allemaal voornamelijk uit hun neus te vreten.
Goede uitleg! Ik deel alleen je conclusie niet helemaal. Er is in mijn ogen nog een mogelijkheid. Stel dat dit de nummering is:
0 1 2 4 3 5 6 7 8 9 A B C D E F
Dus 3 en 4 omgewisseld. Een deel van de ontvangers (bijvoorbeeld de Humax) zou dit kunnen negeren en alles gewoon in de volgorde waarin het binnenkwam verwerken. Dan gaat alles goed en is er geen probleem. Een ontvanger die wat stricter is kan zeggen "HEE, dat is niet de bedoeling!!" en packets droppen, de volgorde aanpassen of lege packets invoegen zodat het aantal weer klopt. Gevolg: perfect beeld op de eerste ontvanger, beeldfouten op nummer twee terwijl ze allebei een perfect signaal hebben.
Maar je moest eens weten, ik heb over de jaren al meerdere malen bij diverse problemen te horen gekregen "controleer uw SCART-kabel", "dat is geen beeldfout, het OSD-menu van uw ontvanger blijft gewoon te lang in beeld" (wat echt super super super knap is voor een ontvanger die geen OSD-menu heeft!). Soms duurde het lang en soms kort, maar de conclusie was altijd hetzelfde: "shit, het ligt inderdaad aan hetgeen wij aanleveren".
Interessant. Dit is dus voor ongeveer een minuut als ik het goed uitreken?
Heb je ook een log van een andere zender op dezelfde frequentie? Want je gaf al aan dat je sowieso slecht signaal hebt op die frequentie, dus dan valt er wat te vergelijken.
Als je logs van pakweg 5 minuten kan maken voor b.v. spike en vice gelijktijdig (of van de hele ts, nog beter) dan kan ik er wel uithalen hoeveel fouten je procentueel op allebei hebt.
Ik heb net nog even TV gekeken. Ik heb twee ogen, dus ik heb naar twee zenders tegelijk gekeken (onfeilbare logica): vice HD en spike HD. Gelijktijdig, op dezelfde tuner, een kwartier lang. Log voor vice (video):
690,750 kHz/Viceland HD: H264 @ #4401: Continuity counter error, 2446 duplicate log lines suppressed
Log voor audio:
(dat is dus een lege regel)
Log voor spike:
(ook een lege regel)
Log voor audio:
(nog een lege regel)
Mogelijke verklaringen:
Als elementary streams zich binnen de frequentie groeperen en vice video bijvoorbeeld vooral in 696 tot 698Mhz zit dan kan het een signaalprobleem zijn dat zich alleen op die heel specifieke frequentie voordoet en niet op 690-696Mhz. Ik denk niet dat het zo werkt, volgens mij gaat alles gewoon door elkaar in de TS.
Andere verklaring: tvheadend bug. Echt heel bijzonder dat die bug zich dan alleen voordeed op twee kanalen met dezelfde content maar een andere codec en frequentie. En nog bijzonderder dat de bug zichzelf op één zender heeft opgelost zonder software update.
Dus dit wil er bij mij ook niet echt in.Andere andere verklaring: usb en/of tuner gaat over de zeik door iets in de ts. Zo was er ook eens een router op de markt die zichzelf resette als iemand in een chatbox een bepaald woord riep. Dit zou dan de naam van de zender of de EPG-inhoud ofzo moeten zijn aangezien het probleem zich eerder ook voordeed op de SD variant.
Andere verklaring: Ziggo heeft de continuity counter verneukt.
Ik ga nog eens proberen de hele ts op te nemen. aan het uppen https://mega.nz/#!JQQm2IT...bkjw4qCzQ2jDbuhEPAwDPW7Dw
Verstuurd vanaf mijn Computer®
Oké, ik weet niet wat je precies doet dus geef ik mogelijke scenario's. Jaren geleden in het Multikabel tijdperk wel eens mee geanalyseerd aan een Samsung PVR ontvanger probleem waarbij sommige forum bezoekers bleven volhouden dat ze het probleem op alle kanalen hadden terwijl dat technisch onmogelijk was. Toen duidelijk was geworden dat het een gevalletje corrupte datastructuur was dat zich alleen voordeed bij een aantal veel bekeken kanalen werd ook duidelijk dat het in feite dus alleen de interpretatie van die bezoekers was geweest dat het om alle kanalen ging. Dat maakt het onderzoek er niet eenvoudiger op.
Het zou natuurlijk kunnen dat een ontvanger niet naar de continuity counter kijkt en de boel altijd in volgorde verwerkt. Die continuity counter is er echter om de ontvangers te laten signaleren dat er iets niet klopt en de packets dus niet verwerkt kunnen worden tot een grotere data structuur op een hoger protocol level. Voor een ontvanger zit er niets anders op dan de boel te droppen en de draad weer op te pakken bij het eerst volgende packet met een gezette payload unit start flag. Dat neem je waar als een verstoring tijdens de weergave.
De MPEG packets worden in de headend in volgorde van verzending genummerd en als een bitstream. De ontvanger groepeert de bits tot bytes en de bytes tot packets. Meerdere packets te samen vormen een grotere datastructuur die uiteindelijk verwerkt zal worden. Rommelen met volgordes of het invoegen van lege packets zal weer leiden tot corruptie van die grotere datastructuur.
Het was de output op basis van jouw Viceland HD opname. Als ik zelf met DVBViewer een opname van Viceland HD maak en die door mijn tooltje haal, dan heb ik met uitzondering van de signaal verstoringsmomenten die ik hier lokaal af en toe ervaar geen continuity counter errors met dezelfde rate zoals die in jouw opname voorkomen. Ik trek daaruit vooralsnog de conclusie dat de nummering van de packets zoals door de headend verzonden in orde is. We krijgen immers allemaal hetzelfde digitale RTV broadcast signaal.
Goed dat het gelukt is. Om te beginnen heb ik de transport stream capture met TransEdit bekeken:
Geen missing packets voor Viceland HD. Wel een aantal voor ID HD, Ziggo Sport Golf HD en Spike HD. Die missing packets treden helemaal aan het begin van de capture op, dus kan het ook een tuner afstemming hickup zijn geweest. De rest van de capture lopen de missing aantallen niet meer op zoals wel het geval was in de Viceland HD opname. Als ik de capture door mijn tooltje haal worden er geen continuity counter errors gerapporteerd.
Op basis van deze transport stream capture lijkt er met het ingangssignaal van de PC software lijkt dus niets aan de hand te zijn. Misschien gaat er bij de decryptie van de packets iets niet helemaal lekker waardoor ze in een andere volgorde worden weggeschreven in het opname bestand?
Mijn tuner hikt inderdaad heel vaak bij het afstemmen. De driver zou misschien iets langer moeten wachten voor hij echt gaat streamen maar dan zou de zapsnelheid ook slechter worden dus daar zullen keuzes gemaakt zijn. Het zapt vlot en het werkt prima dus ik denk dat ze de juiste keuzes gemaakt hebben.
Oplossing is trouwens om de eerste seconde van een opname gewoon eraf te knippen.
Met decryptie bedoel je irdeto/smartcard? Dat is het volgens mij dus ook niet want tvheadend spuugt dezelfde continuity counter errors wanneer ik de decryptie onklaar maak.
Ik gebruik tvheadend gewoon om programma's op te nemen. Daarbij schrijft tvheadend gewoon een TS weg dus dat kost bijna niets aan processorkracht. Begint toch op een bug te lijken..
Als je nog van een andere frequentie een opname wil gil je maar, ik weet nu hoe het moet.
Verstuurd vanaf mijn Computer®
:strip_icc():strip_exif()/u/184432/crop5666ef06248fb_cropped.jpeg?f=community)
Een snelle check bevestigd inderdaad dat met 5555 de 444 lijst is incl. gecodeerde zenders.
Alleen maar lastig dus.
Bedankt voor je snelle en duidelijke reactie.
Zal morgen even een docsis capture maken voor je
Ja daarom juist, hopelijk gaat het allemaal goed, zoniet dan kan ik wel iemand van ziggo die hier x straat vandaan woont die hier vaak aan het werk is voor ziggo.
Er is weer het één en ander gewijzigd. Transport streams 3002, 3003, 2058 en 2057 zijn nu in mijn coaxsegment definitief uitgezet. Daarmee komt het totaal aantal RTV transport streams op 35 stuks. De vier uitgezette transport streams grenzen aan het DOCSIS downstream frequentie blok en zullen dus zeer waarschijnlijk weer in gebruik genomen gaan worden als downstreams waarmee het aantal downstreams in mijn coaxsegment op 24 stuks zal uitkomen. Op dit moment is het vrijgekomen frequentie gebied echter niet in gebruik.
De andere grotere wijziging is dat de transport streams waarin alle recent naar H.264 omgezette SD kanalen waren verzameld bij de wijziging van 14 juni nu knijp transport streams zijn geworden. Initieel hadden alle naar H.264 omgezette SD kanalen een constante bitrate van 3.2 of 3.1 Mbps, maar nu krijgen ze dezelfde behandeling als de HD kanalen in de HD knijp transport streams.
Voor transport stream 2102 ziet dit er dan als volgt uit:
Dus 12 SD kanalen mogen gezamenlijk maximaal zo'n 40 Mbps aan capaciteit gebruiken die ook volledig gebruikt wordt anders had de grens met de Null packets veel grilliger geweest. Ook valt op dat de initiele omzetting naar H.264 met een constante bitrate van 3.2 Mbps voor het gros van de kanalen nogal een beperking in de kwaliteit is geweest als de gemiddelde en maximum bitrate die bereikt wordt nu beduidend hoger ligt. Ook bij deze SD knijp constructie is kunnen we weer spreken van Never The Same Quality (NTSQ).
Ziggo/UPC heeft de volgende SD knijp transport streams in gebruik:
De andere grotere wijziging is dat de transport streams waarin alle recent naar H.264 omgezette SD kanalen waren verzameld bij de wijziging van 14 juni nu knijp transport streams zijn geworden. Initieel hadden alle naar H.264 omgezette SD kanalen een constante bitrate van 3.2 of 3.1 Mbps, maar nu krijgen ze dezelfde behandeling als de HD kanalen in de HD knijp transport streams.
Voor transport stream 2102 ziet dit er dan als volgt uit:
Dus 12 SD kanalen mogen gezamenlijk maximaal zo'n 40 Mbps aan capaciteit gebruiken die ook volledig gebruikt wordt anders had de grens met de Null packets veel grilliger geweest. Ook valt op dat de initiele omzetting naar H.264 met een constante bitrate van 3.2 Mbps voor het gros van de kanalen nogal een beperking in de kwaliteit is geweest als de gemiddelde en maximum bitrate die bereikt wordt nu beduidend hoger ligt. Ook bij deze SD knijp constructie is kunnen we weer spreken van Never The Same Quality (NTSQ).
Ziggo/UPC heeft de volgende SD knijp transport streams in gebruik:
- TS 2046 (11 SD kanalen)
- TS 2052 (13 SD kanalen)
- TS 2066 (12 SD kanalen)
- TS 2067 (11 SD kanalen)
- TS 2068 (12 SD kanalen)
- TS 2102 (12 SD kanalen)
/u/2205/nzflag_60x60.png?f=community)
Ziggo heeft de laatste tijd van alles aangepast op het netwerk om zo (volgens Ziggo) o.a. meer HD zenders door te kunnen geven. Vraag is wanneer komt Ziggo met meer HD zenders en welke zenders? Het netwerk (en vooral mijn tv 
) is er klaar voor.
) is er klaar voor.
/u/90048/DCP_0058.JPG?f=community)
Archie bedankt nog voor de lijst van Sassenheim, ik heb nu weer een hele schone zenderlijst
Ik vroeg me wel nog af wie van jullie er nog meer in Sassenheim/Teylingen zit en zich met digitale tv op de pc bezighoudt
Ik vroeg me wel nog af wie van jullie er nog meer in Sassenheim/Teylingen zit en zich met digitale tv op de pc bezighoudt
Mako4444
Hallo allemaal,
Ik krijg plotseling bij alles "afstem fout" te zien in dvblink tv source.. Ik probeer alle mogelijke frequenties te scannen, maar hij haalt niks meer binnen? Iemand enig idee? Ik heb de kabels gecontroleerd en die zijn goed..
EDIT: Nevermind.. Bleek toch de kabel te zijn
Ik krijg plotseling bij alles "afstem fout" te zien in dvblink tv source.. Ik probeer alle mogelijke frequenties te scannen, maar hij haalt niks meer binnen? Iemand enig idee? Ik heb de kabels gecontroleerd en die zijn goed..
EDIT: Nevermind.. Bleek toch de kabel te zijn
[ Voor 10% gewijzigd door powermarcel10 op 21-07-2017 00:59 ]
:strip_icc():strip_exif()/u/31644/george.jpg?f=community)
Met name Discovery Science is een welkome aanvulling voor me. Nu nog Discovery World en het lijstje daarvan is wel redelijk compleet van Discovery / NGC / History kanalen
:strip_exif()/u/128173/crop59a1592e54731_cropped.gif?f=community)
, ik krijg hier in tvheadend met een Anysee E30TC ook gecodeerde kanalen in de (incomplete) lijst van 4444 te zien.
[ Voor 12% gewijzigd door Raven op 28-07-2017 20:14 ]
After the first glass you see things as you wish they were. After the second you see things as they are not. Finally you see things as they really are, and that is the most horrible thing in the world...
Oscar Wilde
Het configureren van een ontvanger op basis van een netwerk ID is als het goed is zodanig geïmplementeerd dat alleen de Network Information Table (NIT) gebruikt wordt die geïdentificeerd wordt met de ingestelde netwerk ID. Een NIT bevat de set met frequenties van de RTV transport streams waarin de kanalen worden doorgegeven die tot de NIT behoren. Het signaal van Ziggo/UPC bevat meerdere van die NIT's zodat er een bepaalde set van kanalen en bijbehorende transport streams geselecteerd kan worden. Zie onderstaand het verschil tussen de NIT's behorende bij netwerk ID 5555 (links) en netwerk ID 4444 (rechts) (op basis van de Ziggo/UPC/Schoonbron capture)::
Netwerk ID 5555 bevat 38 transport streams en netwerk ID 4444 bevat 26 transport streams. De ID's en de inhoud van de transport streams is gelijk evenals de frequenties waarop ze worden doorgegeven in een bepaalde regio. Een NIT is namelijk slechts een verwijzing naar de transport streams die op de kabel gemoduleerd worden in een bepaalde regio. In de NIT van netwerk ID 4444 is bijvoorbeeld niet RTV transport stream 2050 opgenomen, maar aangezien hij wel in de NIT van netwerk ID 5555 zit zal die transport stream dus wel gewoon in de regio op de kabel aanwezig zijn en dus ook op alle adressen binnenkomen in de wijk ongeacht of er nu wel of niet naar een kanaal in de transport stream wordt gekeken. Het is immers een broadcasting systeem.
Zoals aangegeven is de inhoud van iedere transport stream gelijk voor iedere netwerk ID. Onderstaand op basis van de Ziggo/UPC/Schoonbron capture de inhoud van RTV transport stream 2049 zoals mijn tooltje weergeeft in de kanalen/frequentie overzichten:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| =================================================================================================================================
Transport Stream ID Network ID Network ID Network ID Network ID Network ID Network ID Network ID
Frequency Frequency Frequency Frequency Frequency Frequency Frequency
QAM/SR QAM/SR QAM/SR QAM/SR QAM/SR QAM/SR QAM/SR
---------------------------------------------------------------------------------------------------------------------------------
Service name Type Service ID LCN LCN LCN LCN LCN LCN LCN
=================================================================================================================================
2049 1536 3333 4444 5555 6666 43203
858,00 674,75 674,75 674,75 674,75 674,75
256/6,900 256/6,900 256/6,900 256/6,900 256/6,900 256/6,900
---------------------------------------------------------------------------------------------------------------------------------
24Kitchen 1 20001 24 - - 24(945) 24(945) 945
Animal Planet HD 25 20002 208 - - 208 208 208
SBS9 1 20004 19 - - 19(940) 19(940) 940
FOX 1 20006 11 - - 11(935) 11(935) 935
RTL 4 1 20010 - 4 4 4(928) 4(928) 928
RTL 5 1 20011 - 5 5 5(929) 5(929) 929
================================================================================================================================= |
Deze transport stream bevat dus 6 kanalen (services genoemd in DVB) en zijn ook allemaal continu aanwezig ongeacht de gebruikte netwerk ID. Er is qua definitie echter wel een verschil per netwerk ID, namelijk het Logical Channel Number (LCN). Als je in de kolom onder netwerk ID 4444 kijkt hebben alleen RTL 4 en RTL 5 een nummer gekregen in de kanalenlijst terwijl in de kolom onder netwerk ID 5555 alle kanalen een nummer hebben in de kanalenlijst. Sommige kanalen hebben zelfs twee nummers. Het eerste nummer is dan de plek in de SD kanalenlijst en het tweede nummer tussen de haakjes de plek in de HD kanalenlijst.
Die LCN definities bevinden zich ook in de NIT en Ziggo/UPC heeft één en ander dus zodanig geconfigureerd dat in de NIT behorende bij netwerk ID alleen de kanalen zonder encryptie (Free To Air (FTA)) een LCN hebben gekregen en de kanalen met encryptie niet. Die kanalen zonder LCN krijgen in het kanalen/frequentie overzicht een streepje. Zie onderstaand het voorbeeld van de LCN definitie in de NIT van netwerk ID 5555 en netwerk ID 4444 voor transport stream 2049 op basis van het live signaal in de regio Ziggo/UPC/Alkmaar:
Een door Ziggo/UPC "goedgekeurde" ontvanger is verplicht om de LCN te ondersteunen en zal dus wanneer netwerk ID 4444 wordt ingesteld alleen de kanalen in de uiteindelijke kanalenlijst opnemen die een LCN hebben in de geselecteerde NIT. Alle andere kanalen worden gewoon niet opgenomen terwijl ze natuurlijk wel in het signaal aanwezig zijn. Wederom op basis van de Ziggo/UPC/Schoonbron capture zou dit dan de kanalenlijst moeten zijn als netwerk ID 4444 gebruikt wordt:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
| ============================================================= Logical Channel Number (LCN) list 4444 - Schoonbron FTA ============================================================= LCN Service name Service ID Type TS ID ------------------------------------------------------------- 1 NPO 1 19041 1 2055 2 NPO 2 19042 1 2055 3 NPO 3 19043 1 2055 4 RTL 4 20010 1 2049 5 RTL 5 20011 1 2049 6 SBS6 19027 1 2054 7 RTL 7 19131 1 2059 8 Veronica / Disney XD 19061 1 2056 9 Net5 19448 1 2100 10 RTL 8 19121 1 2059 12 RTL Z 19430 1 2099 13 Ziggo TV 19516 1 2103 14 Ziggo Sport 19044 1 2055 15 Comedy Central 19062 1 2056 16 Spike 19421 1 2099 17 Discovery 19122 1 2059 18 National Geographic Channel 19165 1 2061 20 Eurosport 1 19167 1 2061 21 TLC 19164 1 2061 23 MTV 19449 1 2100 27 Disney Channel 19183 1 2112 29 Nickelodeon 19126 1 2059 30 L1TV 21144 1 2060 40 Lokale Omroep 19801 1 3004 41 Lokale Omroep 19802 1 3004 42 Lokale Omroep 19803 1 3004 43 Lokale Omroep 19804 1 3004 44 Lokale Omroep 19805 1 3004 45 Lokale Omroep 19806 1 3004 46 Lokale Omroep 19807 1 3004 47 Lokale Omroep 19808 1 3004 51 één 19004 1 2053 52 Canvas 19003 1 2053 53 Ketnet 19025 1 2054 54 ARD 19192 1 2112 55 ZDF 19067 1 2056 61 BBC One 19001 1 2053 62 BBC Two 19002 1 2053 503 CNN 19447 1 2100 504 BBC World News 19005 1 2053 607 Brava 20044 1 2051 701 TV Noord 19583 1 2107 702 Omrop Fryslân 19214 1 2062 703 TV Drenthe 19591 1 2107 704 TV Oost 19592 1 2107 705 TV Gelderland 19594 1 2107 706 Omroep Flevoland 19209 1 2062 707 NH 19211 1 2062 708 RTV Utrecht 19207 1 2062 709 TV West 19212 1 2062 710 TV Rijnmond 19208 1 2062 711 Omroep Zeeland 19213 1 2062 712 Omroep Brabant 19593 1 2107 713 L1 TV 19144 1 2060 725 AT5 19210 1 2062 800 Ziggo 19408 1 2098 801 NPO Radio 1 10311 2 2056 802 NPO Radio 2 10312 2 2056 803 NPO 3FM 10313 2 2056 804 NPO Radio 4 10314 2 2056 805 NPO Radio 5 10315 2 2056 806 Sky Radio 10216 2 2054 807 Radio 538 10116 2 2053 808 Q-Music 18042 2 2055 809 Radio Veronica 10317 2 2056 810 Radio 10 10118 2 2053 811 Arrow Classic Rock 18044 2 2055 812 Sublime FM 18043 2 2055 813 SLAM! 18048 2 2055 814 Classic FM 18046 2 2055 815 BNR Nieuwsradio 18045 2 2055 816 FunX 10217 2 2054 817 NPO 2 Soul & Jazz 18501 2 2103 818 Radio Decibel 18047 2 2055 819 Concertzender 10120 2 2053 820 Efteling Kids Radio 10117 2 2053 821 100% NL 18161 2 2061 822 Radio 8FM 18172 2 2061 824 Omrop Fryslân 18162 2 2061 825 Radio Flevoland 18169 2 2061 826 NH 18163 2 2061 827 Radio M Utrecht 18170 2 2061 828 Radio Gelderland 18164 2 2061 829 Radio Rijnmond 18165 2 2061 830 Omroep Brabant 18166 2 2061 831 L1 Radio 18167 2 2061 832 Radio Noord 10320 2 2056 833 Radio West 10323 2 2056 834 Radio Oost 10322 2 2056 835 Omroep Zeeland 10324 2 2056 836 Radio Drenthe 10321 2 2056 844 Radio 1 (VRT) 18186 2 2112 845 Radio 2 (VRT) 18187 2 2112 846 Studio Brussel 18189 2 2112 847 Klara 18188 2 2112 848 MNM 18190 2 2112 915 Lokale Omroep radio 18801 2 3004 916 Lokale Omroep radio 18802 2 3004 918 Lokale Omroep radio 18804 2 3004 919 Lokale Omroep radio 18805 2 3004 920 Lokale Omroep radio 18806 2 3004 921 Lokale Omroep radio 18807 2 3004 922 Lokale Omroep radio 18808 2 3004 925 NPO 1 HD 19401 25 2098 926 NPO 2 HD 19402 25 2098 927 NPO 3 HD 19405 25 2098 976 Ziggo Sport HD 19661 25 2074 978 Ziggo TV HD 19327 25 2069 981 Ziggo 19406 25 2098 996 Zender van de Maand 19589 1 2107 997 Testbeeld 19669 1 2074 999 Eventkanaal 19149 1 2060 ============================================================= |
Wat er bij de Anysee waarschijnlijk fout gaat is dat de implementatie geen ondersteuning biedt van de LCN. In plaats daarvan wordt de frequentielijst van de transport streams die uit de NIT van netwerk ID 4444 gebruikt om te scannen op kanalen en worden alle aangetroffen kanalen opgenomen in de kanalenlijst. Misschien kan je dan nog iets doen met een FTA selectie in de gebruikte DVB applicatie waarbij dan gekeken wordt naar de FTA vlag bij de kanalen in de Service Definition Table (SDT), maar helaas wordt die mogelijkheid door het niet zo snuggere Ziggo/UPC personeel om zeep geholpen omdat ze nalaten om de vlag correct in te stellen. Dat is kennelijk te hoog gegrepen voor ze.
@ArChie Wow, dat is nog eens een uitgebreide duidelijke uitleg 
Er wordt in de lijst met zenders (waar ook het nodige tussen staat met settopbox namen) wel aangegeven of iets wel/niet encrypted is, dus daar op selecteren is geen probleem. Daarbij zie ik net ook een filter daarvoor staan, dus mocht ik nooit wat met het encrypted spul gaan doen (geen idee of de smartcard reader van de Anysee inmiddels ondersteund wordt in raspbian/tvheadend), dan kan ik het encrypted spul gewoon weg filteren
"netwerk ID 4444 bevat 26 transport streams"
Check, helaas geven er een stuk of 10 (170, 409, 425, 498, 546, 570, 650, 666, 714 en 762MHz) fail aan bij het scannen, daar zullen de ontbrekende zenders wel mee te maken hebben gok ik. Ik mis rtl's 4 en 5 (sd+hd), rll's 7+8 (sd) en sbs6 (sd+hd) ontbreekt ook zie ik net, evenals sbs9 (sd), dat zijn i.i.g. die wat opvallen.
't logboek is helaas niet gedetailleerd: tvheadend[857]: mpegts: 425MHz in Ziggo - scan no data, failed
Er wordt in de lijst met zenders (waar ook het nodige tussen staat met settopbox namen) wel aangegeven of iets wel/niet encrypted is, dus daar op selecteren is geen probleem. Daarbij zie ik net ook een filter daarvoor staan, dus mocht ik nooit wat met het encrypted spul gaan doen (geen idee of de smartcard reader van de Anysee inmiddels ondersteund wordt in raspbian/tvheadend), dan kan ik het encrypted spul gewoon weg filteren
"netwerk ID 4444 bevat 26 transport streams"
Check, helaas geven er een stuk of 10 (170, 409, 425, 498, 546, 570, 650, 666, 714 en 762MHz) fail aan bij het scannen, daar zullen de ontbrekende zenders wel mee te maken hebben gok ik. Ik mis rtl's 4 en 5 (sd+hd), rll's 7+8 (sd) en sbs6 (sd+hd) ontbreekt ook zie ik net, evenals sbs9 (sd), dat zijn i.i.g. die wat opvallen.
't logboek is helaas niet gedetailleerd: tvheadend[857]: mpegts: 425MHz in Ziggo - scan no data, failed
After the first glass you see things as you wish they were. After the second you see things as they are not. Finally you see things as they really are, and that is the most horrible thing in the world...
Oscar Wilde
Hmm...
Ik woon in Enschede (fZiggo gebied), in tvheadend zie ik bij netwerk id 4444 de naam "Hengelo FTA" voorbij komen, verder zie ik niet zo gauw iets relevants. Of ik kijk op de verkeerde plek
After the first glass you see things as you wish they were. After the second you see things as they are not. Finally you see things as they really are, and that is the most horrible thing in the world...
Oscar Wilde
Oké, helaas heb ik van de regio Ziggo/UPC/Hengelo geen recente capture en dus ook geen recent kanalen/frequentie overzicht. Op basis van de informatie van april 2017 op de digitale kabeltelevisie website (http://www.digitalekabeltelevisie.nl/techniek/tvhome.shtml) zie ik dat Anysee op nogal wat transport streams geen lock kan krijgen (rood omkaderd)::
Ik woon in Enschede (fZiggo gebied), in tvheadend zie ik bij netwerk id 4444 de naam "Hengelo FTA" voorbij komen, verder zie ik niet zo gauw iets relevants. Of ik kijk op de verkeerde plek
Vermoedelijk een signaal probleem. Dit kan een te zwak of te sterk signaal zijn. Interferentie door externe zenders lijkt gezien de probleem frequenties onwaarschijnlijk.
En dat zijn nou net de frequenties waar hier een foutmelding bij staat
Kan die lock niet handmatig gedaan worden?Met extern doel je denk ik op 4G en DVB-T? Ik gebruik Koka 9TS en KOKWI/KOSWI 5, dus tenzij de boel niet goed aangesloten zit zou dat (binnenshuis i.i.g.) geen problemen moeten veroorzaken. Hoe het buiten met de kabel zit, geen idee. Ik kan later e.v.t. een settopbox aan de kabel bij de Pi hangen en kijken wat die qua signaalsterkte aangeeft.
After the first glass you see things as you wish they were. After the second you see things as they are not. Finally you see things as they really are, and that is the most horrible thing in the world...
Oscar Wilde
Sorry, ik zie dat ik mijn reactie niet lekker verwoord had. Ik had jouw probleem frequenties opgezocht in de lijst op de digitale kabeltelevisie website om te verifiëren of de Anysee de correcte frequenties ophaalt uit het signaal. Die probleem frequenties behoren tot de set van Hengelo waaruit geconcludeerd kan worden dat het de Anysee niet lukt om een lock te krijgen op die frequenties. Dat is meestal een gevolg van een signaalsterkte probleem. Het signaal is dan zodanig slecht dat de ontvanger er geen transport stream in herkend.:
En dat zijn nou net de frequenties waar hier een foutmelding bij staat
Bijvoorbeeld, op de probleem frequenties worden in jouw regio echter nauwelijks externe zenders doorgegeven, dus heb ik aangegeven dat interferentie me onwaarschijnlijk lijkt als oorzaak.
Dat is het onderzoeken waard.
Heb een Fox Z erbij gepakt, die aangesloten op de kabel wat aan de Anysee zat, via Mijn Ziggo de smartcard een schop onder de kont gegeven (blijkbaar nodig bij langdurig geen gebruik) en toen zag ik dit:
De zenders die in tvheadend ontbreken waren op de Fox Z gewoon te bekijken, geen problemen. Gezien de sterkte van 55% maar even de korte kabel tussen AOP en splitter (metalen, niet zo'n plastic ding) ertussen weg gehaald, sterkte veranderde niet. Die zat ertussen omdat de splitter de andere connectors blokkeerde, maar aangezien die toch ongebruikt zijn, weg ermee
Toen de Anysee weer aangesloten en Pi aangezet, inmiddels heeft ie 320 diensten gevonden en nu zijn er nog maar 2 muxes die een fail geven
: 409 en 425MHz.De Rtl's (op 4+5 hd na) en SBS6 zijn nu wél zichtbaar en te bekijken
Wel jammer dat Fox niet te bekijken is, encrypted, op de Fox Z kan ik die wel kijken. Dat wordt denk ik op zoek naar een smartcard reader, aangezien die in de Anysee volgens mij niet eens gedetecteerd wordt en er nooit ondersteuning voor in Linux is ingebouwd. Staat blijkbaar al jaren op de to do lijst van iemand...
After the first glass you see things as you wish they were. After the second you see things as they are not. Finally you see things as they really are, and that is the most horrible thing in the world...
Oscar Wilde
Het vervelende is dat de ene tuner de andere niet is. Wat voor de ene tuner nog voldoende signaal is kan voor een andere tuner net te weinig zijn. De signaalsterkte uitgedrukt in een percentage geeft ook niet echt veel informatie. Qua onderzoek zou je dan van alle gebruikte frequenties het percentage moeten noteren en dat vergelijken met de frequenties die wel goed werken op de Anysee om zo de ondergrens van het signaalsterkte percentage op de FOX Z te kunnen vaststellen waarbij de Anysee nog werkt. De signaalsterkte verschilt namelijk per frequentie. Zie onderstaand bijvoorbeeld een meting met een FRITZ!WLAN Repeater DVB-C aangesloten op de data uitgang van een UMU-1006T die op een DIO-01 AOP geplaatst is::
De zenders die in tvheadend ontbreken waren op de Fox Z gewoon te bekijken, geen problemen. Gezien de sterkte van 55% maar even de korte kabel tussen AOP en splitter (metalen, niet zo'n plastic ding) ertussen weg gehaald, sterkte veranderde niet. Die zat ertussen omdat de splitter de andere connectors blokkeerde, maar aangezien die toch ongebruikt zijn, weg ermee
De FRITZ!WLAN Repeater DVB-C heeft moeite met de foutloze doorgifte van DVB kanalen in transport streams die op frequenties zitten met een signaal sterkte lager dan -10 dBmV. In december vorig jaar heb ik een onderzoekje gedaan naar de signaalsterkte van de verschillende uitgangen:
ArChie in "[EuroDOCSIS] Capaciteit monitoren met een DVB-C PC-TV tuner"
Als je die splitter er nog steeds niet tussen hebt zitten nadat je opnieuw de Anysee hebt aangesloten, dan is vermoedelijk een te zwak signaal de oorzaak. Iedere splitter zorgt namelijk voor demping en door het verwijderen van die splitter heeft de Anysee kennelijk net voldoende signaal om nu wel op de probleem frequenties een lock te krijgen op de transport stream. Dat zou je kunnen onderzoeken door de splitter weer terug te plaatsen en nog een keer een scan uit te voeren. Als je dan weer meer probleem frequenties hebt is mogelijk een versterker de oplossing voor je signaal problemen.Toen de Anysee weer aangesloten en Pi aangezet, inmiddels heeft ie 320 diensten gevonden en nu zijn er nog maar 2 muxes die een fail geven
Er zal vast een geadviseerde smartcard reader oplossing zijn voor TV Headend. Mogelijk dat ze je daarmee in het TV Headend topic verder kunnen helpen.De Rtl's (op 4+5 hd na) en SBS6 zijn nu wél zichtbaar en te bekijken
Hmm.... Ik heb volgens mij niet iets liggen waarmee ik dat zou kunnen doen. Alhoewel, zou je met een oude niet-geactiveerde modem iets kunnen doen op een aansluiting waar alleen een tv-abo actief is? Type zou ik even op moeten zoeken, maar dacht dat het een Ubee was.
Ehm, volgens mij was ik niet echt duidelijk
D'r ging van het AOP naar de splitter (zoiets als deze) een korte coaxkabel, die kabel heb ik er tussenweg gehaald, niet de splitter. Aangezien de vrouw des huizes tv aan het kijken was heb ik de splitter laten zitten om haar niet (lang) tot last te zijn. Kan later wel even zonder splitter proberen.Maar aangezien het een antiek goedkoop dingetje is heb ik sowieso al een bestelling geplaatst voor een moderne splitter van Hirschman (de DFC 2104 dacht ik). D'r zwerft hier ergens al wel een versterker (niet Hirsschmann overigens), eveneens met F-connectors, dus mocht het vervangen van de splitter niet voldoende zijn kan ik er later zo een versterker voor in de plaats zetten.
Ok
After the first glass you see things as you wish they were. After the second you see things as they are not. Finally you see things as they really are, and that is the most horrible thing in the world...
Oscar Wilde
De Ubee modems hebben of hadden die mogelijkheid via poort 8080:
Zie ook:
https://ziggoforum.nl/topics/88819/
https://ziggoforum.nl/topics/82504/
Via Marktplaats voor een appel en een ei te koop. Voor een frequentie spectrum analyzer een koopje. Geen idee of andere kabelmodems ook dergelijke functionaliteit hebben.
[ Voor 23% gewijzigd door ArChie op 30-07-2017 11:41 ]
Net even gesnuffeld op zolder, een EVM3200. Later maar eens kijken of dat ding ook een spectrum analyzer heeft. Het zou ook nog kunnen dat er ergens een groot wit routerloos bakbeest ligt dat 10j terug (ten tijde van @home) ofzo standaard werd geleverd
[ Voor 10% gewijzigd door Raven op 30-07-2017 15:36 ]
After the first glass you see things as you wish they were. After the second you see things as they are not. Finally you see things as they really are, and that is the most horrible thing in the world...
Oscar Wilde
Dat was even een klusje, maar ziehier:
Bij elkaar geknipt en geplakt voor een resolutie van 250 kHz. Dit is gemeten vanaf de Data-uitgang van een UMU-1006T op een DIO-01.
Dan zullen we @Donderstraaltje heel lief aan moeten kijken, om te vragen of hij nieuwe captures zou willen maken en opsturen o-)
@ArChie Mijn downstreams zitten volgens de DOCSIS status pagina op +1.6 (210 MHz) tot +3.6 dBmV (258 MHz).
Ik zal op een later moment even proberen om op dat analoge TV-kanaal af te stemmen. Men zit nog naar het damesvoetbal te kijken maar ik ga slapen
Ik zal op een later moment even proberen om op dat analoge TV-kanaal af te stemmen. Men zit nog naar het damesvoetbal te kijken maar ik ga slapen
[ Voor 3% gewijzigd door Jerrythafast op 30-07-2017 22:31 ]
After the first glass you see things as you wish they were. After the second you see things as they are not. Finally you see things as they really are, and that is the most horrible thing in the world...
Oscar Wilde
Hier is Discovery Science eraf nu en de HD variant is er voor in de plaats gekomen... dus ook hier is het begonnen. Voor mij was dat ook de enige zender van de 3 die enigszins een beetje interessant is soms .
Kijk het nog ff na e dan stuur ik 474 + de eerste downstream op.
.Kijk het nog ff na e dan stuur ik 474 + de eerste downstream op.
Ah, blijkbaar had ik wat verder moeten Googlen. Ach, het andere type komt morgen waarschijnlijk aan
After the first glass you see things as you wish they were. After the second you see things as they are not. Finally you see things as they really are, and that is the most horrible thing in the world...
Oscar Wilde
Transedit vindt Xite wel al een tijd, maar DVBviewer niet echt.
Op het eerste gezicht zie ik er niks fouts aan.
Edit: handmatig toevoegen en dan scannen pikt hij hem wel op... dus hij staat in een table ergens niet helemaal goed waardoor hij niet opgepikt wordt (door niet Ziggo apparatuur?).
[ Voor 35% gewijzigd door Donderstraaltje op 01-08-2017 14:42 ]
Discovery Science HD is in SD knijp transport stream 2064 in plaats van de SD uitvoering gekomen. Daarmee is het dus een SD/HD knijp transport stream geworden. Het was al een behoorlijke verzameling van kanalen wat de bitrate van Discovery Science HD niet goed doet. 4.62 Mbps gemiddeld voor een HD kanaal is niet veel met een variatie van 0.05 Mbps. Nagenoeg een constante lage bitrate dus:
Motorsport TV HD is in SD knijp transport stream 2066 in plaat van de SD uitvoering gekomen. Ook deze transport stream is nu een SD/HD knijp transport stream geworden. Motorsport TV HD krijgt wat meer ruimte met een gemiddelde 9.12 Mbps, maar dat heeft natuurlijk tot gevolg dat de overige SD kanalen nu nog meer geknepen worden dan voorheen.
XITE HD is zoals eerder aangegeven terecht gekomen in HD knijp transport stream 2076. Het gevolg is dat de bitrate van 24Kitchen HD, HISTORY HD, Nat Geo Wild HD en Travel Channel HD omlaag is gegaan aangezien er nu één HD kanaal meer is waarmee de capaciteit van zo'n 40 Mbps gedeeld moet worden.
Er is nog steeds een onbekende HD service met service ID 13341 in transport stream 2070. In eerste instantie dacht ik dat die onbekende HD service Discovery Science HD zou worden, maar kennelijk is het toch een ander kanaal met een constante bitrate van 10.7 Mbps. Wie weet welk kanaal dit is mag het zeggen.
Motorsport TV HD is in SD knijp transport stream 2066 in plaat van de SD uitvoering gekomen. Ook deze transport stream is nu een SD/HD knijp transport stream geworden. Motorsport TV HD krijgt wat meer ruimte met een gemiddelde 9.12 Mbps, maar dat heeft natuurlijk tot gevolg dat de overige SD kanalen nu nog meer geknepen worden dan voorheen.
XITE HD is zoals eerder aangegeven terecht gekomen in HD knijp transport stream 2076. Het gevolg is dat de bitrate van 24Kitchen HD, HISTORY HD, Nat Geo Wild HD en Travel Channel HD omlaag is gegaan aangezien er nu één HD kanaal meer is waarmee de capaciteit van zo'n 40 Mbps gedeeld moet worden.
Er is nog steeds een onbekende HD service met service ID 13341 in transport stream 2070. In eerste instantie dacht ik dat die onbekende HD service Discovery Science HD zou worden, maar kennelijk is het toch een ander kanaal met een constante bitrate van 10.7 Mbps. Wie weet welk kanaal dit is mag het zeggen.
Constante hoge bitrate, dat is meestal gereserveerd voor een voetbalzender of NPO
. Komt er binnenkort een extra eredivisie live zender bij?
Op basis van een aantal woorden in de Nederlandstalige DVB ondertiteling lijkt op dit moment de film "Escape to Witch Mountain (1975)" uitgezonden te worden op dit onbekende kanaal. Het is dus in ieder geval geen voetbal kanaal.:
Constante hoge bitrate, dat is meestal gereserveerd voor een voetbalzender of NPO
Zoals bij iedere wijziging lukt het Ziggo niet om alle gewijzigde zenders op het juiste kanaal te zetten via het alternatieve netwerk voor oudere modellen Philips TV's. 
De zender XITE HD staat op kanaal 954 i.p.v. kanaal 25. De overige gewijzigde kanalen staan wel juist.
De zender XITE HD staat op kanaal 954 i.p.v. kanaal 25. De overige gewijzigde kanalen staan wel juist.
En net zoals altijd lijkt het er ook op dat ze weer een zender hebben die niet lekker scant op niet-Ziggo apparatuur. Vooral Philips tv's zijn hier inderdaad nogal eens slachtoffer van. Bij mij moet ik Xite dit keer handmatig toevoegen want dvbviewer pikt hem niet op, dit is weer iets nieuws.:
Zoals bij iedere wijziging lukt het Ziggo niet om alle gewijzigde zenders op het juiste kanaal te zetten via het alternatieve netwerk voor oudere modellen Philips TV's.
De zender XITE HD staat op kanaal 954 i.p.v. kanaal 25. De overige gewijzigde kanalen staan wel juist.
Het zou eens wat zijn als na onderhoud er geen problemen zijn...
Naast bovenstaande valt mij nog op dat de Humax digitale tv ontvangers de zender Motorsport.tv HD niet ziet als een HD zender. De Humax geeft wel aan dat de zender in1080i uitzendt maar geeft geen HD logo aan.:
Zoals bij iedere wijziging lukt het Ziggo niet om alle gewijzigde zenders op het juiste kanaal te zetten via het alternatieve netwerk voor oudere modellen Philips TV's.
De zender XITE HD staat op kanaal 954 i.p.v. kanaal 25. De overige gewijzigde kanalen staan wel juist.