nachdem meine letzten Änderungen am ParentalControl ja ins Experimental (und seit 2.8 auch ins Image) eingeflossen sind, habe ich mich jetzt mal wieder drangesetzt und die nächsten Feature- Requests in Angriff genommen.

Wie beim letzten Mal muss manuell installiert werden....
Das ganze sieht noch nicht schön aus, sollte aber zumindest schon mal funktionieren...

Installation:

Einfach die Dateien aus der ZIP an folgende Stellen kopieren, Originale vorher sichern nicht vergessen:

ParentalControl.py, ParentalControlList.py --> /usr/lib/enigma2/python/Components
ParentalControlSetup.py --> /usr/lib/enigma2/python/Screens
*.png --> /usr/share/enigma2/skin_default

und anschliessend die Box neu starten.

Features

SEIT LETZTEM PATCH:
- In der Konfiguration können nun auch Files / Directories per PIN geschützt werden. Directories können zwar noch gebrowst werden, aber die Files darin werden nicht abgespielt.
- Tastenbelegung erweitert:
- OK toggelt zwischen Locked / Unlocked für Servicec, Bouquets und files. Wechselt das Verzeichnis, wenn auf einem Directory verwendet
- GRÜN: Setzt den Lock für Service, Bouquet, Files und Directories
- ROT: Entfernt den Lock für Service, Bouquet, Files und Directories

LETZTER PATCH (jetzt offizielles CVS)
- Konfigurierbare Cache- Zeit für PIN- Eingaben: Der eingegebene PIN gilt: 5min, 30min, 60min, bis zum nächsten Standby / Restart
- Konfigurierbare Cache- Zeit für den Abbruch der PIN- Eingaben: Der eingegebene PIN gilt: 5min, 30min, 60min, bis zum nächsten Standby / Restart (Die Box merkt sich also, wenn man die PIN- Eingabe abgebrochen hat und fragt nicht erneut)
- Möglichkeit, ganze Bouquets in die Blacklist / Whitelist aufzunehmen.
- Andere Grafische Darstellung zur Erkennung ob Blacklists verwendet werden (oranges geschlossenes Schloss bei den gesperrten Services) oder whitelists (grünes geöffnetes Schloss bei den freigegebenen Services)
- Rotes B im Symbol, wenn die Einstellung aus einem Bouquet kommt.

Bekannte Einschränkungen
- Wird Beim Umschalten auf einen gesperrten Service keine PIN eingegeben, dann bleibt die Infobar auf dem letzten "Freien" Service stehen... Das ist besonders in Verbindung mit dem "Cancel- Cash" nervig, wenn man über mehrere gesperrte Services "wegzappt", weil sich die Infobar erst wieder ändert, wenn man auf einen "freien" Service wechselt.
- Eine Änderung am Bouquet nach Hinzufügen zu einer Black-/Whitelist wird erst nach dem nächsten Standby / Neustart erkannt, oder wenn man im Jugendschutz- Menu auf "Reload Black-/WhiteLists geht".

Wieder ein Schritt zum kompletten Feature. Viel Spass jetzt beim Testen.

Gruss
Tode

ORIGINAL- POST:
Ich habe ein paar Feature- Requests für das parental control, denn die momentane Implementation ist IMHO so, dass man das nicht wirklich aktivieren kann...

Zunächst mal: Was gefällt mir nicht am aktuellen parental control ?

1. Wird die Sender- Beschränkung aktiviert, und das macht ja nur Sinn, wenn ich sehr viele Sender sperre (oder umgekehrt nur wenige öffne), dann muss ich bei jedem Zappen die PIN eingeben.
Das macht eine "normale" Benutzung der Box quasi unmöglich.

Verbesserungsvorschlag: Man merkt sich die Pin für die Dauer einer session (ala session-Cookie) oder alternativ für eine maximale Zeitspanne von x Stunden (ich würde beides implementieren).
Eine Session definiert sich dabei als die Zeitspanne von einem "Frontend- Start" bis zum "Frontend- Shutdown", das kann entweder das Aufwachen aus dem / versetzen in den (Deep)Standby sein, oder ein Enigma2- Neustart

2. Die Sender- Beschränkungen müssen mühsam zusätzlich zu ggf. bereits vorhandenen Bouquets erfasst / eingestellt werden. Das ist doppelter Pflegeaufwand, die Verwendung von Bouquets ist (momentan) gar nicht möglich.

Verbesserungsvorschlag: Die Sperren können statt auf Sender- Ebene auf Bouquet- Ebene vorgenommen werden. Sie werden dann wirksam, sobald man Sender von einem Bouquet ins andere verschiebt.

