Damit wirst du Recht haben; dem Code zufolge dürfte der Timer jetzt wieder "StateWaiting" bekommen haben.

Das trifft aber auch auf gerade hinzugefügte Timer zu - zu diesen Timern wird das Plugin allerdings keine Aufnahme finden.

Ich bin kein Freund von Wiederholungs-Timern: der geschicktere Weg damit umzugehen ist aus meiner Sicht das AutoTimer-Plugin oder das Smart-EPG-Plugin. Beide suchen anhand von Stichwörtern/Sendungsnamen/... regelmäßig nach Sendungen und erstellen dafür dann jeweils einen neuen Timer.

AutoTimer nutze ich auch, aber nur für Sendungen die unregelmäßig ausgestrahlt werden, z.B. in BBC4-HD "The Sky at Night", das klappt prima.
Die Wiederholungstimer haben aber den Vorteil, dass sie immer zu dieser Uhrzeit aufzeichnen, egal wie die Sendung heisst. Manchmal steht im Titel der Sendung "Hörspiel", manchmal der Name des Hörspiels, manchmal ein ganz anderer Titel hinter dem sich dann aber doch ein Hörspiel verbirgt. Und z.B. SRF Radio hat nur den Now und Next EPG, da geht mit AutoTimer gar nichts. Ja ich weiss, man könnte sich den kompletten EPG per Plugin holen.
Als Nicht-Python-Kenner würde ich die Zeile 11 jetzt so ändern, könnte doch funktionieren!?

Auf die Schnelle zum Test habe ich die Zeile erst mal folgendermaßen Quick&Dirty modifiziert:
also die State-Abfrage einfach weggelassen, denn das Plugin wird ja sowieso nur bei Timer-Ende aufgerufen. Oder übersehe ich da etwas?
Jedenfalls habe ich vorhin zum Test ein paar Timer verschiedener Art angelegt und von allen Aufnahmen wurde ein WAV erzeugt!

Ja, könnte so funktionieren. Kleine Optimierung für deinen Vorschlag (Lesbarkeit):

Mach aus der or-Ausdruck timer.state in [ TimerEntry.StateEnded, TimerEntry.StateWaiting ]

Ah, OK, danke!
So habe ich es eingepflegt, und es funktioniert jetzt einwandfrei!
Einmaliger oder wiederholender Timer, beides klappt.

Hallo,

als langjähriger Solo2-Nutzer konnte ich gerade eine Uno 4K SE und eine Duo 4K SE einrichten und testen. Ich war doch überrascht, dass diese (wie wohl auch die anderen 4K-Boxen) deutlich größere Aufnahmedateien erzeugen als die Solo2 (selbe Sendung zu selber Zeit mit gleicher VTI-Version teilweise bis zu 50% größere Dateien durcht größere Bitrate im Videostream; Tonspur und Pixelzahl gleich). Wie hier im Forum gezeigt wurde, liegt dies an der unnötigen Dauerspeicherung der Eit-EPG-Daten:
vuplus-support.org/wbb4/index.…ostID=2030934#post2030934

Gibt es da inzwischen irgendeine Lösung? Ist das Problem an die Entwickler weitergeleitet worden?

Schön wäre ja eine Option, diese Zusatzinformationen des Streams einfach nicht zu speichern oder diese zumindest nachträglich (möglichst automatisiert) zu entfernen.

Vielen Dank und viele Grüße

Warum doppelt? Hast doch schon hier: Plugin AUTOCUT / bei Sky Filmaufnahmen Werbung entfernen und/oder umwandeln in mkv mp4 mp3 gefragt...

Außerdem bist du in dem von dir verlinkten Thread auch nicht allzuweit mit lesen gekommen - eine Lösung steht da schon drin. Und Entwickler: mach dir keine Hoffnungen; Updates im VTi sind sehr selten geworden.

Edit: Falls du einen Aufruf für ffmpeg benötigst, der die EIT-Daten aus der Aufnahme entfernt - hab's grade mal mit einer kurzen Aufnahme auf der Solo4k gemacht:


Das kopiert die Video-Spur und alle Ton- und Untertitel-Spuren. Den Aufruf kannst du als Grundlage für das Script für das Plugin OnRecend benutzen.

Wenn du diese gestrippte Aufnahme allerdings auf der Box spulen oder bearbeiten möchtest, solltest du sie noch einmal durch Reconstruct-APSC laufen lassen. Oder in eine mp4-Datei umwandeln, wenn du nicht bearbeiten möchtest.

