Hi ,
Hast du die scripts unter /usr/local/bin/fskprotect.sh und cut.sh aus dem PLUGINS/src/pin kopiert ??
Gruss Pat
Hi ,
Hast du die scripts unter /usr/local/bin/fskprotect.sh und cut.sh aus dem PLUGINS/src/pin kopiert ??
Gruss Pat
ZitatAlles anzeigenOriginal von dingo
Hallo,
Danke für die gute Plugin!! Entschuldigung für mein Deutsch, aber ich bin kein "nativ speaker".
Ich habe pin-0.1.7 installiert an vdr-1.4.5, und alles geht gut, aber ich hab ein Problem:
Wenn ich childlock activiere, kann ich ein Timer starten an einem geblocktes Kanal; ich kann "childlock" auf ja oder nein setzten an der Timer (default ist nein), und die Aufnahme kan man auch normalerweise anschauen.
Dies ist unabhängig von der autoprotection setting (<intelligent> oder <immer>).
Sind da auch andere Leute mit diesem Problem, ist es ein Bug oder ist es "expected behaviour"?
Danke!
Hi dingo,
nein ich kann dieses Verhalten bei mir nicht nachvollziehen. Gedacht ist es so, wenn in den Timer Einstellungen childlock auf ja steht ist die daraus resultierende Aufnahme anschließend gesperrt. Wenn man einen neuen Timer anlegt ist die default Einstellung des childlock wie du richtig vermutest abhängig von 'autoprotection' in den Settings. Hierbei bedeutet:
- immer: Für jeden neuen Timer wird chlidlock auf yes gesetzt
- intelligent: Für neue Timer auf gesperrte Kanäle oder Sendungen wird chlidlock auf yes gesetzt.
Anschließend kann man diese Voreinstellung natürlich noch in den Timer-Settings ändern (auf 'no' nur sofern der VDR freigeschaltet ist).
horchi
Hallo horchi,
wenn ich also den Pin nicht kenne, kann ich dann einen Timer anlegen, der einen gesperrten Kanal in eine ungesperrte Aufnahme aufzeichnet?
Dann könnte ich damit den Kopierschutz umgehen.
Markus
ZitatAlles anzeigenOriginal von MarkusE
Hallo horchi,
wenn ich also den Pin nicht kenne, kann ich dann einen Timer anlegen, der einen gesperrten Kanal in eine ungesperrte Aufnahme aufzeichnet?
Dann könnte ich damit den Kopierschutz umgehen.
Markus
nee, dafür ist wie oben erläutert, in den Plugin-Settings die Einstellung 'Automatischer Schutz der Aufnahmen' zuständig
Zitat- immer: Für jeden neuen Timer wird chlidlock auf yes gesetzt
- intelligent: Für neue Timer auf gesperrte Kanäle oder Sendungen wird chlidlock auf yes gesetz
Sofern dies funktioniert und nicht wie von dingo gemeldet ein Problem besteht. Ich habe es aber bei mir gerade nochmals nachvollzogen da funzt es einwandfreit.
horchi
ZitatOriginal von horchi
- immer: Für jeden neuen Timer wird chlidlock auf yes gesetzt
- intelligent: Für neue Timer auf gesperrte Kanäle oder Sendungen wird chlidlock auf yes gesetzt.
Ok, hier ist was ich _exact_ gemacht habe:
-vdr-1.4.5 vanilla clean installiert, ohne patches und plugins, allein das s*ftc*m-plugin und das pin plugin mit ihrem patches
-hab cut.sh an noadcall.sh zugefügt -> dies geht gut, ein bearbeiteten gesicherten Aufnahme wird automatisch gesichert
-scripts/*.sh in /usr/local/bin
-Kanal 199 hab ich gesichert, dies arbeitet gut, mit childlock activiert kan mann nicht dieses Kanal wählen
-zum testen hab ich autoprot auf "immer" gesetzt
-ich activiere childlock
-denn mache ich: <menu><3 Timer><Green Neues timer>; ein timer an Kanal 1 erscheint, mit Childlock = Nein (das wäre nicht expected behaviour!). Ich kan nun das Kanal änderen nach 199, presse <menu> und das Timer läuft mit Childlock = Nein.....
Auch wenn ich vdr als root drehe, dasselbe...
Wass hab ich falsch gemacht?
Hi dingo,
du hast völlig Recht, den Effekt kann ich hier nachvollziehen.
Diesen Weg bin ich noch nie gegangen und habe es völlig übersehen. Zum einen habe ich das erstellen eines Timers über <Grün> 'Neuer Timer' noch nie verwendet und zum anderen ist derzeit auch das ändern des aufzuzeichnenden Kanals leider nicht berücksichtigt :schiel.
Danke für den Bugreport, ich versuche, wenn es klappt noch dieses Wochenende, einen Bugfix bereitzustellen.
horchi
Danke für das schnelle Antwort, jetzt kann ich meine Testen anhalten.
Ich hoffe nicht zu viele Väter haben nach anschauen ihren syslogs ein Problem mit ihre Kinder....
Bis schnell! Dingo.
P.S.: Ich glaube da ist noch ein anderes Problem in dieselbe Richtung:
1) Childprotection aktiviert
2) <menu> <1 epg> <grün what's on now> : scroll zu ein protected
Kanal, und mach <rot: aufnehmen>
Ein timer wird gemacht, mit childprot=ja, aber nach eine Secunden ist den Timer verschwunden, und da ist auch kein Aufnahme da...
Hi,
ich habe erst einmal eine schnelle Lösung eingebaut, damit kann man ohne vorher den Pin Schutz freizuschalten den Kanal der Timer nicht mehr verändern.
So kann jeder User Timer für gesperrte und nicht gesperrte Kanäle anlegen wobei die Aufnahmen der gesperrten Kanäle (bei entsprechenden Plugin Einstellungen) auch gesperrt werden. Da man nun den Kanal (ohne freischalten) nicht mehr verändern kann ist die Sicherung so nicht mehr zu umgehen. Das sollte auch keine problematische Einschränkung sein, da man via des EPG auch ohne den Code Timer für jeden beliebigen Kanal erstellen kann.
Wie seht ihr das?
Ich werde die Änderung in der nächsten Version des Plugins berücksichtigen.
Hier vorab die Änderung zum manuellen einbauen, in der Datei menu.c des vdr die Zeile mit dem '+' hinzufügen, alles neu übersetzten und installieren.
cMenuEditTimer::cMenuEditTimer(cTimer *Timer, bool New)
:cOsdMenu(tr("Edit timer"), 12)
{
firstday = NULL;
timer = Timer;
addIfConfirmed = New;
if (timer) {
data = *timer;
if (New)
data.SetFlags(tfActive);
channel = data.Channel()->Number();
Add(new cMenuEditBitItem( tr("Active"), &data.flags, tfActive));
+ if (cOsd::pinValid)
Add(new cMenuEditChanItem(tr("Channel"), &channel));
Add(new cMenuEditDateItem(tr("Day"), &data.day, &data.weekdays));
Add(new cMenuEditTimeItem(tr("Start"), &data.start));
Add(new cMenuEditTimeItem(tr("Stop"), &data.stop));
Alles anzeigen
Nun zu den anderen beiden gemeldeten Punkten.
1. 'Immer' in den Plugin Einstellungen hat in der Tat keinen Einfluss auf Timer welche man mit <grün> im Timer Menü erstellt. Das ist ein Bug, hierfür werde ich auch auch bald ein Fix bereit stellen. Dies sollte mit obiger Änderung jedoch kein Risiko mehr sein.
2.
Zitatin timer wird gemacht, mit childprot=ja, aber nach eine Secunden ist den Timer verschwunden, und da ist auch kein Aufnahme da.
Das kann ich hier nicht nachvollziehen, habe es auf verschiedene arten Versucht, mit und ohne epgsearch-Plugin, etc.
Grüße
horchi
Danke für das schnelle Antwort!
ZitatOriginal von horchi
2.
Das kann ich hier nicht nachvollziehen, habe es auf verschiedene arten Versucht, mit und ohne epgsearch-Plugin, etc.
Grüße
horchi
Kann es auch nicht mehr reproduzieren, nicht in Test-Umgebung weder in Production, so Entschuldigung für diese falsche Meldung.
Danke für die Patch!
Grüsse, Dingo.
mal ne frage zu der abwärtskompatiebilität deines beigelegten patches (vdr-1.4.5.diff)
Im Bigpatch zum VDR-1.4.6 ist noch eine alte Version deines patches aus früheren pinplugin Versionen integriert.
Wenn ich jetzt vdr-pin-0.1.7 damit zum laufen bringen will, wird das gehen oder fehlt mir dann grundsätzlich etwas am Functionsumfang?
Wie siehts andersherum aus, neuer Patch mit älterer pin plugin Versionen? wird das gehen?
Wir haben hier unter Gentoo noch die vdr-pin-0.0.20 am laufen,
*hmm, irgendwie den anschluss verpasst ...*
Du kannst mir das schneller aus dem Stehgreif beantworten eh ich hier erst grossartig Versuche starte.
Cheers
/bin/joerg
ZitatAlles anzeigenOriginal von hd.brummy
horchi
mal ne frage zu der abwärtskompatiebilität deines beigelegten patches (vdr-1.4.5.diff)
Im Bigpatch zum VDR-1.4.6 ist noch eine alte Version deines patches aus früheren pinplugin Versionen integriert.
Wenn ich jetzt vdr-pin-0.1.7 damit zum laufen bringen will, wird das gehen oder fehlt mir dann grundsätzlich etwas am Functionsumfang?
Wie siehts andersherum aus, neuer Patch mit älterer pin plugin Versionen? wird das gehen?
Wir haben hier unter Gentoo noch die vdr-pin-0.0.20 am laufen,
*hmm, irgendwie den anschluss verpasst ...*
Du kannst mir das schneller aus dem Stehgreif beantworten eh ich hier erst grossartig Versuche starte.
Cheers
/bin/joerg
Hi,
ohne nachsehen habe ich da auch keine Chance, dazu bin ich zu vergesslich. Sicher kann ich jedenfalls schon sagen das zw. der 0.0.20 und 0.1.7 zu viele Änderungen sind als das es noch passen könnte. Bis zu welcher Plugin Version der Patch von 0.0.20 noch funzt und umgekehrt welchen Patch du min für die 0.1.7 brauchst müsste ich leider auch erst rescherschieren (für die 0.1.7 ist jedenfalls ein recht aktueller Patch nötig).
Ich würde es mit dem aktuellen Plugin und dem aktuellen Patch versuchen wobei du beim Patchen bestimmt einige Reject's manuell auflösen musst (wenn es da klemmt kann ich gern versuchen zu helfen).
Kommt ein vdr update nicht in Frage, wenn du den vdr patchst musst du ohnehin alles neu übersetzen?
Grüße
horchi
HI,
gibt es schon einen Patch für die 1.5.0/1.5.1 ?
Danke
Geni
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!