3. Um "Normal" fernzusehen muss ich momentan das Parental Control ausschalten (wegen oben genannter Gründe). Das bedeutet: Ich vergesse womöglich es danach wieder zu aktivieren, am nächsten Tag ist das also wieder aufgehoben.

Verbesserungsvorschlag: Siehe oben: Session- basierte Aufhebung der Parental Control (einmalige Pin- Eingabe), so dass dann das "normale" Fernsehen nicht mehr einegschränkt ist

Zusammen mit diesen "Verbesserungs- Vorschlägen", habe ich noch ein paar zusätzliche Features, die ich gerne im Parental- Control hätte:

1. Unterscheidung "Gesperrter Modus" <-> "Freier Modus"
- Gesperrte Sender / Bouquets nicht nur per PIN schützen, sondern im "Gesperrten Modus" komplett ausblenden, und zwar in allen Menus (Timer setzen, umschalten, Boquet- Wechsel, etc.)

2. Erweiterung der Sperre auf Aufnahmen: Aufnahmen (und oder ganze Ordner, analog zu den Bouquets) können mit einem Sperrflag versehen werden.
Auch hier wieder: Im Gesperrten Modus werden diese nicht angezeigt...

3. Erweiterung der Sperre auf relevante Menus
Momentan ist nur das Parental Control Menu geschützt, im Kindersicherungs- Modus sollten aber auch z.B. Plugin- Installationen untersagt sein, etc...
(optional): Einführen einer Sperrflags für Plugins

4. (optional, auch wenn es ziemlich cool wäre): Eine kleine "Benutzerverwaltung" für den Gesperrten Modus: User / Pin- Abfrage beim starten einer "session":
Jedem User sind die Punkte 1 - 3 individuell zuzuordnen.

Man hätte dann beim Box- Start mit aktiviertem Parental- control eine DialogBox:
1. Freier Modus
2. Hans-Peter
3. Kunigunde
4. Hagen

für den freien Modus und ggf. den ein oder anderen Benutzer muss man eine PIN eingeben, es könnte aber auch einen "Default- Benutzer" geben, der keine PIN- Eingabe erfordert und dann halt minimale Berechtigungen hat...
Nach Auswahl des Benutzers wird entweder der zuletzt gesehene Service gestartet (wenn für diesen Benutzer freigegeben), oder eben der erste Service aus dem ersten für den Benutzer freigegebenen Bouquet

Und ganz zum Schluss könnte man dann noch meinen KiddyTimer integrieren und so pro Benutzer die täglichen Fernseh- Zeiten beschränken...

Das wären meine Feature- Requests.

Wenn sich der ein oder andere Mitstreiter findet, wäre ich auch gerne bereit, das ganze selbst in Angriff zu nehmen (für einen Hobby- Programmierer alleine ist das -denke ich- eine zu grosse Geschichte).
Ich würde das auch als Plugin umsetzen, aber ich denke, viele der Dinge müssen direkt im Enigma2 implementiert werden, um effizient zu funktionieren.

Ich freue mich auf Kommentare.
Tode

Tja... wie gesagt: Alleine wird das sehr schwer.... Ich habe zum Beispiel schon Probleme, den Einstiegspunkt zu finden:
Wo wird dafür gesorgt, dass beim Zappen auf einen protected Service der PIN- Input gezeigt wird ?

Ich habe schon Infobar.py sowie InfoBarGenerics.py gesucht ausserdem die ChannelSelection.py... Ich habe alle Sources nach PinInput durchsucht...

Natürlich habe ich die ParentalControlSetup.py gefunden, aber das ist ja auch nur das Setup, nicht der Einstieg...

Ich finde den Einstiegspunkt nicht

Um zu wissen, wo ich einsteigen kann, fehlt mir einfach zu sehr der generelle Überblick.

Und deshalb bin ich mir sicher, dass das ganze ne Nummer zu gross für mich alleine ist.
Ich code gerne Funktionen, wenn mir jemand sagt, wir brauchen in der py diese Funktion.
Aber selbst / alleine steige ich da einfach nicht durch.

Wer kann helfen ?

Gruss
Tode

ritzMo: Vielen Dank für dieses "Codelesen für Dummies". Ich muss gestehen, dass ich bis "zap" schon gekommen war, und auch die Zeile self.session.nav.playService war mir ins Auge gefallen, aber irgendwie hatte ich dann von playService auf iService geschlossen und das kommt ja aus Enigma, ist also C-Code, weshalb ich an der Stelle die Lust verloren hatte...