Filegrößen dabei:
Original: 62373888 Bytes, gestrippte ts-Datei: 52242756 Bytes, als mp4-Datei: 47144002 Bytes

Diese Aufnahme hat 108 Sekunden.

Das bezog sich auf ein spezielles Plugin, das bei mir leider nicht funktioniert. Den verlinkten Thread hatte ich vollständig gelesen, aber die Lösung bislang nicht hinbekommen. Ich hatte die Hoffnung, dass es eine etwas allgemeinere Lösung geben könnte und habe deswegen den allgemeineren Thread geöffnet (auch um noch einmal auf das in meinen Augen relevante Thema aufmerksam zu machen, immerhin wären das in meiner Bibliothek mehrere Terabyte Datenmüll)...

Danke für den Quellcode. Ich werde mal sehen, ob ich das damit auch hinbekomme...

Danke an @rdamas und @Kingspring Ich habe es jetzt teilweise hinbekommen, ein für mich passendes Script zum Laufen zu bringen (s.u.), das den z.T. großen Datenmüll aus jeder Aufnahme entfernt. Leider habe ich als Programmier-Laie (ohne Python-Kenntnisse) drei Dinge trotz Recherche nicht hinbekommen:

1. Wie angesprochen lassen sich die die Dateien nach ffmpeg mit copy Parameter zunächst nicht richtig abspielen, da die ap-Datei nicht mehr passt. Nach Ausführen von ReconstructApSc ist z.T. leider immer noch die Zeitanzeige in der Filmliste falsch und die Tonspur startet nicht gleich (1-10s delay). Dies liegt an immer noch falschen Werten in der Meta-Datei (Zeile 6 erzeugt falsche Zeitangabe, Zeile 8 den Tonspurdelay). Da ich Filme fast immer über die Filmliste ansehe und die meta-Datei sehr nützlich finde, würde ich sie gerne behalten. Die Lösung: Erst Ausführen von ReconstructApSc, dann(!) löschen von Zeile 6 und 8 der Meta-Datei. Das Anpassen der Meta-Datei habe ich im onrecend.sh-Script implementiert. Aber kann ich dort auch ReconstructApSc für die Datei ausführen (und wie)?

Edit: Das Plugin ReconstructApSc liegt im Ordner (Windows-Explorer-Pfad): rootfs\usr\lib\enigma2\python\Plugins\Extensions\ReconstructApSc

2. Da ich auch sehr viele wiederholende Timer nutze, müsste das Python-Script bei mir auch angepasst werden - wie von Kingspring vorgeschlagen. Gibt es da eine angepasste hochgeladene Version des Onrecend-Plugins oder wie kann ich es selber anpassen? Ich kann die plugin.py des Plugins in Zeile 11 mit Notepad++ vom Windows PC entsprechend ergänzen (s.u.) .. und dann?
3. Wenn ich eingestellt habe, dass der Receiver bei Timerende ausgeht bzw. er im Standby ist und automatisch ausgeht (was ja auch Strom spart und sinnvoll ist), dann wird das Onrecend.sh-Script leider nicht mehr ausgeführt. Kann man das irgendwie fixen bzw. hat jemand eine Idee, wie man den Reciever dazu bringen kann, nach Ende des Timers noch ein paar Minuten zu warten, bis er ausgeht?

Ich habe hier mein Script angehängt, das nach jeder Aufnahme automatisch per ffmpeg den Daten-Stream löscht und die (teilweise deutlich kleinere) gesäuberte Datei an den Originalort schiebt, während die Originaldatei zur Sicherheit in den Temp-Ordner verschoben wird:

1. Ja, du kannst auch Reconstruct-APSC im Script noch aufrufen.
Dazu einfach den Befehl mit ganzem Pfad dort eintragen - etwa so (bin grade nicht vor der Box, die Pfade musst du kontrollieren):

/usr/lib/enigma2/python/Plugins/Extensions/ReconstructApSc/bin/reconstruct_apsc "$InputPath$InputFile"

2. Ja, genauso. Kannst auch die Zeile 11 von @Kingspring kopieren. Dann speichern.

3. Hmm; das ist aufwändiger. Jedenfalls nicht aus dem Script lösbar. Vielleicht kann man dafür eine Queue aufbauen, die nach einem Neustart abgearbeitet wird. Sowas wie die Filenamen in eine Datei schreiben oder leere Dateien in einem separaten Verzeichnis schreiben oder eine zusätzliche Datei für die Aufnahme mit einer neuen Endung .queued oder so anlegen, die nach dem ffmpeg/reconstruct-apsc wieder gelöscht wird.

