94 replies to this topic

[christophecvr]

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.

Wel in de eerste plaats dien je een zéér solide basis en zéér zéér up to date te hebben . Zonder gebruik van satellite.xml   good luck , ik doe daar niet aan mee daar je werk gaat doen dat reeds door tal van anderen wordt gedaan en je zowiezo gaat achter lopen in termijn zonder rekening te houden met klassieke fouten zoals typo's dus ......

 

Ok als mensen gaan rommelen aan die satellite.xml en het loopt fout is dat hun probleem niet dat van pli off image maker. Maar iemand die weet wat hij doet kan een xml hebben die echt super is voor hem persoonlijk.

 

Aan bv een lamedb rommel ik bv nooit rechstrreeks. Nu daarvoor gebruik ik nu net de standaard scan tools die overigens 100 % ok zijn als de satellite.xml ok is  .

 

Maar zoals de lamedb nu is is het gemakkelijk voor sommigen die editors tools maken ok sommigen zijn niet ok anderen gewoon super. Tuurlijk ik werk enkel op linux dus heb ik daar niet veel aan. maar ach ja

Echt nodig zijn ze niet behalve een echt goede bouquets editor zou handig zijn niet echt een noodzaak.

 

Jawel er kan véél verbetering komen. Maar let op voor een nieuw wiel die een ouder 100 % goed draaiend zij het niet zo snel wiel vervangt. De problemen die er zijn komen voornamelijk van verkeerde tools of verkeerd editeren van de huidige lamedb en of satellite.xml. Op zich werken ze super goed en zéér stabiel.

[Zuppelan]

Je snapt het echt niet, hé?

Wat als je in de toekomst gewoon zou kunnen doen:

enigmadb import satellites.xml

Als het dan een beetje handig ontworpen is, dan is het waarschijnlijk ook nog wel mogelijk om het te doen zonder dat een herstart van Enigma noodzakelijk is en wordt het alleen maar makkelijker t.o.v. de huidige situatie.

[christophecvr]

Je snapt het echt niet, hé?

Wat als je in de toekomst gewoon zou kunnen doen:

enigmadb import satellites.xml

Als het dan een beetje handig ontworpen is, dan is het waarschijnlijk ook nog wel mogelijk om het te doen zonder dat een herstart van Enigma noodzakelijk is en wordt het alleen maar makkelijker t.o.v. de huidige situatie.

Ik snap het wel maar......

 

Ik ben zéér zéér bang , jullie (jij en WanWizard) gaan er véél véél te luchtig over.

 

1) volledig akkoord dat de enigmadb sterk kan worden verbeterd (zeg maar de lamdb die we nu hebben) maar hoewel de huidige beperkt is is ze zéér goed en stabiel betrouwbaar. Perfect nee dat is ze niet. Stabiel dat is ze wel.

    Dat sommige gebruikers erin rommelen en het dan op screwen is hun probleem.

 

2) Zelfs als je nu een volledig nieuwe lamedb maakt en wat met bestaande editors  ? ok velen zijn niet ok maar er zijn er ee paar echt super goeden. Paniek allom zal komen.

 

3) Wat met bestaande channel lists je hebt de downloadbare maar ook zéér zéér veel mensen hebben hun eigen gemaakt en dit op zich is meer dan een dag werk ?

 

en ......

 

Jullie gaan er ontzettend luchtig over maar enorm véél zal gebroken worden. Er komt ontzettend véél bij kijken .

Edited by christophecvr, 1 June 2016 - 17:19.

[WanWizard]

Ik ga helemaal nergens luchtig overheen, ik ontwerp al 30 jaar software systemen, en wel een stukje complexer dan dit.

 

Het is juist de bedoeling dat je met je vingers van die data af blijft. Die mag je alleen benaderen door een API die volledige validatie doet, en stabiliteit en integriteit garandeerd. Nogmaals, hoe de buitenwereld er mee omgaat is totaal niet relevant, die xml file is een transport medium, en geen opslag medium. Snap dat nu eens een keer. En niks te maken met "bestaande lists", dat is ook allemaal externe data.

 

Als je nu zou zeggen "er moet dat wel een interface komen om de buitenwereld met dit nieuwe systeem te laten omgaan" dan zou ik je nog gelijk willen geven, maar je blijft halstarrig naar die rotte xml files kijken...

[Zuppelan]

