275 replies to this topic

[littlesat]

solved..

 

from urllib2 import urlopen
destination = "/home/root/testdir"
import shutil
from json import loads
import os
if os.path.exists(destination):
        shutil.rmtree(destination)
os.mkdir(destination)
test = loads(urlopen("http://192.168.1.10/file?dir=/etc/enigma2", timeout=5).read())
print test["files"]
for x in test["files"]:
        print x.encode("utf-8")

[littlesat]

Dit is een werkende dump via OWIF... Het is wel 'merkbaar' trager dan via FTP en ' ietsje' complexer. Maar het werkt wel goed. En de feitelijke kerncode buiten de lib imports is slechts 2 regels.... (moet wel een try/pass omheen als het in e2 gaat

 

 

Gewoon ff keizen FTP sneller.. of OWIF merkbaar trager....

 

Dit gaat wel spinners opleveren in E2 als je het zo maakt.. zonder spinners moet het ook nog ff 'slim' aangepakt worden... Ook zou overwegen kunnen worden dit stukje python aan te roepen via een Console... dan werkt het gewoon echt in een 'achtergrond'... 'iets' ofwel een techniek wat we nog nooit gedaan hebben... het script gaan dan op het einde een reload settings doen via OWIF... Dan zijn de aanpassingen in E2 zelf minimaal.

 

Dan heb je ook geen spinners e.d.... (bijvoorbeeld door aanroepen met console() python sync_settings.py var1 var2)

from urllib2 import urlopen
from json import loads
import os
 
url = "http://192.168.1.10"
destination = "/home/root/testdir"
if os.path.exists(destination):
        import shutil
        shutil.rmtree(destination)
os.mkdir(destination)
 
for file in [file.encode("utf-8") for file in loads(urlopen("%s/file?dir=/etc/enigma2" % url, timeout=5).read())["files"] if os.path.basename(file).startswith(('lamedb', 'bouquets.', 'userbouquet.'
        print file
        open("%s/%s" % (destination, os.path.basename(file)), "wb").write(urlopen("%s/file?file=%s" % (url, file), timeout=5).read())

Edited by littlesat, 19 February 2018 - 11:58.

[Huevos]

So no error handling in case the remote is not available?

[doglover]

For the user the difference between both the methods are:

 

1.  Via FTP.  You need to provide user and password.

2.  Via HTTP.  Open Webif needs to be installed.

 

I do not know which is to be preferred.

 

Willy

[littlesat]

Also for OWIF userid and/or password might be required... And this authorization was indeed not fully included in this 'pseudo' code

 

So no error handling in case the remote is not available? -> A script can also return an error code... this can trigger retry mechanism...

And error handling is not designed yet

Edited by littlesat, 19 February 2018 - 14:52.

[littlesat]

Oneliner om de epgcache file te vinden van de server box

fallbacktuner_epgcache_location = [x.strip().split('=')[1] for x in urlopen("%s/file?file=/etc/enigma2/settings" % url, timeout=5).readlines() + ["config.misc.epgcache_filename=/hdd/epg.dat"] if x.startswith('config.misc.epgcache_filename')][0]

Edited by littlesat, 19 February 2018 - 14:28.

[Rob van der Does]

Je blijft maar aan het ontwerpen, terwijl al deze ontwerpvragen nog onbeantwoord zijn:

 

 

Stap voor stap... eerst settings en epg... eerst eens
Een methode voor deze

OK, geen timers dus. Maar dan blijven de volgede vragen nog steeds over:

1-In plaats van en/of aanvullend op lokale settings ?

2- Auto/SemiAuto/Handmatig synchroniseren ?

3- Plugin/Embedded functionaliteit ?

 

Ik blijf erbij: eerst nadenken over wat er gewenst is, dan pas nadenken over hoe dat te realiseren. Anders krijg je weer een hink-stap-sprong beleid, met een grote kans op niet-intuïtieve spaghetti.

 

[littlesat]

Ik ben alleen maar bezig met functionele blokken die 'nodig' zijn... Zodat ze bij een ontwerp eventueel in elkaar kunnen vallen... Of het nu wel of niet gebruikt gaat worden is ook nog helemaal niet zeker. Maar voordat je 'ontwerpt' moet je ook ff wat chaos maken met een onderzoek na mogelijkheden. In dit 'voor' onderzoek vallen mijn suggesties hier.

 

 

1-In plaats van en/of aanvullend op lokale settings ? -> Ik ben er voor om locale settings in eerste instantie 'out of scope' te laten, omdat dit e.e.a. extra complex maakt en ook denk ik ook extra specialistisch is... Degene met zo'n opstelling zitten toch er toch op e,e,a, handmatig aan 'vast'.

 

2- Auto/SemiAuto/Handmatig synchroniseren ? -> Ik ben voor automatisch (by opstarten box, box in standby, maar >default< niet bij herstarten box en herstarten E2.

 

3- Plugin/Embedded functionaliteit ? -> Embedded.

Edited by littlesat, 19 February 2018 - 16:34.

[Rob van der Does]

Nee hoor: verkeerd om redenering. Maar niet ongebruikelijk bij ITers......

[littlesat]

Je kunt niet iets specificeren zonder te checken wat je specificeert of het ook mogelijk is...

[WanWizard]

Dat is natuurlijk niet helemaal waar.

 

Functionele specificatie, design en archictuur staat los van uitvoering/implementatie, sterker nog, daarvoor is implementatie helemaal niet relevant.

 

Met andere woorden, als de functionele eis is "ik wil reizen van Amsterdam naar Rotterdam", en zegt dat niets over of dat lopend, op de fiets, met de auto of met het OV moet gebeuren. En andersom, als je niet weet dat je die reis wilt gaan maken, dan heeft het weinig zin om te gaat uitzoeken met welke transportmiddelen dat zou kunnen.

 

Denk dat Rob daarop doelt...

[littlesat]

Maar als nu de reis van Amsterdam naar New York gaat en je specificeerd dat je verplicht bent dat met een auto to doen die niet op een boot of vliegtuig mag...? (LOL)

 

M.a.w. met wat 'mogelijke' code posten hier, specificeer ik niet... ik leg alleen vast dat je met een vliegtuig of boot naar New York kunt gaan. Met een vliegtuig gaat dat in 6 uur en met de boot doe je daar een week of zo over. 

Als je later specificeerd dat je binnen een dag in New York moet zijn, dan valt de boottest af... Maar als je specificeerd dat een vliegticket te duur is dan zal je misschien toch de boot moeten nemen...

Edited by littlesat, 19 February 2018 - 19:17.

[cobus]

Leuk om te lezen dit heerlijk

[Rob van der Does]

Dat is natuurlijk niet helemaal waar.

 

Functionele specificatie, design en archictuur staat los van uitvoering/implementatie, sterker nog, daarvoor is implementatie helemaal niet relevant.

 

Met andere woorden, als de functionele eis is "ik wil reizen van Amsterdam naar Rotterdam", en zegt dat niets over of dat lopend, op de fiets, met de auto of met het OV moet gebeuren. En andersom, als je niet weet dat je die reis wilt gaan maken, dan heeft het weinig zin om te gaat uitzoeken met welke transportmiddelen dat zou kunnen.

 

Denk dat Rob daarop doelt...

 

Precies dat bedoel ik steeds duidelijk te maken.

Eerst precies opschrijven wat je (als gebruiker) verwacht; pas als daarover overeenstemming is bereikt heeft het zin naar operationele zaken te kijken. En dan volgt in de praktijk van de IT-ontwikkeling een fase waarin heen en weer wordt gesproken tussen gebruiker en (systeem-)ontwikkelaar.

 

Voorbeeld van een gebruikelijke situatie:

Gebruiker stelt als eis: ik wil met het vliegtuig van Amsterdam naar Parijs.

Na enig heen en weer praten blijkt de eis niet te zijn 'per vliegtuig' te moeten gaan, maar binnen een bepaalde tijd van huis (en dat huis stond niet op Schiphol, maar in Amsterdam-centrum) naar kantoor te moeten gaan (en dat kantoor stond niet op Charles de Gaulle, maar in noord-Parijs).

Nu is de eis dus ineens heel anders geworden, simpelweg doordat de gebruiker bij het formuleren ervan in eerste instantie al op de stoel van de uitvoerder (het reisbureau) was gaan zitten. In dit geval was de oplossing een TGV-retourtje; goedkoper en sneller. Maar daar kom je pas achter na uitvoerig vaststellen van de eisen (= ondervragen van de gebruiker).

Dit ondervragen vaan de gebruiker is een vak apart; tijdens dat proces krijgt de gebruiker in de praktijk ook pas door wat hij nu eigenlijk wil. Gebruikelijk is dat de gebruiker al heel gedetailleerd bepaalde functionaliteit voor zich ziet (het 'hoe', in dit geval het vliegtuig) terwijl hij nog niet eens precies weet wat hij wil bereiken (in dit geval binnen een bepaald etijd van A naar B reizen).

Na dit vaststellen op hoofdlijnen, volgt meestal een meer gedetailleerde eisenlijst (in dit geval zaken als comfort/stilte/stroomvoorziening/eten/WiFi).

 

In dit ondervragen gaat bij het ontwerpen van een systeem meestal relatief veel tijd zitten; tijd die later ruimschoots wordt terugverdiend doordat de ontwikkelaar veel preciezer weet wat er wordt verwacht en er integraal wordt nagedacht over de som van de eisen. Resultaat is een logisch opgezet, en daardoor goed te onderhouden, systeem, met een intuitieve UI.

 

Voorwaarde bij dit alles is dat de gebruiker niet dezelfde is als de systeemontwerper, en de systeemontwerper weer een ander is dan degene die uiteindelijk gaat coderen.

Littlesat is nu een drie-in-één spel aan het spelen; ondanks alle goede bedoelingen is het vrijwel onmogelijk zoiets tot een goed einde te brengen (hoewel er uiteindelijk ongetwijfeld een werkbare oplossing tevoorschijn resulteert).

 

Ook het idee van 'eerst dit, dan zien we later wel weer verder' (om te verbeteren of extra functionaliteit in te brengen), is niet goed. Alle (voorzienbare) eisen moeten duidelijk zijn, alvorens ook nog maar aan één regel code te denken. Dit voorkomt veel herschrijven, of zelfs dat latere eisen niet meer inpasbaar zijn in het gekozen ontwerp.

[littlesat]

Willen we hier nog weken wachten wat de gebruikers verwachten...?
In ieder geval staat is dat settings ophalen en epg al vast en min of meer willen we het via owif.. door de ‘TEST’ code weten we ook al dat dit technisch kan, dus we kunnen verder specificeren. Had het technisch niet gekunt dan hadden we meteen kunnen ophouden.
Er zit nog niets in e2!.

En soms moet je om complexibieit eruit te halen de scope limiteren, iets maken, en daarna de scope weer uitbreiden... een onderdeel van Wilson Learning... zo zou je userid en wachtwoord van owif eruit kunnen halen om het eenvoudiger te maken in eerste instantie en daarna pas toevoegen.

Edited by littlesat, 20 February 2018 - 08:07.

[doglover]

Mijn wens was:

 

Een methode (plug-in, utility, etc...) om automatisch de bouquetten van de slave te synchroniseren met de master.  Niets meer of minder.

 

Nu is dit natuurlijk het eenvoudigste systeem.  De slave heeft geen eigen tuner (is uitgeschakeld), en kan slechts tunen via de tuners van één welbepaalde receiver.  Ook wenste ik een volledige kopie van de bouquetten.

Vermits niet direct een oplossing voorhanden was, heb ik zelf iets ineengeflansd - een bash script met de hulp van yafc.  Heb dit script in de enigma2_pre_start.sh file gezet en dit doet de job - voor mijn situatie.

 

Natuurlijk besef ik dat er meer bij komt kijken wanneer je dit wilt in bedden in enigma2.

Deze vragen zijn in dit draadje al uitvoerig aan de orde gekomen:  Zoals:

 

* Keuze van de bouquetten moeten gesynced worden.

* Hoe vaak en wanneer wil je syncen.

* Wanneer de slave ook een eigen tuner heeft, mogen bestaande bouquetten overschreven worden, of moeten ze gemerged worden?  Of renamen?

* Wat met lamedb?  Vooral als de slave een eigen tuner heeft die verschillende satellieten aan kan dan de master.  Mergen van lamedb.  Dit is belangrijk omdat anders de namen van de kanalen niet goed overkomen.

* Wil je ook EPG overhalen.  epg.dat?  Dan eerst op de master epg.dat wegschrijven.  File overhalen en inlezen in de slave?  Of is er een andere techniek?

 

Allen vragen die niet spelen in mijn eigen situatie, maar belangrijk kunnen zijn voor anderen.

Ben echter niet goed geplaatst om deze vragen te beantwoorden.

 

Nochtans kan ik littlesat wel volgen.  Hij is eerst aan het uitzoeken wat mogelijk is.  Bij mijn pogingen om iets eenvoudig op te zetten liep ik tegen een aantal methodes aan die niet werkten.

Had nl. eerst geprobeerd om de bouquetten via een mount van de master op de slave te gebruiken.  Dit werkte, maar ik liep aan tegen het feit dat een CIFS mount af en toe faalt.  Een NFS is niet mogelijk op mijn systemen, omdat NFS geen UBIFS kan sharen. 

 

Mag ik hopen dat er enig schot in de zaak komt. 

 

Willy

Edited by doglover, 20 February 2018 - 08:11.

[littlesat]

Kijk daar hebben we wat aan,,,

 

* Keuze van de bouquetten moeten gesynced worden. -> Ik stel voor alles of niets... keuze out of scope op dit moment (kan later misschien)

* Hoe vaak en wanneer wil je syncen. -> Na een opstart box... vraag is of we dit ook na een herstart van E2 of herstart box willen doen wel of niet via een config. Box in standby om de x tijd, 

* Wanneer de slave ook een eigen tuner heeft, mogen bestaande bouquetten overschreven worden, of moeten ze gemerged worden?  Of renamen? -> Mengen of zo out of scope... gewoon een op een overzetten (kan later misschien)

* Wat met lamedb?  Vooral als de slave een eigen tuner heeft die verschillende satellieten aan kan dan de master.  Mergen van lamedb.  Dit is belangrijk omdat anders de namen van de kanalen niet goed overkomen. -> Zie vorige punt....

* Wil je ook EPG overhalen.  epg.dat?  Dan eerst op de master epg.dat wegschrijven.  File overhalen en inlezen in de slave?  Of is er een andere techniek? -> EPG overhalen kan... op dezelfde manier als de plugin door de epg.dat file op de server te forceren en op te halen. Het via een api overhalen kan eventueel later nog (scope stellen!!! als je alles meteen wilt maakt het te complex). We kunnen ook beslissen in eerste instantie de hele EPG niet te doen (out of scope).

 

Nog iets...

WIllen we een notify box als de settings worden opgehaald met een status (progress barr,, percentage, de file die momenteel wordt opgehaald en/of fase)?

Willen we het ook handmatig kunnen starten> Zo ja in welk menu?

Willen we meteen de mogelijkheid aanbieden een userid en wachtwoord voor het webif in te kunnen vullen? (of out of scope voor nu)...

Edited by littlesat, 20 February 2018 - 08:57.

[doglover]

WIllen we een notify box als de settings worden opgehaald met een status (progress barr,, percentage, de file die momenteel wordt opgehaald en/of fase)?

 

 

Tijdens een automatische update is een progress bar overdreven.  In mijn geval duurt een update minder dan 20 seconden.  Een melding lijkt mij genoeg, en dan niet een melding box op het sherm, maar bv. een melding dat de sync uitgevoerd is in het scherm van de utilty zelf.  Iets zoals nu by AutoBackup.

Eventueel kun je daar wat filenamen voorbij kunnen laten komen, zodat je ziet dat er iets gebeurt.

 

 

Willen we het ook handmatig kunnen starten> Zo ja in welk menu?

 

 

Handmatig zou moeten kunnen denk ik.  Kan mij voorstellen, dat er situaties zijn, waarin je zegt, ik wil nu een sync.

Welk Menu:  Hetzelfde menu waar nu the remote Channels convertor opduikt.

(Ik denk dat dit is:  Instellingen - Zenders zoeken)

 

 

Willen we meteen de mogelijkheid aanbieden een userid en wachtwoord voor het webif in te kunnen vullen? (of out of scope voor nu)...

 

 

Als er ergens userid en wachtwoorden nodig zijn, dan vind ik dat je een plaats moet aanbieden om die in te vullen.  Niet iedereen is zo handig om die ergens in een setting lijst te gaan invullen.

 

Willy

Edited by doglover, 20 February 2018 - 09:22.

[doglover]

Wat betreft de methode:  FTP of owif

 

Hierbij wil ik ter overweging zeggen dat als je dit wil inbedden in enigma2, en je kiest voor owif dat je dan afhankelijk bent van een plug-in om iets te laten werken binnen enigma2.

Ik ben van oordeel dat dit niet zou mogen.

 

Willy

[Rob van der Does]

Willen we hier nog weken wachten wat de gebruikers verwachten...?

Jammer dat je van mijn uitgebreide betoog geen woord begrepen hebt: snel = zeker niet meteen code programmeren.

Ik geef het op en zie wel wat er uit de bus komt.