Jump to content


Photo

transponder wijzigingen Canal Digitaal 31 mei 2016


  • Please log in to reply
94 replies to this topic

Re: transponder wijzigingen Canal Digitaal 31 mei 2016 #41 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 1 June 2016 - 13:04

En het creëren van zulke aangepaste satellites.xml file lijd nogal eens tot problemen met epgimport en het gebruik van picons.

 

bv:

 

28.2 E wordt nogal eens ingevoerd met als positie 28.4  of 28.5.

of

4.8 E wordt nogal veel op positie 5.0 E gezet.  Ook 4.9 komt voor

 

(<sat name="28.2E Astra 2E/2F/2G" flags="1" position="282">)

 

Dit leidt dan tot een afwijkende service ref.  Dat werkt wel om naar de zender te kijken, maar de koppeling met EPG en picons loopt dan helemaal mis.

 

Mijn verzoek:

 

Blijf af van deze files. 

En het zou een goede zaak zijn als e.e.a. in een database verwerkt wordt welke niet door iedereen kan aangepast worden.

 

Willy

Actueel dat is een fout van de makers.

 

Normaal is de 28.2 altijd 282 maar sommige hebben daar 284 off 285 van gemaakt want natuurlijk niet ok is.  (p.s. het 28.2 covert wel twee sattelieten één op 28.2 en één op 28.4)

 

Maar als je met vaste antenne werkt (wat de meesten doen) kan je slechts één lnb gebruiken. Vandaar worden de transponders van de twee sattelieten samen in één lijst 282 gezet.

 

Uiteraard is nu net weer eens dreambox één die een uitzondering maakt op die regel namelijk zij werken niet standaard (er is géén iso norm voor maar ...) ze geven de satteliet key 284 als naam , niet de eerste keer dat dreambox weer eens afwijkt ...


Edited by christophecvr, 1 June 2016 - 13:06.


Re: transponder wijzigingen Canal Digitaal 31 mei 2016 #42 Zuppelan

  • Senior Member
  • 1,408 posts

+62
Good

Posted 1 June 2016 - 13:10

Nee, dat is geen fout van de makers, maar een fout van het systeem. Positie 28.2 en 28.5 zijn niet hetzelfde en op een grote schotel kan de mogelijkheid bestaan het onderscheid te maken. Tevens zijn er mensen die 9 en 10 oost op een kleine schotel met 1 LNB kunnen ontvangen.

Het zenderlijstensysteem maakt dit soort onderscheid niet goed mogelijk. Een zender zit op een transponder, een transponder zit op een satelliet, een satelliet heeft een positie en een LNB ontvangt doorgaans 1, maar zo nodig meerdere posities. De bestandsindeling moet een reflectie zijn van de werkelijke situatie en dat is nu niet het geval.

Re: transponder wijzigingen Canal Digitaal 31 mei 2016 #43 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 1 June 2016 - 13:11

Maar ik vrees dat er enige verwarring heerst tussen :

 

een goede database in e2 voor gescande kanalen ok maar .... vergeet niet alle andere externe zaken zoals epg , transponders zelf , met véél werk en moed en volhoudenheid de opmaak van bestaande kanalen lijsten bouquets ...

 

De satteliet basis up to date transponder info die wereldwijd één file heeft satteliet.xml ach ja daar hebben jammer genoeg sommigen weer eens afgeweken zoals dreambox.



Re: transponder wijzigingen Canal Digitaal 31 mei 2016 #44 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 1 June 2016 - 13:13

Nee, dat is geen fout van de makers, maar een fout van het systeem. Positie 28.2 en 28.5 zijn niet hetzelfde en op een grote schotel kan de mogelijkheid bestaan het onderscheid te maken. Tevens zijn er mensen die 9 en 10 oost op een kleine schotel met 1 LNB kunnen ontvangen.

Het zenderlijstensysteem maakt dit soort onderscheid niet goed mogelijk. Een zender zit op een transponder, een transponder zit op een satelliet, een satelliet heeft een positie en een LNB ontvangt doorgaans 1, maar zo nodig meerdere posities. De bestandsindeling moet een reflectie zijn van de werkelijke situatie en dat is nu niet het geval.

Zal dan wel een monster schotel zijn om voor 28.2   28.4 28.5 een lnb naast elkaar te zetten.

 

p.s. je kan wel met 3 schotels werken dit geeft dan een optimaal resultaat :P


