WanWizard

Ideally this should be a config switch with the options "continue", "restart", "ask". So you can also opt not to see that message at all if you always want to start at the beginning.

De webif is een externe plugin, daar hebben we geen invloed op.

Je zou je vraag hier kunnen stellen: https://github.com/E...penWebif/issues

Ja.

En die is prima in te stellen. In de kanaal lijst, zender selecteren die je als startup wilt hebben, menu knop (in de kanaallijst dus), "startup service" (geen idee wat de NL optie is).

Het systeem werkt als volgt:

Het begint met de satelliet en transponder lijst (satellites.xml), die onderdeel is van OpenPLi, en wekelijks wordt bijgewerkt. Deze lijst wordt gebruikt om een satelliet de scannen, en het resultaat van de scan is de "all services" lijst, die wordt opgeslagen in een pseudo database (lamedb genoemd).

Op basis van deze lijst kun je favorieten lijsten maken, bouquetten genoemd, door een zender uit de "all services" lijst te selecteren en deze aan een bouquet toe te voegen.

"Fast scan" is daarbij een hulpmiddel. Een aantal providers zenden een lijst uit met alle zenders in hun pakket, deze lijst kan door de ontvanger worden opgepakt. In die lijst staat een zender mapping, en op basis daarvan kan OpenPLi een bouquet genereren met exact de zenders in de uitgezonden lijst, in de correcte volgorde. De provider gebruikt die lijst ook voor het bijwerken van hun eigen ontvangers.

Ten aanzien van aanpassingen:

OpenPLi bevat een feature met de naam "background scan", en dat staat standaard aan. Dit zorgt ervoor dat als je naar een zender zapt, er in de achtergrond een snelle scan plaats vindt op de transponder van die zender. En op basis daarvan wordt de "all services" lijst bijgewerkt. Dit kan er voor zorgen dat naamswijzigingen (zoals NED1 => NPO1) automatisch in de lijst verschijnen.

In principe is dit een eenmalige actie. Echter, die lijsten worden in het geheugen van de box bijgehouden, en pas weggeschreven naar de pseudo database zodra je de box (of enigma) herstart, via de afstandbediening. Als je ouders de box echter ga gebruik gewoon uitzetten (door de stroom er af te halen), dan zijn die wijzigingen weg, en staat er na opstarten weer NED1. Wat weer verandert naar NPO1 zodra je zapt naar een van de zenders op de transponder waarop NPO1 zit.

Er is geen enkel mechanisme om het verplaatsen van een zender te detecteren, dus dit kan niet automatisch. Dit kan alleen door een nieuwe scan (als de background scan de nieuwe zender al niet gevonden had), gevolgd door het handmatig aanpassen van het bouquet. Of door de fastcan opnieuw te draaien. Of een bouquet lijst gebruiken van iemand die dat voor je gedaan heeft.

Het zou op zich wel mogelijk zijn om bijvoorbeeld een change log van een site als lyngsat of kingofsat te halen, en daar rond een mechanisme te bouwen die bouquetten automatisch bijwerkt bij wijzigingen, maar tot op heden heeft niemand dat gebouwd.

Ja, die bonjour plugin er weer af halen.

Als je bedreven bent met telnet, kun je proberen direct na het booten in te loggen, en enigma2.sh en enigma2 te killen. Dat stopt het rebooten. Daarna kun je via opkg de plugin via de commandline verwijderen.

Als je dat niet ziet zitten dan wordt het opnieuw flashen.

Dit zal ook niet meer aangepast worden, de DM800 is al een tijdje end of life, en is blijven hangen op OpenPLi 2.1, welke al even niet meer ondersteund wordt.

Autotimer on Schwerkraft has a licence that restricts it's use to DMM hardware. So we can't use that version. Like so many other things on there.

I know a lot of people don't give a **** about that, but we play by the book. And that is why we can't merge it's updates, we use the last version that was available before the licence changed.

No worries, still working hard on it. It's rebuilding caches at the moment, so the database load is quite high...

Idioten.

Er is een klonenbakker die het nodig gevonden heeft in cron elke 5 minuten een 'opkg update' te runnen, en er is een andere klonenbakker die het nodig vind om in cron elke 5 minuten een xmltv download te runnen.

Aangezien de server die het forum runt tevens een download mirror draait voor zowel xmltv EPG als OpenPLi zijn er momenten waarop de boel volledig overbelast is, en de reverse proxy in een timeout loopt.

Er lopen een aantal initiatieven op dit aan te pakken. Op korte termijn worden de IP's van de mensen die deze images draaien geblokt in de firewall. In eerste instantie was dat voor een periode van 24 uur, wat er voor zorgde dat er elke avond (zeg tussen 10 en 12) een forse unblock / block again ronde liep, met een CPU spike op de firewall tot gevolg. Dit is nu aangepast zodat dit meer gespreid over de dag gaat verloopt, maar dat duurt even voordat dit effect gaat hebben.

Voor de wat langere termijn zijn we middelen aan het zoeken om het aantal servers en de capaciteit uit te breiden, zodat het forum separaat kan draaien van de andere functies, maar hiervoor is nog geen timing bekend.