Und einen Job, der nach dem Neustart nach solchen Dateien sucht.

Danke Das meiste funktioniert jetzt...meistens...

zu 1. Es klappt, Reconstruct-ApSc per Skript aufzurufen! Leider bleibt das Problem, dass die Werte nach ffmpeg in der Meta-Datei - v.a. Zeile 8 - nicht mehr passen und beim Abspielen zu den genannten Fehlern führen (Video/Ton startet nicht richtig; Zeitangabe falsch). Die Idee, Zeile 6 und 8 der Meta-Datei zu löschen, löst meist das Problem - außer bei sehr kurzen Aufnahmen (unter 10-15s). Bei diesen werden wohl korrekte Werte in Zeile 8 benötigt. Ohne Werte lassen sich die Dateien dann mit der Meta-Datei gar nicht mehr abspielen; diese ist defekt.
Hat irgendjemand eine Idee, wie man eine defekte Meta-Datei repariert oder wie man die Werte in Zeile 8 korrekt ermittelt?

zu 2. Mit dem Vorschlag von Kingspring (mit Oder-Bedingung) und Neustart werden jetzt auch wiederholende Timer bearbeitet

zu 3. Interessanterweise wird der Anfang des onrecend.sh-Skriptes noch ausgeführt, dann wird es aber durch den Autoshutdown abgebrochen (auch ohne sleep). Kann man nicht in der .sh (oder im Plugin-Skript) irgendeine Bedingung setzen oder einen Prozess starten, der ein Ausschalten verhindert (je nachdem, in welcher Reihenfolge die Box vor dem Ausschalten die Bedingungen abfragt)? Könnte man die Box sonst direkt bei Timer-Ende aus dem Standby holen (damit sie nicht automatisch ausgeht) und dann irgendwie auf den Ausschalt-Timer zugreifen und ihm nach Aufnahme-Ende mitzuteilen, dass die Box erst nach zB 10 Minuten ausgehen soll?

Gefunden habe ich nur das Systemplugin AutoShutDown im SystemPlugins-Ordner. Aber da kann man ja nur einstellen, wie und wann die Box ausgeht, wobei die Timer nicht berücksichtigt werden (die Box geht dann auch direkt nach der Aufnahme aus). Leider kann man ja nicht einmal global das Verhalten der Box nach Timerende einstellen (nur umständlich in jedem Timer).

Nochmal zu 3. Nein, das geht nicht, ohne den VTi-Code selber zu ändern. Und den haben wir nicht als Python-Code.

Die einzige Möglichkeit, die ich sehe ist, eine Queue aufzubauen, aus der die fertigen Aufnahmen nach und nach konvertiert werden.

Heisst:
- onrecend.sh könnte die Aufnahme z.B. in ein Queue-Verzeichnis verschieben und dann ein anderes Script aufrufen, welches das Queue-Verzeichnis im Hintergrund abarbeitet.
- dieses andere Script kannst du auch nach dem hochfahren aufrufen; es würde dann alle noch nicht verarbeiteten Aufnahmen im Hintergrund konvertieren.

Mir ist das erst jetzt aufgefallen, dass wenn nach einer Aufnahme die Box heruntergefahren wird, diese Aufnahme nicht mehr konvertiert wird, weil knallhart heruntergefahren wird. Bei kurzen Radioaufnahmen (25 Minuten) klappt es noch, bei längeren fehlt dann das Ende.
@rdamas hat mit der Queue eine gute Idee! Das habe ich aufgegriffen und heute nachmittag programmiert. Es gibt jetzt zwei Skripte: "onrecend.sh", das merkt sich nur noch die zu konvertierende TS-Datei als 0-Byte-Datei im Unterverzeichnis "queue" und ruft dann das zweite Skript "onrecend_convert.sh" auf. Das schaut jetzt in dem queue Verzeichnis und arbeitet die Konvertierungen ab. Die 0-Byte-Datei wird erst gelöscht, wenn komplett konvertiert wurde. Kommt das Herunterfahren dazwischen, wird beim erneuten Start der Box das Skript aufgerufen und die Liste abgegearbeitet.