Edited by christophecvr, 1 June 2016 - 13:15.


Re: transponder wijzigingen Canal Digitaal 31 mei 2016 #45 Zuppelan

  • Senior Member
  • 1,408 posts

+62
Good

Posted 1 June 2016 - 13:18

Bijvoorbeeld. Of als je een draaibare schotel hebt, dan heb je de luxe dat je de schotel exact op beide posities kunt laten afstellen. Maar ja, de draaimotor optimaal afstellen op 28,2 of 28,5 vereist dat er een onderscheid tussen beide in de transponderdatabase gemaakt wordt.

Dikke kans dat 28,4 bedacht is om een draaimotor enigzins tussen beide posities in te laten afstellen.

Edited by Zuppelan, 1 June 2016 - 13:18.


Re: transponder wijzigingen Canal Digitaal 31 mei 2016 #46 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 1 June 2016 - 13:25

Bijvoorbeeld. Of als je een draaibare schotel hebt, dan heb je de luxe dat je de schotel exact op beide posities kunt laten afstellen. Maar ja, de draaimotor optimaal afstellen op 28,2 of 28,5 vereist dat er een onderscheid tussen beide in de transponderdatabase gemaakt wordt.

Dikke kans dat 28,4 bedacht is om een draaimotor enigzins tussen beide posities in te laten afstellen.

28.4 ?? maar het bleef één lijst dus .... ook met vaste schotel set je de lnb zo in dat deze redelijk ok is voor de twee sattelieten. En dit gaat goed op 28.x de beam is zéér goed . Bovendien heb je reeds goed HD beeld met een snr van 6 db (wat zéér laag is) SD zelf tot snr van 5 db . Op die satteliet toch ;)


Edited by christophecvr, 1 June 2016 - 13:25.


Re: transponder wijzigingen Canal Digitaal 31 mei 2016 #47 WanWizard

  • PLi® Core member
  • 70,523 posts

+1,810
Excellent

Posted 1 June 2016 - 13:44

een goede database in e2 voor gescande kanalen ok maar .... vergeet niet alle andere externe zaken zoals epg , transponders zelf , met véél werk en moed en volhoudenheid de opmaak van bestaande kanalen lijsten bouquets ...

 

EPG, bouquetten, satellites.xml/cable.xml, de hele alternatives zooi, ongein rond black/whitelists, alles wat er mee te maken heeft moet dus ook die database in, anders schiet je er niks mee op.

 

En ja, dat heeft consequenties. So what. Het wordt tijd dan PLi zijn E1 reputatie van voorloper weer terugkrijgt, er ligt nu veel te veel still uit "angst" voor het breken van compatibiliteit met nu meer dan 10 jaar oude software.

 

Er valt veel te zeggen over DMM, maar dat lijken ze in hun huidige "DreamOS" wel begrepen te hebben.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: transponder wijzigingen Canal Digitaal 31 mei 2016 #48 mirakels

  • Forum Moderator
    PLi® Core member
  • 7,603 posts

+62
Good

Posted 1 June 2016 - 14:08

Sowieso is XML technisch gezien een draak van een bestandsindeling die een flinke hoeveelheid bloat met zich meebrengt, omdat XML structuurloos is en en een willekeurige karakterset kan worden opgemaakt, waardoor er een hele hoop Unicode-meuk nodig is om het bestand te lezen, terwijl er alleen maar wat getalletjes instaan over een transponder. Als een XML-bestand eenmaal geparset is, dan heb je weer redelijk veel code nodig om de resulterende boom te analyseren: Je kunt in C dan zegmaar niet satellite->transponder->symbolrate doen, maar moet check of deze elementen in de geparsete boom aanwezig zijn.

De libxml2.so.2 op mijn ontvanger is 1,5 megabyte groot, daar komt de code in Enigma2 om de gegevens verder te verwerken nog bij.

Een tekstuele indeling heeft voordelen omdat je die handmatig kunt editen, maar ik denk dat er best wat voor valt te zeggen voor een goed ontworpen binaire indeling. Ik weet niet of er verder in Enigma2 nog XML gebruikt wordt, maar dit soort complexe parsers dragen allemaal bij aan de opstarttijden en het geheugengebruik van Enigma2, terwijl transponderdata binair gewoon triviaal is om in te lezen. Zelfs als tekst gewenst is kan een eenvoudiger formaat de interne complexiteit al behoorlijk vereenvoudigen.

