Hallo Aladin,

leider funktioniert Dein Plugin iPRec seit einigen Tagen nicht mehr, da tvinfo auf https umgestellt hat. Ursache ist wohl der fehlende ssl-Support in der Dreambox (ich verwende die 7020HD mit Enigma 2 / Merlin 3). Habe auch schon etwas herumprobiert, komme aber nicht weiter. Ein ähnliches Problem wird hier auch beschrieben:
https://www.dream-multimedia-tv.de/board/index.php?page=Thread&threadID=6478&pageNo=2&highlight=iprec

Diese Lösung funktionierte bei mir sogar auf Anhieb!!!! Yipeeh, jetzt geht wieder alles!
opkg update
opkg install python-misc python-textutils --force-reinstall

Hallo,
ich habe jetzt das Problem und die Ursache endlich erkannt und gelöst!
Ich habe heute abend wieder auf Tele 5 Kalkhofe's Mattscheibe und Schlefaz aufgenommen. Beide Aufnahmen wurden wieder geteilt. Diesmal wurden aber die Timereinträge nicht gelöscht. Ich hatte zuvor das Sync-Intervall auf 1h gestellt. Kalkhofe's Mattscheibe wurde dabei exakt zum Zeitpunkt des Sync gem ipRec-log geteilt, ebenso die nachfolgende Schlefaz-Aufnahme jeweils zum sync-Zeitpunkt. Gleichzeitig lief eine Aufnahme auf Sat1 und später auf Spiegel Wissen. Diese Aufnahmen wurden nicht geteilt. Bei den geteilten Tele 5 - Aufnahmen war vor der ersten Sendung wieder eine 4:3-Sendung, vor der zweiten jedoch nicht. Scheint also durch einen erstmaligen Formatwechsel ausgelöst zu werden, bei mir am Häufigsten eben bei Tele 5 und Tele 5 HD via Kabel Deutschland. Ich habe jetzt das Sync-Intervall auf 48h gestellt, damit sollte das Problem dann gelöst sein. Die lange Sync-Zeit ist kein wesentliches Problem, da ich die Dreambox sowieso nach Gebrauch jeweils ausschalte (deep-Standby) und ipRec ja nach dem Hochfahren sich jeweils die Timer holt.
Anbei die Logdatei von ipRec und die Dremabox-xml-Timerdatei für weitere Überprüfungen sowie das Tele5-Programm an diesem Abend. Der Film "Killing Virus Todesflug 335" lief davor und war in 4:3. Schlefaz habe ich gesondert programmiert, diese Aufnahme wurde dennoch geteilt, obwohl ja bezogen auf diese Aufnahme keine 4:3-Sendung davor lief. Aber wenn die Dreambox erstmal im Splitmodus ist, bleibt sie auf diesem Kanal wohl dabei. Anders als früher lief die parallel laufende Aufnahme von Sat1 ungestört. Ich habe ja ipRec insofern modifiziert, als dass zu lange Filmtitel (> 40 Zeichen) gekürzt werden. Das hat bereits einige Probleme gelöst. Das Problem scheint auch nur bei über ipRec programmierte Aufnahmen aufzutreten. ich hatte in den letzten Wochen Kalkhofe's Mattscheibe Freitags 20h mal direkt als Wochentimer programmiert, der Fehler trat hier nie auf.
Zum Nachvollziehen: Die Aufnahmen haben bei mir stets einen Vorlauf von 5 und einen Nachlauf von 10 min. .
Hier die von mir veränderte Zeile zur Kürzung des Filmtitels:
Die Datei
/usr/lib/enigma2/python/Plugins/Extensions/ipRecService/Interfaces/tvinfo.py habe ich verändert, damit Titel auf 40 Zeichen gekürzt wird:
Zeile 154, neu: [0:41]

sTitle = self.xmltools["ConvertToLatin1"](title.text[0:41])

