94 replies to this topic

[littlesat]

Een satellites.xml lost dat niet op... alleen met nieuwe fixed transponders scannen....

 

De lamedb moet de nieuwe parameters krijgen....

 

En ergens is het gewoon jammer dat je een satellites.xml hebt en een lamedb - in beide staan transponders...

[Rob van der Does]

'tuurlijk.

Maar een gewone scan is niet mogelijk zonder de juiste transpondergegevens; nu moet je die zelf invullen terwijl die er bij een juiste xml automatisch staan.

[Rob van der Does]

En ergens is het gewoon jammer dat je een satellites.xml hebt en een lamedb - in beide staan transponders...

Maar de ene is om te scannen en de andere om te tunen. Plus dat in de lamedb alleen die transponders staan die ook daadwerkelijk gebruikt worden.

Edited by Rob van der Does, 31 May 2016 - 16:37.

[WanWizard]

De xml flauwekul moet gewoon afgeschaft worden, en samen met de epg in een fatsoenlijk ontworpen channel database gestopt worden. Als dat goed gedaan wordt dan volgen de externe tools vanzelf.

[littlesat]

Maar de ene is om te scannen en de andere om te tunen. Plus dat in de lamedb alleen die transponders staan die ook daadwerkelijk gebruikt worden.

-->

Ik weet waarvoor ze zijn... maar toch is dit compleet "verrueckt" zoals ze het op zijn Duits zouden zeggen... Maar zo zijn er al meer dingen in E2... alleen al de naam lamedb.... en dat is ook nog iets waar je niet zomaar meer vanaf komt...

[WanWizard]

Ja hoor. Gewoon doorbijten en doorvoeren.

 

Het zou wat zijn, als ze bijvoorbeeld in de autoindustrie gezegd zouden hebben "tja, we hebben nu eenmaal benzine, het heeft dus geen zin om motoren voor een andere brandstof te ontwikkelen", of "we hebben paard en wagen, waarom zouden we proberen dat paard te vervangen door een motor?".

 

Er is een limiet aan "backward compatibility". Lijkt me een mooie klus voor OpenPLi 6, beter werk dan al die cosmetische aanpassingen.

[doglover]

De ET-9500 die hier staat, heeft deze ochtend alles zelf aangepast.

Ik had direct beeld, zonder iets te moeten scannen.

 

Dus een happy bunny hier.

 

Willy

[christophecvr]

Sorry maar de xml werkt perfect en is 100 %

Niets zo eenvoudig en snel als een fastscan aan de basis van een xml file. Dat is wereldwijd gebruikt en op alle stb's.

 

Uiteraard gebruik ik een eigen xml file waar enkel de satellieten in zijn die ik nodig heb geen anderen.

 

Trouwens de verandering op 23.5 was enkel één satelliet scan 23.5 daarbij wordt de xml file gebruikt. 3 a 4 minuten en klaar alle kanalen terug zonder meer.

[WanWizard]

Tja, zo werkte paard en wagen ook voor een heleboel mensen...

[littlesat]

De fastscan doet helemaal niets met die xml... Die leest gewoon data in een carousel van een bepaalde transponder en pid...

Edited by littlesat, 31 May 2016 - 18:04.

[hro]

zie bijlage voor diegenen die het moeilijk vinden handmatig de Symbolrate aan te passen.

Attached Files

•  CD wijzigingen per 31 mei.pdf   133.97KB   57 downloads

[christophecvr]

De fastscan doet helemaal niets met die xml... Die leest gewoon data in een carousel van een bepaalde transponder en pid...

Ja ik bedoel gewoon sateliet scan die leest wel de xml en is zeer snel . Nee de xml file is ontzettend goed en zéér gestructureerd iets . En binnen de minuut kan je een upgedate xml file hebben die juist is.

[WanWizard]

Maar het is geen database, en mist functionaliteit die een database wel heeft. En die nu node gemist wordt.

[christophecvr]

Maar het is geen database, en mist functionaliteit die een database wel heeft. En die nu node gemist wordt.

Misschien maar:

 

Ze is 100 % juist (mits upgedate) Wat zéér éénvoudig is en de gegevens komen van een werledwijde correcte database die well zéér up to date is.

Het is ook werelwijd de gebruikte en enige juiste methode. Er mogen er anderen zijn maar die lopen achter zijn labiel en ....

 

Waarom :

 

1) Op een stb heb je enkel gegevens nodig van de satelieten die je will gebruiken.

    Wel zéér eenvoudig maak gewoon een aangepaste satelite.xml. Dan kan je zéér vlug je tuner config instellen

    nv ik werk enkel met 13.0 E 19.2 E 23.5 E en 28.2 E  (hierbij gevoegd de up to date xml.)

 

2) Je scant gebruikmaken van een up to date transponder list (geen onnodig tijverlies met full scan enz. ...) Je gegevens zijn correct.

 

3) De transponders veranderen zéér regelmatig dit voor de 4 satelieten die ik gebruik.

    Vandaar is het handig om bv je database toch zowat éénmaal in de maand echt op te kuisen.

    Wééral zéér eenvoudig scan één sateliet en verwijder de bestaande info voor de scan en hopla je lamedb die de database is is upgedate en gecleaned van onnodige niet werkend feeds.

 

4) Zéér weinig onderhouds werk voor anderen de xml is gemaakt voor U met upgedate database. Feeds bijhouden wordt anders een 24 uren 7 op 7 job Nu 1 minuut per maand. een een scan .

Attached Files

•  satellites.xml.zip   2.23KB   9 downloads

[WanWizard]

Je hebt het niet begrepen. Niets van deze opsomming heeft te maken met het medium waarmee je de gegevens opslaat.

[christophecvr]

De gegevens sla je op in lamedb na db na de scan toch ?

[WanWizard]

Zucht.

 

Het gaat er om dat de lamedb geen db is, maar een xml file. En dat er nog andere files zijn, en andere data is, die allemaal met elkaar gerelateerd zijn, en dat nu niet zijn. Wat een consistency hell oplevert, die nog een keer verergend wordt doordat de user er in zit te sleutelen.

 

Dat probleem los je op door alle data in een database te stoppen, fatsoenlijke relaties te definieren, foreign key constraints op te leggen, en er een fatsoenlijke API op te bouwen die de boel consistent houd. Die API moet je in staat stellen om "functioneel" hetzelfde te kunnen doen als nu, maar dan zonder dat je dingen sloopt (of kunt slopen).

 

Een database maakt het ook mogelijk om additionele data toe te voegen (zoals bijvoorbeeld de ondertitel instellingen per zender) zodat dat die niet verloren gaan als je een scan of import van een zenderlijst doet.

[Zuppelan]

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.

Edited by Zuppelan, 1 June 2016 - 12:53.

[christophecvr]

Ja ok maar dat is dan iets anders en heeft niets met de satellites.xml zelf te maken.

 

Wat je dus wil zeggen is de lamedb vervangen door een echte database file.

[doglover]

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