Im Klartext heisst das: Ich habe in der richtigen py mit der Suche angefangen, nämlich in der ParentalControl, bin dann immer weiter vom Weg abgekommen, nur um am Ende wieder da zu landen...

Wenn ich mir das nämlich richtig anschaue, dann muss ich nicht zig Python- Files patchen, sondern vielleicht 2 oder 3 (auf jeden Fall ParentalControl und ParentalControlSetup), um zumindest mal die -für mich momentan wichtigsten- zwei Punkte zu implementieren:

1. Sperren von ganzen Bouquets
2. Cachen der PIN bis zum nächsten sessionstart... (wobei das wird ziemlich tricky, weil ich da entweder einen eigenen Timer bauen muss, um zu überprüfen: Bin ich schon im Standby und da dann die credentials zu löschen, oder aber ich muss mich an ein event anhängen, das schon existiert, und da dann rumfuhrwerken).
Am coolsten wäre es natürlich, wenn die session eine art sessionID hätte (muss ich prüfen, oder weiss das jemand zufällig), die sich beim booten und auch beim Standby ändert.... Dann könnte ich mir die sessionID merken, und wenn die sich ändert, dann den PIN abfragen...

Vielen Dank erst mal, damit komme ich weiter...

Tode

Frage an die DMM- Entwickler:

Sowohl in der ParentalControl als auch in der ParentalControlSetup findet man "Artefakte", die darauf hinweisen, dass jemand das mit dem Service- Pin- Speichern schon mal angefangen hat.

Beispiel ParentalControlSetup, Zeile 77:
#self.list.append(getConfigListEntry(_("Remember service pin"), config.ParentalControl.storeservicepin))

Beispiel ParentalControl, Zeile 13:
config.ParentalControl.storeservicepin = ConfigSelection(default = "never", choices = [("never", _("never")), ("5_minutes", _("5 minutes")), ("30_minutes", _("30 minutes")), ("60_minutes", _("60 minutes")), ("restart", _("until restart"))])

Wurde das aus Mangel an Zeit nicht fertig gemacht, oder weil Ihr da auf Probleme gestossen seid, die Ihr nicht lösen konntet ? Würde mich nur interessieren, nicht dass ich hier was anfange, was Ihr schon -weil unmöglich- verworfen habt... ?

Und irgendwas war wohl auch mal mit einem "ServiceLevel" angefangen... Aber was das sollte, da bin ich noch nicht dahinter gekommen. Kann da noch wer ein / zwei Sätze zu sagen ?

Thanx
Tode

ritzMo: das mit dem Intervall ist wirklich relativ easy, so weit war ich auch schon... Deshalb wundert es mich, dass das hier zwar angefangen wurde, aber eben nicht zu Ende gemacht...
Das heisst für mich aber im Umkehrschluss, dass die Option ("restart", _("until restart")) Probleme gemacht haben muss, sonst wäre dieses Komfort- Feature doch wirklich schon lange aktiviert.

Zumal es wirklich nur wenige Zeilen code sind:
Beim Pin- Input einen Config- Wert auf die aktuelle Zeit setzen und diesen dann beim nächsten "isServicePlayable" vergleichen, ist wirklich kein Act...

Insofern werde ich mal mit diesem minimal- invasiven Eingriff starten.
(auch wenn es mir schon wieder davor graust, Zeiten voneinander abzuziehen, und das Ergebnis mit Stunden:Minuten zu vergleichen....)

Tode

wir wollen es ja nicht zu einfach machen... Also einfach nur restart ist kein Problem, aber für mich ist restart auch standby.

Aber das kommt dann nachher...

Gruss
Tode

dann wird bei mir der Punkt anders heissen... wenn ich nach einer PIN- Eingabe erst die ganze Box neustarten muss, um den zu "vergessen", dann ist das für mich nicht praktikabel.

Der Standard- 08/15- Benutzer erwartet sicher nicht, dass in so einem Fall zwischen Standby und Neustart unterschieden wird...

Ich werde also den Punkt entsprechend umbenennen...

Tode

OK... die Entwicklung hat begonnen...

Heute hat DMM zwei config- Variablen hinzugefügt, und dafür die mytest.py und die Standby.py geändert.

config.misc.startCounter
config.misc.standbyCounter

Mit der Standby.py und mytest.py von heute können meine Änderungen getestet werden, die ich hier anhänge.

Erster Schritt: Im ParentalControlSetup kann man einstellen, für wie lange die ServicePin gecached wird:

Mögliche Werte: Nie, 5 Minuten, 30 Minuten, 60 Minuten, until Standby/Restart

Das nimmt schon mal viel Schmerz...

Wer Lust hat kann das testen.