En in de hoeveelheid code van libxml2 past een redelijke database... geen volwaardige RDBMS, maar iets relationeels is vast wel mogelijk.

Waarom een binair formaat definieren, waarmee het een crime wordt om de datastructuur uit te breiden?

Ik eg niet dat xml fantatisch is, maar het heeft zo zijn voordelen.

De 'bloat' los je makkelijk op door de boel compressed op te slaan. Heb je toch nog een beetje een binary format.

(Hint: xml tags compressen als een gek. Kijk maar eens naar een excel spreadhseet in xml formaat van vroeger toemn microsoft nog niets van compressen wist, en de gecompresste versies van tegenwoordig).

 

 

Maar dit alles heeft niets met het topic onderwerp te maken. welk formaat ook gebruikt wordt, de transponder wijziging problemen hadden er toch wel geweest.

Dus als maak er een apart topic van als er een zinvolle discussie moet worden gevoerd over lamdeb en satellites.xml (en ja, ik zou het een zinvolle discussie vinden. )


Geen wonder... Had slechts een dm7000, maar wel ook een rotor. eigenlijk al een tijdje ook een dm600 en dm7025. Maar nu kijkend met een et9000 en vuduo

Re: transponder wijzigingen Canal Digitaal 31 mei 2016 #49 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 1 June 2016 - 14:12

 

een goede database in e2 voor gescande kanalen ok maar .... vergeet niet alle andere externe zaken zoals epg , transponders zelf , met véél werk en moed en volhoudenheid de opmaak van bestaande kanalen lijsten bouquets ...

 

EPG, bouquetten, satellites.xml/cable.xml, de hele alternatives zooi, ongein rond black/whitelists, alles wat er mee te maken heeft moet dus ook die database in, anders schiet je er niks mee op.

 

En ja, dat heeft consequenties. So what. Het wordt tijd dan PLi zijn E1 reputatie van voorloper weer terugkrijgt, er ligt nu veel te veel still uit "angst" voor het breken van compatibiliteit met nu meer dan 10 jaar oude software.

 

Er valt veel te zeggen over DMM, maar dat lijken ze in hun huidige "DreamOS" wel begrepen te hebben.

 

Dat er misschien een betere lamedb moet komen ja maar blijf af van de satellites.xml Deze is wel goed en niet vooroorlogs nog ouderwets.

 

Dat is data opgemaakt door één enorm aantal mensen juist correct en up to date en tja gegoten in een xml file zonder frills en drills maar zéér gestructureerd en stabiel. De labiele punten komen enkel van mensen die daar andere zaken dan de(algeheel aangenomen er is geen iso norm op de markt ervoor) standaards in willen zetten  zoals bv 284 i.pv. 282 enz ....

 

Natuurlijk kan je wel vragen aan de satteliet bedrijven van je dadatbase up te daten en hopen dat ze het doen ?? zij staan toe dat xml files worden gemaakt punt uit. Je kan je natuurlijk bezig houden met elke verandering zelf te verbeteren.

Hoe lang hou je dat vol ? hoeveel fouten gaan daarbij komen ? en hoeveel tijd ? dat is een 24/24 7/7 task en enorm saai .



Re: transponder wijzigingen Canal Digitaal 31 mei 2016 #50 overlast

  • Senior Member
  • 68 posts

0
Neutral

Posted 1 June 2016 - 14:21

Hallo,

 

Nu heb ik gisteren de transponder wijzigingen doorgevoerd. Maar op de kanalen waarop de wijzigingen zijn doorgevoerd, heb ik nu grote SNR schommelingen en dus haperingen in beeld en geluid.

Normaal heb ik een SNR van zo'n 14db. Het lijkt wel of hij een soort in een loop zit; Hij bouwt hem op tot 14db om dan vervolgens weg te vallen tot 0db. Vandaar dus de haperingen.

Hier had ik voor de wijzigingen geen last van. 

Iemand meer hier ook last van?

Het gaat om een Mutant HD2400



Re: transponder wijzigingen Canal Digitaal 31 mei 2016 #51 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 1 June 2016 - 14:27

@mirakels

 

Klopt als een bus wat we ook hadden de transponder veranderingen zouden zowiezo problemen hebben gegeven.

 Maar de satellites.xml is een file die pli voor zichzelf maakt met een gegeven script die acces heeft naar de databases van satellite providers . off algemeen aanwezig op internet satellite xml creator zoals bv.

 