They are misusing the OpenPLi brand.

I've been looking at a way to contact them, but they seem to be very good at hiding...

And this solution is running now.

An IP will receive a ban of 12 hours if it tries to download the channel index more than 5 times in 10 minutes.

I've started xmltvepg.wanwizard.eu again, and it was immediately flooded with request again. After a bit of startup lag, I now see IP's being banned in rapid succession, and the number of requests only go down slowly. So this might be a more widespread problem than we think.

I really like to meet the person that thought this was a good idea, and give him my 2 cents...   

Op basis waarvan concludeer je dat?

OpenPLi ondersteunt al tijden geen dreamboxen meer, dus het probleem van de 500HD interesseert ons vrij weinig. De communitie heeft zich bereid verklaard er naar te kijken, dus voor ons is daarmee de kous af. En ik begrijp dat de problemen gevonden zijn (gewoon veel te weinig flash, de image was te groot geworden), dus dat gaat wel weer goed komen.

Voor wat betreft de andere zaken: we werken nu eenmaal met automatisch gegenereerde nightly beta's, en niet met releases. Niemand dwingt je om dagelijks te updaten en op de bleeding edge te zitten. Sterker nog, voor een "woonkamer box" zou ik dat ten sterkste afraden. Als we met releases zouden werken, zoals vroeger, had je maar twee keer per jaar een nieuwe versie gehad.

We zijn al tijden druk bezig om het build proces te stroomlijnen, en daarbij moet flink gehakt worden. En daarbij vliegen, zoals het spreekwoord zegt, de spaanders in de rondte.

De eerste stap die we hebben gezet is de introductie van BSP layers (en dat is iets anders dan de branding), waarbij alle box specieke zaken in een aparte layer worden ondergebracht. Dit maakt het makkelijker nieuwe hardware te ondersteunen, de fabrikant kan die layer gewoon zelf aanleveren.

De tweede stap die nu bezig is, is een betere en snellere synchronisatie met Open Embedded. Voorheen deden we dat zelden of nooit, en was een update van OE een forse en tijdrovende operatie. En dit betekent dat we nu geconfronteerd worden met software van externe partijen uit het jaar nul, die niet meer (fatsoenlijk) door de auteur ondersteund wordt, en die niet meer compatible blijkt te zijn met de nieuwe versie van OE. En daar kom je pas op compile time achter. Aangezien dit voor ons hobby is, en geen betaalde fulltime job, kan dit betekenen dat het even duurt voordat het allemaal weer is opgelost. Zeker als het vakantie tijd is.

Het is een proces waar we met E1 ook doorheen gegaan zijn. Je begint met een fork, en dan start er een periode waarin je voorzichtig bent met het maken van structuele wijzigingen omdat je de aanpassingen nog van andere repo's (zoals bijvoorbeeld de upstream, of van andere teams) moet kunnen mergen. En na verloop van tijd wordt het besluit genomen dat los te laten, en de image als eigen product verder uit te bouwen. En pas dan kun je echt structurere aanpassingen maken die zorgen dat we verder vooruit kunnen.

Met E1 heeft niemand dat gemerkt, dat gebeurde achter de schermen in de 6 maanden tussen twee releases. Nu, met een nachtelijke automatische build, zit iedereen er met de neus bovenop, en is er ook heel weinig tijd tussen twee builds om zaken te implementeren of te repareren. Zeker als het over grote oefeningen gaat als een merge van OE.

Je kunt snel zien of het een probleem is met de ontvangst van de tweede tuner, door de eerste in de solo2 in de config even uit te zetten (op not-connected zetten), dan dwing je de box om de tweede tuner en aansluiting te gebruiken.

Dan wordt vrij snel duidelijk of het een ontvangst probleem op de solo2 is.

Ik doe hier de streaming naar een XP1000 (en die is vrij gelijk aan een ET4K), in de woonkamer dus altijd in gebruik (ik heb geen coax in de woonkamer), en ik heb daar geen problemen mee.

Helemaal mee eens. Dat er een opname buffer meeloopt is m.i. totaal niet relevant.

Zolang je live aan het kijken bent is er geen sprake van het bekijken van een opname, en moet die handel allemaal wegblijven.

Maar de feed wordt toch automatisch geupdate nadat de image klaar is?

Op de bouwserver, ja. Eens dat klaar is worden de resultaten verstuurd naar wat we noemen de "upload server", de bouwserver is niet internet bereikbaar, bovendien wil je alle power gebruiken voor compileren, en niet voor webservers en wat nog meer.

Deze upload server synchroniseert met de download mirrors via rsync. Dit werkt met een pull systeem, het zijn dus de mirrors zelf die de synchronisatie starten (de reden daarvoor is dat die mirrors onder beheer van derden (kunnen) zijn. Zowel de images als de feeds komen van de mirrors vandaan. Ook de website pollt de upload server voor de beschikbaarheid van images.

Het kan dus zijn dat de website de nieuwe image laat zien (want deze staat al op de upload server), maar dat (een van) de mirrrors om een of andere reden niet in sync zijn.

Correct. Nieuwe flat hier, en weinig vierkante meters, dus korte kabels...