Und genau das bekomme ich nicht hin! Wie kann ich der Box sagen, dass sie beim Start das Skript aufruft?
Ich habe schon im VTi-Panel versucht einen Cronjob einzutragen, aber ohne weitere Parameter wird es jede Minute aufgerufen.
Beim Raspi z.B. schreibe ich in die crontab "@reboot /pfad/skript.sh", das funktioniert hier nicht.

Ich stelle trotzdem mal meine beiden Dateien hier ein, sollten soweit funktionieren solange nicht das Herunterfahren dazwischenkommt. Vielleicht kann @Solo2-Nutzer_ab_2014 etwas damit anfangen!

Zum Thema "abruptes Rumterfahren" noch ein Hinweis:
Ich lasse meine Box beim Ausschalten per Timer oder Fernbedienung immer nur in den Standby fahren.
Durch automatisches Ausschalten schaltet sich die Box dann nach 15 Minuten ganz aus.
Damit hättest Du nach dem Beenden des Timers noch ein paar Minuten Zeit, um die Todo-Liste zu verwalten.

Beim Start der Box kann ein Shell-Script z.B. über den Cron gestartet werden.
Ein Plugin könnte über eine Aufgabe gestartet werden.

Ich bin mir nicht ganz sicher, ob der Busybox-crond im VTi schon die Zeitangabe "@reboot" versteht (google mal nach "crontab @reboot"), in den aktuellen Sourcen ist das drin; aber ich benutze (inzwischen) einen anderen crond auf meinen Boxen, werde das also nicht ausprobieren.

Wenn das mit "@reboot" nicht funktioniert, kannst du immer noch ein Init-Script im Runlevel 3 anlegen, das den Job ausführt. Den Crontab-Eintrag wirst du wohl mit "crontab -e" anlegen müssen (und vorher mit "export EDITOR=vi" einen Editor festlegen, mit dem du umgehen kannst).

Hätte den Vorteil, dass deine Crontab auf Korrektheit geprüft wird.

Ich hab das mit "crontab -e" und "@reboot" nochmal getestet, der Eintrag in der Datei "root" ist identisch wie vorher und es funktioniert leider nicht.

Init-Script im Runlevel 3: da musste ich erst mal nachlesen...
Also das "onrecend_convert.sh" ins Verzeichnis /etc/init.d kopiert und mit
ln -s /etc/init.d/onrecend_convert.sh /etc/rc3.d/S95onrecend_convert.sh
den Symlink erzeugt.

Dann noch eine Datei in die Queue kopiert und die Box neu gestartet, mit dem Erfolg dass kein Fernsehbild mehr kam.
Meine Logdatei zeigte aber dass das Skript gestartet wurde und als letzten Eintrag, dass das TS demuxed wird, bis zum Löschen ist es aber nicht gekommen.
Hab den Symlink gelöscht, neu gestartet, Box läuft wieder.

Was habe ich denn falsch gemacht?

Vielleicht reicht es ja, wenn ein eigenes init-Script das onrecord_convert.sh im Hintergrund startet mit & am Ende des Aufrufs.

Schau dir auch andere init-Scripten mal an.

Es läuft!
Ich habe das Skript mit der höchsten Nummer aus Runlevel 3 (/etc/init.d/rmnologin.sh) editiert und diese 2 Zeilen vor der letzten Zeile (exit 0) eingefügt:
Zum Test eine Datei in die Queue und die Box neu gestartet.In der Logdatei sah ich gleich wie er dann schön demuxt ... perfekt, genau so lasse ich es und teste in den nächsten Tagen.

Danke @rdamas, heute hab ich wieder viel dazugelernt!

Sehr cool, was hier alles gepostet wird

@RickX: Das mit dem System-Plugin "Automatisches Ausschalten" habe ich probiert. Da die Aufnahme standardmäßig im Standby erfolgt, wird die Zeit der Aufnahme schon als Standbyzeit mitgerechnet, so dass die Box leider trotzdem sofort nach Timerende ausgeht

@Kingspring: Echt genial, dass du alles gleich umsetzt und hier postest . Um es nochmal zusammenzufassen:

Man schiebt den eigentlichen Konvertierungsvorgang in ein neues Skript onrecend_convert.sh, welches sowohl nach Timerende (von der modifizierten onrecend.sh), als auch bei Start der Box aufgerufen wird. Und damit es beim Start der Box aufgerufen wird, muss man das rmnologin.sh wie dargestellt modifizieren und einen Systemlink von onrecend_convert.sh in etc/rc3.d erzeugen. Und das onrecend_convert.sh Skript muss trotzdem nach /etc/init.d geschoben werden (und der Pfad im onrecend.sh entsprechend angepasst werden)?