Ik denk dat hij in zijn laatste bericht doelt op bestaande externe tools die nu onder andere de lamedb wijzigen. Als de lamedb foetsie is, dan werken die gereedschappen niet meer. Dat is waar. Ik ben het er mee eens dat je niet zomaar externe tools zonder een goede reden onbruikbaar moet maken.

Maar... er lijkt hier wel sprake van een hele goede reden. En als je een externe API goed ontwerpt, dan schep je juist nieuwe mogelijkheden voor externe gereedschappen en kun je voorkomen dat je de boel in de toekomst weer moet omgooien. En externe gereedschappen kunnen natuurlijk geschikt gemaakt worden voor de nieuwe situatie. Als de hoeveelheid ontvangers overweegt die een PLi-image of een daarvan afgeleid image draaien, gaat dat vast goed komen.

[christophecvr]

Ik ga helemaal nergens luchtig overheen, ik ontwerp al 30 jaar software systemen, en wel een stukje complexer dan dit.

 

Het is juist de bedoeling dat je met je vingers van die data af blijft. Die mag je alleen benaderen door een API die volledige validatie doet, en stabiliteit en integriteit garandeerd. Nogmaals, hoe de buitenwereld er mee omgaat is totaal niet relevant, die xml file is een transport medium, en geen opslag medium. Snap dat nu eens een keer. En niks te maken met "bestaande lists", dat is ook allemaal externe data.

 

Als je nu zou zeggen "er moet dat wel een interface komen om de buitenwereld met dit nieuwe systeem te laten omgaan" dan zou ik je nog gelijk willen geven, maar je blijft halstarrig naar die rotte xml files kijken...

Juist die 30 jaar zou je toch duidelijk moeten maken dat je niet zonder de correcte info van een satellite.xml kan . Net die 30 jaar zou voldoende moeten zijn om toch het extreme stabiele karakter van de satellite.xml te begrijpen.  No frills no drills just correct info to the point. Een van de basis regels die tegenwoordig in databases echt worden genegeerd met alle gevolgen van dien. Trouwens de satellite.xml is een xml file maar eigenlijk wel degelijk ook een database file ok beperkt maar 100 % correct tenzij gebruikers ermeer rommelen.

[littlesat]

Als de NIT tabellen juist zijn dan heb je eigenlijk per satelliet maar 1 transponder nodig... de rest van de data wordt dan van de "satelliet" geplukt....

[Zuppelan]

Trouwens de satellite.xml is een xml file maar eigenlijk wel degelijk ook een database file

Dat is de kern van het probleem: XML is totaal ongeschikt als database. Ik geef het op. We hebben je de problematiek proberen uit te leggen en je aan het verstand proberen te brengen dat het in de rede ligt dat je ook in de toekomst de stabiele en correcte satellites.xml als gegevensbron kunt gebruiken. Ik heb niets toe te voegen zonder in herhaling.

[christophecvr]

Als de NIT tabellen juist zijn dan heb je eigenlijk per satelliet maar 1 transponder nodig... de rest van de data wordt dan van de "satelliet" geplukt....

Maar dat geeft eigenlijk nu véél te véél data. Vandaar de satellite.xml . Hoe dat dit alles is verwerkt verder in enigma2 dat natuurlijk is een andere zaak. Maar de satellite.xml is tot op heden mits bijgehouden 100 % correct gestructureerd en to the point. extreem belangrijk voor correcte scan van kanalen en (sat) tuners basis info. Clean up van kanalen in een bestaande database.

 

Dus : Hoe het nu is well het werkt zéér goed is echt stabiel. Als er wordt beweerd dat wat we nu hebben labiel is ...... wel dat is niet zo ouderwets wel. De mensen die zeggen dat wat we hebben labiel is terwijl dat 100 % niet is . Dan venieuwing willen hebben ? Jagen mij een zeer grote schrik aan. Daar in enorm veel gevallen gewoonlijk de zogenaamde moderne look van hen een complete chaos zijn en in hun  vernieuwingen  labiel een understatement wordt.

[christophecvr]

 

Trouwens de satellite.xml is een xml file maar eigenlijk wel degelijk ook een database file

Dat is de kern van het probleem: XML is totaal ongeschikt als database. Ik geef het op. We hebben je de problematiek proberen uit te leggen en je aan het verstand proberen te brengen dat het in de rede ligt dat je ook in de toekomst de stabiele en correcte satellites.xml als gegevensbron kunt gebruiken. Ik heb niets toe te voegen zonder in herhaling.

 