http://satellites-xml.org/index.php?

 

Maar inderdaad een betere file dan lamedb want deze is inderdaad echt ouderwets zou niet slecht zijn maar een enorm werk. En iemand met véél skills zal dit moeten doen. Daar komen dan alle echt gebruikte transponders in of ze nu terestrial of satelliet zijn.

De correcte bestaande up to date transponder info zal tocj nog steeds van files als satellites.xml of terrestrial.xml moeten komen . Info gemaakt door derden



Re: transponder wijzigingen Canal Digitaal 31 mei 2016 #52 Zuppelan

  • Senior Member
  • 1,408 posts

+62
Good

Posted 1 June 2016 - 14:49

Als er een binair bestand of database komt, dan kan het script dat de satellites.xml nu ophaalt gewoon aangepast worden dat het bestand geconverteerd wordt. Als een conversietootlje onderdeel is van de image dan kun je jezelf ook in de toekomst helpen. Dit is dus zeker geen argument tegen het gebruik van een degelijker bestandsindeling.

Re: transponder wijzigingen Canal Digitaal 31 mei 2016 #53 WanWizard

  • PLi® Core member
  • 70,523 posts

+1,810
Excellent

Posted 1 June 2016 - 14:52

Dat er misschien een betere lamedb moet komen ja maar blijf af van de satellites.xml Deze is wel goed en niet vooroorlogs nog ouderwets.
 
Dat is data opgemaakt door één enorm aantal mensen juist correct en up to date en tja gegoten in een xml file zonder frills en drills maar zéér gestructureerd en stabiel. De labiele punten komen enkel van mensen die daar andere zaken dan de(algeheel aangenomen er is geen iso norm op de markt ervoor) standaards in willen zetten  zoals bv 284 i.pv. 282 enz ....


Zoals al eerder opgemerkt, je lijkt weinig van de discussie te snappen. Er is GEEN ENKELE relatie tussen de data en de manier van opslag!

Als er een proces bestaat, extern of niet, dat informatie produceert en die aanlevert in XML formaat, so be it. Dat impliceert helemaal niet dat je die data ook in dat formaat moet opslaan.

 

/edit: Zuppelan volgt de discussie blijkbaar wel. ;)


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: transponder wijzigingen Canal Digitaal 31 mei 2016 #54 Zuppelan

  • Senior Member
  • 1,408 posts

+62
Good

Posted 1 June 2016 - 14:55

Waarom een binair formaat definieren, waarmee het een crime wordt om de datastructuur uit te breiden?


Ik schreef:

best wat voor valt te zeggen voor een goed ontworpen binaire indeling.


Een binaire representatie die niet uitbreidbaar is, is mijns inziens een slecht ontworpen binaire indeling.

Ik eg niet dat xml fantatisch is, maar het heeft zo zijn voordelen.


Zeker, het voordeel is dat je er met je poten in kunt knoeien en dus zelf aanpassingen kunt doen. Maar dat is tegelijkertijd ook het nadeel: Je kunt met eigen geknoei allerlei foutieve situaties creëren die in Enigma2 een hoop code vereisen om ze netjes af te handelen. Als er een gereedschap is om bewerkingen op de toekomstige variant uit te voeren dan zijn die voordelen redelijk te behouden.

Re: transponder wijzigingen Canal Digitaal 31 mei 2016 #55 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+542
Excellent

Posted 1 June 2016 - 15:08

Ik zeg al jaren: het probleem met de satellites.xml en ook de lamededb en de bouquets, is dat de plaintext representatie suggereert dat je er zomaar vanalles mee kunt gaan klooien. Dat is niet de schuld van de plaintext representatie, dat is de schuld van de lui die dat ook daadwerkelijk gaan doen (de bouquet editors). In plaats daarvan zou er een nette api gedefinieerd moeten zijn/worden waarmee enigma zelf of een externe executable via een gedeelde library (met enigma) of direct via zo'n library aan de bouquet editor een api kunnen aanbieden die helemaal los staat van de opslagmethode.

 

Dat is ongeveer les #1 die je krijgt op de informatica-school. En nu zien je dus wat er gebeurt als je datastructuren onvoldoende/niet abstract maakt.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: transponder wijzigingen Canal Digitaal 31 mei 2016 #56 WanWizard

  • PLi® Core member
  • 70,523 posts

+1,810
Excellent