Achtung, es dürfen keine Zeilen hinzugefügt oder gelöscht werden, da die anderen ipRec-Skripte per Zeilensprung Teile aufrufen! Deshalb habe ich die Kürzung in dieser Zeile mit integriert, was zum Glück funktionierte.

Eine einfache und elegante Lösung des Problems könnte ja sein, das ipRec die Synchronisierungen stoppt, wenn Aufnahmen laufen oder bald beginnen. Und welches Skript weiß das besser als ipRec selbst?

Hi Aladin,

am häufigsten tritt das Problem bei "Kalkhofes Mattscheibe", Freitags auf Tele 5 oder Tele 5 HD um 20-20'15h auf, wenn du die Aufnahme per Timer 5 min. vorher startest, damit der Formatwechsel noch voll drauf ist. Ich benutze nicht den Serientimer (wie geht der eigentlich und was macht der genau?), habe die Aufnahmen aber mit jeweils 5 min. Vorlauf und 10min. Nachlauf über tvinfo und iprec programmiert. Der Fehler tritt meist ca. jede 3. Aufnahme auf. Die Wiederholung von Kalkhofe's Mattscheibe am Sonntag abend ist ungeeignet zum Testen, da dort vorher keine 4:3-Sendung läuft. Derzeit teste ich gerade in der Einstellung 1 sync pro Stunde, aber bis man sagen kann, das es was bringt, vergehen ja min. 3 Wochen. Zeitgleich lade ich vor der Aufnahme die iprec-logdatei herunter, damit ich nachvollziehen kann, ob es einen Zusammenhang zwischen dem Sync und dem Aufteilen der Aufnahme gibt. Zusätzlich verwende ich noch dein WOL-Skript zum Mounten des PCs und nehme auf der Freigabe meines PCs auf. Die WOL-Funktion habe ich bei deinem Skript deaktiviert (direkt im Programmcode) und benutze statt dessen das separate WOL-Skript
http://www.i-have-a-dreambox.c…ght=&hilightuser=0&page=1
da dieses den PC nur dann per WOL hochfährt, wenn eine Aufnahme ansteht.

Hi,
ich nutze begeistert Dein Tool. Bei einigen wenigen Aufnahmen passiert es mir jedoch ab und zu, dass diese in mehrere Teile aufgeteilt werden, zudem ist der Timereintrag (sonst als "erledigt" noch einsehbar) verschwunden. Nach einer langen Internetrecherche habe ich lediglich einen passenden Eintrag gefunden:
http://board.newnigma2.to/wbb3…page=Thread&postid=150300
Dort wird das Problem ähnlich beschrieben, er verwendet auch ipRec. Ansonsten scheint niemand das Problem zu haben. Das deutet darauf hin, das es mit ipRec zusammenhängt, es wäre sonst wohl schon öfters beschrieben worden. Meist tritt es bei kurzen Aufnahmen (unter 30min.) auf, scheinbar bervorzugt, wenn zuvor eine Umschaltung von 4:3 auf 16:9 erfolgt. Tlw. erfolgt auch ein exakter Schnitt genau an dieser Umschaltstelle, ich habe es deshalb zunächst für ein interessantes Feature gehalten! Wenn der Fehler auftritt, erfolgt ein Schnitt meist nach 12 min. oder eben gleich am Anfang beim Umschaltmoment.
Könnte es sein, dass die 15-minütige Synchronisierung das Problem verursacht?
Man kann nach meinen Tests diese Zeit auf einmal pro 1..48h verlängern (siehe Abfrage in "xmltools.py"), wenn man den Parameter "synchintervall" in der "ipRecSetup.xml" entsprechend wählt (statt "0"). Das eht übrigens auch ganz einfach über das ipRec-Einstellmenü, wenn man den Synchronisationsmodus auf "manuell" umschaltet. Dann erscheinen plötzlich die zuvor sehnlichst vermissten Einstellpunkte dazu. Schade, dass ich das erst einige Stunden später nach Studium des Programmcodes zufällig entdeckte.
Ich werde einmal testen, ob sich dadurch das Problem beseitigen lässt.