Ja zeker xml is ongeschikt als database . Dat heb ik dan ook nooit tegengesproken. Maar zolang de ploegen (en dat zijn er enorm véél ) hun vele werk nu tot zo'n file verwerken .... ben je eraan gebonden.

 

Wat betreft enigma2 zelf , wel ja je kan van de lamedb een echte database file maken maar daarbij zal je een convertie tool voor de huidige lamedb in de niewe om te zetten. Verder de hele bouquets structuur dient te worden gewijzigd uiteraard met opnieuw een tool om reeds bestaande bouquets te converten enz....

[Sagitarius †]

overlast, on 01 Jun 2016 - 15:21, said:overlast, on 01 Jun 2016 - 15:21, said:

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

Ik merk dat ook op mijn Zgemma H2H, op mijn ET8000 loopt alles tot nu toe goed, ik denk dat bepaalde ontvangers tegen de magische en kritische fec grens aanlopen van 30000.

Vooral op NPO1HD en NPO3 heb ik soms geen beeld of komt moeilijk op gang, ik ben benieuwd of die CDS bakjes hier ook problemen mee hebben, dan heeft CDS een vet probleem.

Edited by Sagitarius, 1 June 2016 - 19:53.

[christophecvr]

Ja blijkt dat sommige stb's problemen hebben daarmee.

 

vuduo2 en dm8000 alles ok.

[WanWizard]

Juist die 30 jaar zou je toch duidelijk moeten maken dat je niet zonder de correcte info van een satellite.xml kan . Net die 30 jaar zou voldoende moeten zijn om toch het extreme stabiele karakter van de satellite.xml te begrijpen.  No frills no drills just correct info to the point. Een van de basis regels die tegenwoordig in databases echt worden genegeerd met alle gevolgen van dien. Trouwens de satellite.xml is een xml file maar eigenlijk wel degelijk ook een database file ok beperkt maar 100 % correct tenzij gebruikers ermeer rommelen.

 

Lees nu toch eens keer!

 

Er is toch helemaal niemand die zegt dat je zonder die info kan? Ik zeg alleen dat je die info niet in een XML in de box moet opslaan. Dat zijn twee TOTAAL verschillende zaken, die niks met elkaar van doen hebben. In welk formaat die info buiten de box wordt opgeslagen of getransporteerd is totaal niet relevant. Al gebruik je rooksignalen.

 

En wat tools betreft: op dit moment hebben de tools ook een interactie met Enigma. Je moet ze vertellen welke versie je gebruikt, en ze gebruiken een API om Enigma een reload te laten doen als er data is geupdate. Nergens staat dat we dit tot in lengte van jaren zo moeten blijven doen. Als dat zo is dan moeten we hier gelijk allemaal stoppen, en terug gaan naar onze DM7000.

 

Je kunt innovatie en significante verbeteringen wel vergeten als je continue naar achteren en naar anderen blijft kijken. Er zijn verdomd weinig mensen hiermee bezig, de meeste doen niks anders dan een bestaand image pakken en die als een kerstboom aankleden. En daar gaan we de wereld niet mee winnen...

[catastrofus]

Precies, mijn ex had geen beeld meer op haar dm8k's maar ze heeft spontaan een fastscan gedaan en voila: beeld!

 

Ja blijkt dat sommige stb's problemen hebben daarmee.

 

vuduo2 en dm8000 alles ok.

[christophecvr]

 

Juist die 30 jaar zou je toch duidelijk moeten maken dat je niet zonder de correcte info van een satellite.xml kan . Net die 30 jaar zou voldoende moeten zijn om toch het extreme stabiele karakter van de satellite.xml te begrijpen.  No frills no drills just correct info to the point. Een van de basis regels die tegenwoordig in databases echt worden genegeerd met alle gevolgen van dien. Trouwens de satellite.xml is een xml file maar eigenlijk wel degelijk ook een database file ok beperkt maar 100 % correct tenzij gebruikers ermeer rommelen.

 

Lees nu toch eens keer!

 