Posted 1 June 2016 - 15:29

Hadden ze bij DMM toch les #1 overgeslagen blijkbaar... ;)


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: transponder wijzigingen Canal Digitaal 31 mei 2016 #57 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 1 June 2016 - 15:35

Ik zeg al jaren: het probleem met de satellites.xml en ook de lamededb en de bouquets, is dat de plaintext representatie suggereert dat je er zomaar vanalles mee kunt gaan klooien. Dat is niet de schuld van de plaintext representatie, dat is de schuld van de lui die dat ook daadwerkelijk gaan doen (de bouquet editors). In plaats daarvan zou er een nette api gedefinieerd moeten zijn/worden waarmee enigma zelf of een externe executable via een gedeelde library (met enigma) of direct via zo'n library aan de bouquet editor een api kunnen aanbieden die helemaal los staat van de opslagmethode.

 

Dat is ongeveer les #1 die je krijgt op de informatica-school. En nu zien je dus wat er gebeurt als je datastructuren onvoldoende/niet abstract maakt.

De spijker op zijn kop.

 

Nu het klopt dat deze toppic zoals @mirakels zei best als een nieuwe wordt gemaakt om de eventuele modernisering van het geheel te bespreken.

 

Het is een zéér belangrijke toppic en ja de bestaande wijze is hoe je ook draait of keert vrij goed tot zéér goed. Ok het is een beetje ouderwets aan het worden maar goed en stabiel is het.

 

Ik heb nu bv als test een ouderwetse (ach ven een maand oud) satellite.xml gebruikt . dan een clean-up scan gedaan van één satelliet dus nu 23.5 is een perfect voorbeeld.

 

Instellingen eerst verwijderen van bestaande zenders (die in dit geval enkel die van de geselecteerde satelliet zijn) dan gescanned. En ja all de veranderde transponders channels in mijn bestaande bouquets waren grijs bij 23.5.

Werking ok en perfect.

 

Dan de satellite.xml vervangen door een juiste laatste heb ik heer nyu bijgevoegd (die enkel voor 4 sat's is als voorbeeld het spreekt voor zich dat pli een volledige moet maken)

Opnieuw een scan en jawell all mijn posten zijn terug geen problemen off vodden . Bovendien zijn alle niet meer bestaande zenders weg en de basis lamedb is weer kleiner.

 

Very last satellite.xml example (ok gelimiteerd tot mijn persoonlijke settings ) included.

Attached Files



Re: transponder wijzigingen Canal Digitaal 31 mei 2016 #58 christophecvr

  • Senior Member
  • 3,131 posts

+140
Excellent

Posted 1 June 2016 - 15:43

@WanWizard

 

Ik versta het héél goed maar ... denk verder dan een single database. Ik denk voornamelijk aan easy maintenance en stabiliteit. Ook in termijn correcte informatie.

 

Dus niet een nieuw wiel dat leuk lijkt maar uiteindelijk vierkant draait niettegenstaande alle nieuwe toeters en bellen en dit enkel om dat de basis waarmee wordt gewerkt niet wordt upgedate enkel omdet het een zo goed als onmogelijke  onderhouds job wordt.

 

Uiteindelijk een database is een database en als de info niet juist is werken alle verdere zaken afhankelijk van die informatie niet.


Edited by christophecvr, 1 June 2016 - 15:44.


Re: transponder wijzigingen Canal Digitaal 31 mei 2016 #59 littlesat

  • PLi® Core member
  • 57,166 posts

+698
Excellent

Posted 1 June 2016 - 15:54

De satellites.xml komt geloof ik elke vrijdag op zaterdag mee en wordt gegrabbed van lyngsat...


WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: transponder wijzigingen Canal Digitaal 31 mei 2016 #60 Zuppelan

  • Senior Member
  • 1,408 posts

+62
Good

Posted 1 June 2016 - 16:01

Stabliteit is nu juist dat wat erg lastig te garanderen is als mensen met de hand de gegevens inconsistent kunnen maken. Je kunt een .xml-bestand op oneindig veel manieren verknallen en ik betwijfel ten zeerste of Enigma2 in alle mogelijke foutieve situaties netjes blijft functioneren. Juist een degelijk ontwerp van de data, waarbij de consistentie van de bestanden door een manipulatiegereedschap gewaardborgd wordt, vermindert de hoeveelheid dingen die mis kunnen gaan.


2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users