Die Dateien gehören hierhin:

mytest.py --> /usr/lib/enigma2/python
Standby.py, ParentalControlSetup.py --> /usr/lib/enigma2/python/Screens
ParentalControl.py --> /usr/lib/enigma2/python/Components

und für Images älter als 2009-08-04 noch:
Screen.py --> /usr/lib/enigma2/python/Screens

Achtung: Das austauschen von einzelnen Dateien kann zu unvorhersehbaren Ereignissen führen, wenn das Image selbst zu alt ist. Ihr solltet Euch also vorher Sicherungen machen und auf jedenfall schon mal ne Telnet- Session bereit halten für ein init 4 (um die Sicherungskopien zurückzusichern)

Also bitte nur testen, wenn Ihr wisst, was Ihr tut...

Die Änderungen selbst habe ich natürlich schon -so gut möglich- getestet und sollten stabil sein.

Viel Spass
Tode

10 Downloads bis jetzt und noch kein Kommentar... Als hauptberuflicher Software- Entwickler werte ich das mal als "ist OK", denn wenn irgendwas nicht geht bekommt man immer sofort Feedback
Dann werde ich mich heute Abend mal an Schritt 2 meiner Entwicklung machen und versuchen, den Schutz auf Bouquets auszuweiten.

Auch hier wieder ne kurze Frage an die erfahrenen Entwickler (sonst muss ich wieder so viel Quellcode quälen):

Ich habe die "servicelist" in der Infobargenerics als Möglichkeit identifiziert, ans aktuelle Bouquet zu kommen... Ist das richtig ?
Und wenn ja: wie kriege ich ne servicelist ? (eServiceCenter.getInstance().list(bouquet) habe ich gefunden, aber ich weiss ja das bouquet gar nicht....

Gruss
Tode

Danke für's Feedback: Python ist einfach nicht meine Sprache....

Dann werde ich erst mal den Code nach Deinen Tipps optimieren, bevor ich an weitere Dinge gehe...

Lass mich das zusammenfassen:
- Nicht config- Werte nehmen um die letzten Werte zu speichern, sondern einfache integer..
Frage: Es wird also nicht bei jedem Zugriff auf isServicePlayable eine neue Instanz der Klasse ParentalControl erzeugt ?

- Session- Key: Das hatte ich deshalb gemacht, weil es keinen Hook gibt, um sich an den Standby anzuhängen.. ich müsste also einen Timer laufen lassen, um Standby.inStandby zu überwachen...
Oder aber: Ich müsste die Standby.py patchen.... Deshalb die Idee, einen Session- Key zu generieren... Damit muss ich nichts monitoren sondern kann beim Zugriff (also on demand) prüfen, ob ein Standby dazwischen war...

- Temporäre variablen an Klasseninstanz binden... äh: hier steh ich auf dem Schlauch... Was meinst Du ?

- Die Speicherung des Wertes: Das habe ich -ohne nachzudenken- übernommen. Aber natürlich hast Du recht: Das direkt so zu speichern, wie ich es später brauche, ist natürlich sinnvoll... da war zu viel Respekt for fremdem Code da... deshalb heisst auch die "restart" - Variante nicht standby... ich wollte nicht einfach die Werte ändern (auch wenn das noch nicht verwendet wurde).

Danke für Deine Anregungen: Ich hatte mich ja nicht wirklich drum geschlagen, das zu coden (bin zwar seit über 10 Jahren Entwickler, aber in Python noch grün hinter den Ohren.. ich verstehe noch zu wenig die Zusammenhänge...)...

Auf an die Arbeit...

Tode

nur eine Instanz:

kannst Du mir sagen, woran ich das erkenne !? (wenn ich Dich nerve, sags einfach, aber ich will ja, dass mein Code irgendwann release- fähig wird, und nicht dass die Devs von DMM alles neu schreiben müssen, denn wenn Sie Zeit für diesen Firlefanz hätten, hätten Sie das ja schon lange umgesetzt (ist ja wirklich ziemlich wenig code)

Nur zu Deiner Info (aber ich denke Du hast das ganze verfolgt): Denn Standby- Counter hat Ghost ja extra für mich geschrieben... Dass ich den jetzt als counter nutze und mich nicht einfach per Callback an die Variable hänge ist natürlich mein Fehler...

Da muss ich dann halt meine Logik überdenken: Dann merke ich mir nicht nen Session- Key, sondern ein "hasToRun"- Flag, das ich beim callback (durch config- änderung) zurücksetze... dann spare ich mir die Abfrage jedesmal...

Danke nochmal für Deine Hilfe...

Tode