Er is toch helemaal niemand die zegt dat je zonder die info kan? Ik zeg alleen dat je die info niet in een XML in de box moet opslaan. Dat zijn twee TOTAAL verschillende zaken, die niks met elkaar van doen hebben. In welk formaat die info buiten de box wordt opgeslagen of getransporteerd is totaal niet relevant. Al gebruik je rooksignalen.

 

En wat tools betreft: op dit moment hebben de tools ook een interactie met Enigma. Je moet ze vertellen welke versie je gebruikt, en ze gebruiken een API om Enigma een reload te laten doen als er data is geupdate. Nergens staat dat we dit tot in lengte van jaren zo moeten blijven doen. Als dat zo is dan moeten we hier gelijk allemaal stoppen, en terug gaan naar onze DM7000.

 

Je kunt innovatie en significante verbeteringen wel vergeten als je continue naar achteren en naar anderen blijft kijken. Er zijn verdomd weinig mensen hiermee bezig, de meeste doen niks anders dan een bestaand image pakken en die als een kerstboom aankleden. En daar gaan we de wereld niet mee winnen...

 

Ik ben helemaal niet tegen vernieuwing, integendeel zelfs. Maar vernietig niet ok zaken en dat is de satelitte.xml . Bouw en ontwikkel vernieuwing en ja MET de satellite.xml aanwezig op de box. Gebruik de echt updated info ervan .

 

Als je dat niet zou doen gaat zowiezo alle progressie met de toeters en bellen of whatever uiteindelijk een serieuze regressie zijn.

[theparasol]

Je kunt aan een plaintext ook een MD5 hash tag toevoegen.

De knutselaar wordt dan voortaan getrakteert op een nette fout melding in de geest van "tampered, invalid ... please replace!"

[mirakels]

heftige discussie....

 

of het nu text, gecompresste text of binarie of 'goed ontworpen' binary is, het is allemaal buiten de api om te wijzigen.

Genoeg applicaties gezien die met een database werken en een 'nette' api. Maar om dat de applicaties zo traag/beperkt/te interactief is zie je toch allerlei custom sql scripts ontstaan om de data te benaderen (en zelfs te wijzigen). Heb dat zelfs nu in mijn huidige project.

 

1e lessen zijn niet altijd heilig heren (dames ook). De 1e les van hedendaagse computerarchitectuur is: Begin met een cloud, en als dat niet voldoet neem je met een cloud. Een derde optie is een cloud en als zelfs dat niet kan gebruik je een cloud oplossing.

Van dat soort lessen wordt de wereld een paradijs.

 

Gegeven tijd en middelen kan je het zo mooi maken dat alle 1e lessen wel van toepassing zijn. Als iemand er eerst voor zorgt dat ik financieel onafhankelijk ben wil ik me wel op dat ideaal storten

[Zuppelan]

Er is een wet in de informatica en die zegt dat er iedere 5 jaar een nieuwe hype is. Een zeer wijze les, die helaas zelden als 1e les geleerd wordt, is nooit op die hype te springen, want daar gaan kapitalen in die na een paar jaar waardeloos zijn. In plaats daarvan moet je analyseren welk deel van de hype structureel is en daar op inspringen.

[Rob van der Does]

Het off-topic deel van het bovenstaande kort samenvattend is het duidelijk dat de huidige satelliet- en transponderstructuur niet voldoet aan elementaire eisen die aan een database gesteld zouden moeten worden; zowel qua inrichting als qua onderhoud van de data.

Ook duidelijk is dat het wel werkt en dat de huidige onderhoudsmiddelen daar (uiteraard) op ingericht zijn.

 

De interessante en nog onbeantwoorde vraag is natuurlijk of PLi dit oppakt en een goede database gaat ontwerpen, of dat we door blijven modderen met de huidige spaghettistructuur.

 

Overigens weet ik zeker dat als je de auteur van E-Channellizer bij zo'n project betrekt, hij er zeker voor zal zorgen dat dit onderhoudsmiddel de ontwikkelingen bijhoudt.

 

 

PS: het lijkt me wel noodzakelijk bij aanvang van zo'n (groot?) project eerst te inventariseren welke (belangrijke) plugins hierdoor (mogelijk) niet meer gaan werken en indien mogelijk contact met de betreffende auteurs op te nemen. Denk aan zaken als EPG-search, EPG-importtools en IMDb, maar er zijn er vast meer.

[littlesat]

En ondertussen doen we het met deze structuur al vanaf ergens in 2002....'het begin van de E1 tijd...