Posts by ritzMo

    Quote

    Originally posted by Nierotter
    War aber nur 34MB groß, also wurde der Prozess wohl irgendwie abgebrochen.


    Es wird gespeichert was Backup/Restore aus dem SoftwareManager auch speichert oder falls das nicht gefunden wird die darin genutzten Standardpfade: /etc/enigma2/, /etc/network/interfaces, /etc/wpa_supplicant.conf, /etc/wpa_supplicant.ath0.conf, /etc/wpa_supplicant.wlan0.conf, /etc/resolv.conf, /etc/default_gw, /etc/hostname


    Also nicht das gesamte Image, sowas war zwar auch mal geplant wurde aber aus verschiedenen Gründen zurückgestellt.


    Quote

    Originally posted by Nierotter
    Muss die App laufen bis alles fertig ist, und kommt dann ne msg auf dem iDevice das alles fertig ist ?


    Hab das ehrlich gesagt lange nicht auf einer echten Box genutzt, der Code legt jedoch nahe, dass ein während dem download ein Overlay aktiv ist mit dem eigentlich recht klaren Text (aus dem englischen) "Retrieving Backup" ;)

    Quote

    Originally posted by Nierotter
    Hmmm, ich habe das tar eben im TMP Verzeichnis der Box gefunden.......


    Ehm, ja - das hab ich vom ur-Backup im webbouqueteditor abgeschaut, es wird lokal immer die gleiche Datei in /tmp erstellt, gelöscht aber nicht da sie über eine andere API abgerufen werden muss ;)
    Ist ja mit dem nächsten Reboot weg xD


    Quote

    Originally posted by Nierotter
    Wo denn im iDevice ? Document Ordner ist mir da noch nirgends aufgefallen... mal suchen...


    Jede App hat ihren eigenen Dokumente-Ordner der den Datenaustausch via iTunes erlaubt, den ohne iTunes zu finden macht keinen Spass da die Apps alle eine gerätespezifische UUID haben.

    Quote

    Originally posted by Nierotter
    Wo wird das denn bei der 7080 gespeichert wenn ich per App ein Gesamtes System Backup mache ?


    Auf dem iDevice - auf dem Receiver macht ja nur bedingt Sinn.
    Liegt im Dokumente-Ordner und ist via iTunes kopierbar sofern man möchte.



    Mostly unrelated: Da ich den Screenshot noch auf meinem Desktop hatte, im Anhang ein Ausblick auf die primäre Änderung für 1.7.0 ;)


    *EDIT* Screenshot entfernt da das Update im Laufe des Tages verfügbar sein sollte :)

    Quote

    Originally posted by betonme
    Was hältst du davon?


    Das dürfte mit unverändertem AutoTimer nicht laufen.
    Die Version auf schwerkraft gibt ints zurück und len(int(9)) wirft ebenfalls eine Exception.


    Ich kenne die andere API nicht und kann mich daher dazu nur sehr bedingt äussern.
    Ich würde aber empfehlen die EPGRefresh-Version auf schwerkraft mit dem AutoTimer auf schwerkraft kompatibel zu halten.

    Quote

    Originally posted by crazydogs
    Ja, muss unbedingt mal das System neu aufsetzen.


    Also die AutoTimer-Version aus deinen Logs gibt es meines Wissens nach nicht. Und zumindest so grob sollte ich es wissen :)
    Ich denke du hast irgendwann nach dem letzten Update eine andere AutoTimer.py eingespielt.
    Die installierte entspricht nicht der aus Revision 1e01905 und stürzt irgendwo in dem nicht vorhandenen Code ab.


    Zumindest die Standardfunktionalität sollte durch reinstallation des Plugins wieder gegeben sein, wobei betonme Recht hat und dort diverse andere Fehler im Log auftauchen.


    Quote

    Originally posted by betonme
    werde ich bei nächster Gelegenheit einpflegen.


    Habs mal gepusht.

    Quote

    Originally posted by Microdevil
    Andererseits könnten mir die netten Entwickler von Autotimer ja auch mal ein Beispiel für die WebIf API geben, damit ich damit experimentieren kann.


    Soweit ich deinen Ansatz verstehe brauchst du nur die Parameter id und !shortdescription[].


    Beispiel:

    Code
    http://localhost/autotimer/edit?id=1&!shortdescription[]=Kuchen&!shortdescription[]=Backen&!shortdescription[]=macht&!shortdescription[]=Spass


    Der Aufruf ändert den Timer mit der Id 1 (siehe dafür http://localhost/autotimer, die kannst du zwar theoretisch auch aus der xml im Dateisystem generieren aber das Thema lassen wir mal), so dass er 4 excludes für die Shortdescription hat: Kuchen, Backen, macht, Spass
    Alle anderen Einstellungen sollten erhalten bleiben, auch wenn ich grade zwei mögliche Probleme bei name & match gefunden hab - also sicherheitshalber diese eventuell auch mitsenden.

    Quote

    Original von chrisly
    Es würde also reichen, das Endedatum ("Aufnehmen nicht nach ..." ) leer lassen zu können.


    Ich hab grad keinen angeschlossenen Receiver in Reichweite, kannst du mal die AutoTimerComponent.py aus dem Anhang probieren.
    Die führt eine Verhaltensänderung ein, so dass gleiches Start-&Enddatum als open-ended interpretiert wird.
    Wieso Start = Ende? Ist ein schnell zu erreichender brauchbarer Wert. Ende < Start deutet eher aus ein Missverständnis hin und ist mir als Definition zu grob.

    Quote

    Originally posted by Microdevil
    - Autotimer.xml direkt bearbeitet, "parse?" aufgerufen und voilà! veränderte Ausgabe.


    parse startet die Suche im EPG, wenn das ist was du willst kannst du das so nutzen. Ansonsten würde ich evt. einfach http://127.0.0.1/autotimer nehmen - das gibt dir nur das xml zurück.
    Als Vorwarnung bevor du die Rückgabe vergleichen möchtest: das Format is minimal anders um die Verarbeitung durch Clients zu vereinfachen.

    Quote

    Originally posted by Microdevil
    [...] http://BOXIP/autotimer/parse?_=1429194621765 gestossen (was auch immer die Zahl ist).


    Wäre es nur "1429194621" würd ich sagen der Unix-Timestamp vom Zeitpunkt deines Aufrufs (auch wenn das 3:30 CET heute ist, weiss ja nicht wann "jetzt" ist :)).
    Kurzum: keine Ahnung, vermutlich automatisch hinzugefügt um Caching des Browsers zu umgehen.


    Quote

    Originally posted by Microdevil
    da ich zum Test die xml umbenannt habe.


    Du hast die Datei einfach umbenannt oder eine gültige config an die Stelle geschrieben?
    Wenn keine Config da ist denkt das Plugin "warum neu einlesen?" und macht einfach weiter :)


    Quote

    Originally posted by Microdevil
    Gibt es auch einen Befehl um autotimer.xml neu einzulesen?


    Ne, da das bei den meisten API-Aufrufen automatisch passiert und ein Reload ohne Grund braucht nicht unbedingt eine API, da es wie gesagt idR überflüssig ist.


    Nicht passiert es aktuell nur bei löschen/editieren(/hinzufügen) und plugin-config APIs, bin mir aktuell nicht sicher ob das bei den ersten zwei sinnvoll ist da sich zumindest beim löschen die Id ändern könnte - ich denke hier griff die Logik: lieber den richtigen nicht gelöscht als den falschen :)
    Aber das ist ein anderes Thema…

    Ich weiss auch nicht so genau was betonme hier erzählt.
    Beim Beenden wird vorm Speichern geguckt ob das xml neuer ist als die zuletzt gelesenen Daten, wenn ja wird neu gelesen (was das Speichern überflüssig macht, aber das ist ein anderes Thema).


    Afaik nutzt jeder Pseudo-Fork noch meine entsprechende Logik von damals, sollte also überall so funktionieren.

    Quote

    Originally posted by DeMaddin
    Ok, ich muss dazu sagen, dass ich OE 2.0 drauf hab. Das kann Ordner (oder sind es doch Lesezeichen?) lesen.
    Werden als rote Kästchen vor der Aufnahme angezeigt. Ich denke, du weißt was ich meine... ;)


    Am einfachsten gehst du ins WebInterface. Wenn da etwas angezeigt wird sollte es in der App auch zu sehen sein ;)


    Afair sind einige von den Bookmarks genervt und nutzen daher alternative Aufnahmelisten die Bookmarks ignorieren und den Nutzer einfach durch die Ordner navigieren lassen.




    Und die Lesezeichen/Ordnerproblematik geht viel weiter zurück als OE 2.0/2.2, mein git sagt dazu folgendes:

    Code
    commit ba4c219da50c06c732ea9899d2b4e3679066aecc
    Author: Felix Domke <tmbinc@elitedvb.net>
    Date: Wed Feb 20 00:36:00 2008 +0000
    timer_select.patch by Moritz Venn, with minor fixes


    einige Monate später kam dann basierend auf einem Patch von ralfK und mehreren Diskussionen in Forum/Mailinglist/Privater Inbox support für Bookmarks ins (ich glaube das war mal) CVS.


    So rekonstruiere ich das jedenfalls aus den hier vorliegenden Daten :)

    Quote

    Originally posted by DeMaddin
    Kann es sein, dass dreamote keine Ordner beim Movie-Ordner anzeigen kann?
    An der Box selbst ist es kein Problem.


    Auf der Box selbst ist es durchaus ein Problem, denn zumindest meine können im Auslieferungszustand auch keine Ordner anzeigen - nur Lesezeichen (ich sollte es Wissen, an einem Teil des Monsters bin ich ja Schuld :)).
    Lesezeichen sind in der App kein Problem, Ordner werden von beiden standardmäßig ignoriert (bzw. sie werden auf dem Receiver ignoriert und somit erfährt die App nie was von den Ordnern).

    Quote

    Originally posted by Schnello
    Hallo.


    Hat noch wer Probleme mit der aktuellen Version das wenn man im Webinterface den "parse" button drückt das die Box crasht?


    Kannst du mal die AutoTimerResource.py aus dem Anhang nehmen?

    Quote

    Originally posted by DeMaddin
    Nee, leider nicht - nach 60 sek. immer Zeitüberschreitung ;(


    Btw:


    Meintest du das aktuelle Autotimer-Plugin oder ein Plugin in dreamote?


    Aktuelles AutoTimer-Plugin.
    Neuer als 11.2.2015, genauer gesagt mit diesem Commit.


    Eigentlich schickt er dann alle 50s ein paar Daten damit kein Timeout erreicht wird.
    Hier hat er das auch brav gemacht, allerdings nur die Ausgabe geprüft da mein AutoTimer einfach nicht so lang läuft und ich nicht aus dem Kopf wusste, wie ich sauber in E2 die Ausführung verzögern würde ;)

    Quote

    Originally posted by DeMaddin
    Wieso fummelt Apple an euren Apps herum? :rolleyes:


    Tun sie nur bedingt - ich bin allerdings von "selbst verwaltet" auf "Apple verwaltet" gewechselt was den Timeout angeht. Zum einen wusste ich nicht, dass der dann fest auf 60s steht, zum anderen kannte ich die neue API auf die ich gewechselt nur bedingt. Hatte also keine Ahnung wie ich einen eigenen Timeout hätte setzen können.


    Quote

    Originally posted by DeMaddin
    Unschön, wenn es eine Einstellung für Timeouts gibt?


    Nein: wie geschrieben unschön, dass das Plugin einen derart hohen Timeout benötigt.
    Mit o.g. Commit sollte das übrigens erstmal wieder gehen. Fun-Fact: Mit Timeouts < ~50s gibts das Problem weiterhin, wollte aber die Verbindung nicht zu viel spammen ;)

    Quote

    Originally posted by DeMaddin
    Könntest du wieder die Einstellung für Timeout einpflegen?
    60sek. reichen in meinem Fall nicht, wenn Autotimer den EPG intensiv durchsucht. (Bekomme immer Timeoutfehler)


    Eine Einstellung bis 120sek. wäre gut.


    Meh, timeouts - anderseits scheint Apple auch nur einen von 60s hardcoded zu haben… dachte die machen da was besseres ;)


    Ist im nächsten Update wieder drin (auch die Änderungen nicht mehr live greifen sondern erst bei der nächsten Verbindung). Aber eigentlich ist das auf Plugin-Seite unschön und ich wollte das immer mal ändern. Besser erstmal so als gar nicht :)


    *EDIT* Hab doch mal was fürs Plugin gebastelt… Irgendjemand da der den Commit in 4.2 testen möchte? Oder einem aktuellen 4.0 - hatte grad nur 20130114 zur Hand ;)