Außerdem noch mal eine Verständnisfrage, da ich von Programmieren wenig und von Queues gar keine Ahnung habe:
Wie funktioniert die spezielle for-Schleife mit QUEUE:
Wird so für jede Datei im Ordner die Schleife einmal durchlaufen und der Dateiname jeweils als Wert der Variablen QUEUE übergeben?

Ja, die Idee mit dem System-Plugin "Automatisches Ausschalten" wäre super, aber leider in diesem Fall doch nicht praktikabel.

Genau, der eigentliche Konvertierungsvorgang geschieht in "onrecend_convert.sh" und wird nach Timerende und beim Box-Start aufgerufen.
Um es beim Start der Box aufzurufen, muss man nur das "rmnologin.sh" modifizieren, sonst nichts.
Das mit dem Symlink und dem rc3 hatte bei mir nicht funktioniert. Es wurde zwar aufgerufen, aber die Box fuhr nicht komplett hoch. Vielleicht wollte/muss das System auch auf das Abarbeiten des Skripts warten, das weiss ich aber nicht.
Das "onrecend_convert.sh" muss nicht unbedingt in /etc/init.d stehen, das kann irgendwo stehen, der Pfad im "onrecend.sh" und im "rmnlologin.sh" muss aber stimmen!

In der BASH-Programmierung hier bin ich auch nicht der grosse Held, ich bin lieber beim guten alten Assembler...
Ob also meine Schleife der Weisheit letzter Schluss ist?
Du hast es schon richtig interpretiert, die Schleife geht im aktuellen Verzeichnis die Dateinamen durch. Wenn z.B. 3 Dateien im Verzeichnis sind, wird die Schleife 3 mal durchlaufen, dabei erscheint der Dateiname immer in der Variable QUEUE (die kann auch einen anderen Namen haben).

So ganz bin ich aber noch nicht zufrieden mit der Lösung. Wahrscheinlich werde ich das in den nächsten Tagen nochmal ändern, dann wird im "onrecend.sh" nicht mehr das "onrecend_convert.sh" aufgerufen. Ebenso wird beim Start des Receivers das "onrecend_convert.sh" nicht mehr gestartet.
Stattdessen kommt das "onrecend_convert.sh" in einen Cron-Job, der z.B. alle 15 Minuten aufgerufen wird. Mir ist es nämlich erst vorhin passiert, dass drei Timer kurz nacheinander zu Ende waren und somit das Skript 3 mal kurz nacheinander aufgerufen wurde und ein Hörspiel wurde dann zwei mal konvertiert. Da ist jetzt zwar nichts schiefgegangen, aber wer weiss...
Wenn's fertig ist, schreibe ich hier!

Danke für die Erklärungen, da hab ich jetzt wieder was gelernt .. Vielleicht bekomme ich es mit so einer Schleife auch hin, mir ein Skript zu schreiben, das alle bereits vorhanden unkonvertierten Dateien nacheinander konvertiert..

Die Frage ist, wie man die Konvertierung neuer Aufnahmen am besten implementiert: Ich finde es in jedem Fall sehr praktisch, wenn die Aufnahmen direkt nach Timerende konvertiert werden. Dann kann man sie sofort nutzen. Die gravierenden Probleme dabei sind jetzt wohl gelöst. Allerdings kann es trotzdem noch Probleme geben:

So kommt es vor, dass ich einen Timer während der Sendung abbreche, dann aber neu programmiere. Wenn man das per EPG macht und die vorherige Aufnahme der Sendung nicht mehr mit ursprünglichem Namen am Standardspeicherort ist (wegen des Skriptes), dann bekommt die Sendung bei der neuen Aufnahme den exakt gleichen Namen, wodurch das OnRecEnd-Skript bei Timerende die ursprüngliche konvertierte Aufnahme überschreiben könnte. Das Vorhandensein des Dateinamens sollte man also vor dem Speichern abfragen oder (so wie ich es aktuell mache) die Originaldatei bzw. eine identisch benannte konvertierte Datei sollte weiter gespeichert bleiben, sodass der Timer einen neuen Namen vergibt.

Wenn Timer (mit verschiedenen Namen) allerdings zur exakt gleichen Zeit enden, dann hat bei mir immer alles geklappt, da das Skript zwar mehrfach fast zeitgleich aufgerufen wird, allerdings nach dem jeweiligen Aufruf unabhängig von den anderen Aufrufen arbeitet.