Ich hab da mal etwas weitergebastelt

Änderungen in 1.5c:
- jetzt mit eigenem Display-Skin (Summary-Screen) bei aktivem PTS-Timeshift
(dabei wird dann im Display zum aktuellen Timeshift der Sender, der Sendungsname, der Sendungsfortschritt, die Uhrzeit und die Restlaufzeit angezeigt)

Den Default-Fortschrittsbalken habe ich dabei blau gewählt, um den optischen Unterschied zur normalen InfoBarSummary bei Live-TV (gelber Fortschrittsbalken) zu haben.
Das ganze kann natürlich durch den User komplett umgeskinnt werden.

Info: Die Files aus der zip gelten dabei als Ergänzung zum bereits installierten PTS 1.5

Die InfoBarGenerics nutzt es auch (Cuesheetsupport):
http://git.opendreambox.org/?p…86c061fa5abb305a7d6#l2187

Zitat von Sven H

Also ich habe auf meiner Box einen Renderer "extvolumeText.py" - keine Ahnung, wo der mitkommt.

Ich glaub, ich habs gefunden
http://www.i-have-a-dreambox.c…thread.php?postid=1992285

Zitat

...Das Paket findet Ihr im BP als enigma2-plugin-skincomponents-extcomponents...

@komisch und @obibraun
Und hier nochmal das Widget zur Anzeige der Lautstärke-Einstellung im Display (z.B. im InfoBarSummary):

<widget font="Display;70" position="170,165" render="extvolumeText" size="150,80" source="global.CurrentTime" transparent="0" backgroundColor="#000000" halign="center" valign="center" zPosition="4" />

Zitat von Swiss-MAD

Mir reicht es zum Glück, wenn ich die Lautstärke höre. Das ist meistens der Fall.
Zudem ist die bei mir immer gleich, weil ich die über den AV Receiver regle.
Wieso nur braucht man so was im LCD?

Darum gehts doch bei Skinsachen nicht. Da sind die Wünsche und Bedürfnisse eben völlig unterschiedlich
Die Frage war, ob es geht.
Das wollte ich damit nur bestätigen

Zitat von mr_vica

der Renderer ist in dem .zip file drin
Feed-Skin "DMConcinnity-HD" mit letztem Update 4.3.1r3 überschrieben (aber nicht OE2.5-tauglich)

Das ist ja der von mir für die 920 angepasste Skin.
Da habe ich den Renderer verwendet.
Ich weiß aber nicht, zu welchem Paket der sonst gehört???
Evtl. GP3 ??

Also ich habe auf meiner Box einen Renderer "extvolumeText.py" - keine Ahnung, wo der mitkommt.
Damit kann ich die aktuelle Lautstärke-Einstellung im Display anzeigen (z.B. im InfoBarSummary)

<widget font="Display;70" position="170,165" render="extvolumeText" size="150,80" source="global.CurrentTime" transparent="0" backgroundColor="#000000" halign="center" valign="center" zPosition="4" />

Volume Text Renderer for Dreambox/Enigma-2
# Coded by Vali (c)2010
# Support: www.dreambox-tools.info

Wenn das ganze automatisiert erfolgen soll, dann wäre das der Autotimer.

Er wollte den Stick ja nur als Datensicherung verwenden.
Ich hatte da mal das gleiche Problem, wobei ich den Stick mit dem Video woanders weiterverwenden wollte, wo wiederum nur ntfs funktionierte.

ntfs wird in der Box doch nur readonly gemountet.
Um den ntfs-Stick auch beschreiben zu können, musste ich im GP3 einen kernel-ntfs-g3 oder so installieren.
Dann hat ein normaler ntfs auch an der 920 zum kopieren von Videos funktioniert.

Beim Testen mit dem PTS in anderer Sache ist mir nochmal aufgefallen, dass die Stop-Taste im PTS nach dem ersten Timeshift je Sender immer erst beim 2. Drücken Wirkung zeigt.
Der Tastenbefehl wird zwar ausgeführt, versickert aber irgendwo im E2.

Der letzte Befehl im PTS ist: self.doSeek(3600 * 24 * 90000)

Wenn nichts passiert, kommt nur das im Log:

action -> InfobarTimeshiftActions timeshiftStop
dm920 enigma2[2372]: I/ [InfoBar.ptsSetNextPlaybackFile] :: [PTS-Plugin] setNextPlaybackFile()
dm920 enigma2[2372]: eDVBServicePlay::seekTo: jump 7776000000

Drücke ich dann direkt nochmal, kommt das:
dm920 enigma2[2372]: I/ [InfoBar.ptsSetNextPlaybackFile] :: [PTS-Plugin] setNextPlaybackFile()
dm920 enigma2[2372]: eDVBServicePlay::seekTo: jump 7776000000
dm920 enigma2[2372]: seek.
dm920 enigma2[2372]: stopping thread.

Da fehlt beim ersten Drücken immer das "seek. und stopping thread." im Log.

Ich hab im Code jetzt einfach den doSeek-Befehl doppelt reingenommen, so dass es jetzt auch immer beim ersten Tastendruck funktioniert.
Ist aber trotzdem komisch, warum E2 den ersten Befehl immer verschluckt.

Anleitung zum Nachstellen:
- PTS installieren und im Setup enablen
- Sender wechseln !!! (wichtig, da immer nur beim ersten Timeshift nach Senderwechsel)
- Pause-Taste drücken (Timeshift wird gestartet)
- (zwischendurch Play-Taste ändert das Problem nicht)
- Stop-Taste drücken (es sollte nichts passieren)
- nochmal Stop-Taste drücken (jetzt sollte Timeshift beendet werden und in den Live-TV-Modus gewechselt werden)

- wenn man jetzt direkt ohne Senderwechsel wieder die Pause-Taste drückt
- und dann die Stop-Taste, dann wird es beim ersten Drücken beendet

Erst nach einem Senderwechsel und erneutem Timeshift kommt wieder das Problem.

Ich hab das ganze jetzt mal versucht zu analysieren.
Offensichtlich, gab es da tatsächlich noch einen Bug, der dafür sorgte, dass der Timeshiftfile-Wechsel nicht immer richtig verarbeitet wurde.

Ich hab das mal mit Version 1.5a versucht zu fixen und hab gleich noch einen neuen internen PTS-StandardScreen integriert ("PTSStandardTimeshiftState").
Dieser arbeitet jetzt im PTS generell mit Eventname und ist unabhängig von der im Setup wählbaren PTS-Infobar.
So sieht man im TimeshiftState-Screen den EventNamen der laufenden Timeshiftsendung, auch wenn im Live-TV bereits eine andere Sendung läuft.

Änderungen in Version 1.5b:

• new: show the eventname from the current timeshiftfile always in a new TimeShiftState-Screen "PTSStandardTimeshiftState"
• new: on "Stop-Key" show the TimeShiftState-Screen with STOP-State
• new: show TimeShiftState-Screen after ptsTimeshiftFileChanged
• new: set the correct timeshift-screen directly after changing the pts-settings
• fix: "Stop-Key" to switchToLive - this key works most only on second time (so use doSeek twice - this works)
• fix: set "switchtolive" after SetNextPlaybackFile - the "pts_currplaying" was incorrect after ptsTimeshiftFileChanged

Es wäre schön, wenn ihr die Version mal testen könntet mit entsprechender Rückmeldung

Edit: hab noch 2 kleine Fehler gefunden - daher jetzt schon Version 1.5b

Ich hab das ganze jetzt noch weiter getestet im PTS.

Komischerweise funktionierte es jetzt doch mit dem "ptsTimeshiftFileChanged".
Keine Ahnung, warum PTS bei den letzten Tests die Function nicht ausgelöst hat. Ich muss das mal beobachten.

Dadurch kann ich jetzt doch mit dem pts_currplaying über das aktuelle Timeshiftfile den EventNamen abfragen.
So macht es PTS ja auch, wenn man den PTS-eigenen TimeShiftState-Screen (PTS-Infobar) nutzt.

readmetafile = open("%s/pts_livebuffer.%s.meta" % (config.usage.timeshift_path.value,self.pts_currplaying), "r")
servicerefname = readmetafile.readline()[0:-1]
eventname = readmetafile.readline()[0:-1]
readmetafile.close()
self.pvrStateDialog["EventName"].setText(eventname)

Genau.

PTS speichert ja mehrere Sendungen und legt für jede ein eigenes File an.

Wenn ich jetzt zum Beispiel bei Sendung 1 auf "Pause" drücke und damit Timeshift starte, ist das noch File1.
Beginnt im Hintergrund bereits die nächste Sendung, wird im Hintergrund File2 aufgezeichnet usw.

Wenn ich mich nun aber nach der "Pause" weiter im File1 bewege, sollte dort auch der Name der Sendung1 erscheinen und nicht der Name der aktuellen Live-Sendung2 die bereits im Hintergrund läuft bzw. in File2 aufgenommen wird.

Wenn man nun am Ende von File1 angekommen ist, wechselt E2 automatisch auf das nächste File2.
Im PTS steht dann immer noch "self.pts_currplaying = 1", weil PTS das nicht mitbekommt.

Und da würde mich interessieren, in welchem File (Pfad+Name) man sich gerade im Timeshift-Modus bewegt
Dann könnte ich darüber evtl. aus den meta-files vom PTS an den richtigen Namen kommen.

Gibt es da vielleicht eine nette Funktion ala getCurrentStreamPath() oder getCurrentTimeShiftFile() ?

mit PTS werden ja auch meta-files für jede Timeshift-Sendung angelegt.
Die kann ich auch auslesen, allerdings bekommt PTS offenbar nicht mit, wenn E2 nach Timeshift-EOF (Ende der Sendung) auf das nächste File wechselt.
(self.pts_currplaying wird dabei nicht verändert)
Dadurch bekomme ich dann auch wieder nicht den richtigen EventName des laufenden Timeshiftstreams.

im E2-log taucht beim Wechsel des Files sowas auf:

Gibt es eine Möglichkeit an diese Channelinfos (Pfad + Filename) des aktuell abgespielten Timseshiftfiles (Streams) zu kommen?

Jul 11 14:36:35 dm920 enigma2[1402]: reached EOF, but we are in stream mode. delaying 1 second.
Jul 11 14:36:35 dm920 enigma2[1402]: eDVBChannel: End of file!
Jul 11 14:36:35 dm920 enigma2[1402]: timeshift EOF, switch to next file
Jul 11 14:36:35 dm920 enigma2[1402]: stopping thread.
Jul 11 14:36:35 dm920 enigma2[1402]: FILEPUSH THREAD STOP
...
Jul 11 14:36:35 dm920 enigma2[1402]: alloc PVR
Jul 11 14:36:35 dm920 enigma2[1402]: allocate channel.. 0413:0001:00c00000 (/media/usb//pts_livebuffer.2)
Jul 11 14:36:35 dm920 enigma2[1402]: available channel.. 0413:0001:00c00000 (/media/usb//timeshift.wjwrL6)
Jul 11 14:36:35 dm920 enigma2[1402]: allocate pvr demux

Edit:
Die aktuelle Version ist im Post #51 zu finden

erweiterte Funktionen:
- Anzeige des Sendungsnamens der aktuellen Timeshiftsendung
- eigener Display-Skin zur Anzeige der Infos zur aktuellen Timeshiftsendung im Display
- Anzeige des realen Zeitbalkens inklusive der realen Restlaufzeit während des Timeshiftens der aktuellen Live-TV-Sendung
- bei aktivem Timeshift wird beim Senderwechsel über die Kanalliste vorher gefragt, ob man wirklich den Sender wechseln möchte

==================================================
Ausgangsfrage:
Da mein Wunsch den EventName im TimeShiftState-Screen anzuzeigen sich vermutlich nicht allein per Skin lösen lässt, hab ich da mal etwas weiter probiert.
Im Skin habe ich im Screen "TimeShiftState" und in der PVRState.py ein zusätzliches Label "EventName" angelegt.

Dieses aktualisiere ich beim Anzeigen des TimeShiftState-Screens über die Timeshift-Function "_mayShow()" mit folgendem Code:

service = self.session.nav.getCurrentService()
info = service and service.info()
event = info and info.getEvent(0)
eventname = event.getEventName()
self.pvrStateDialog["EventName"].setText(eventname)

Allerdings wird dabei nur der EventName des Live-TV-Events zurückgegeben und nicht der aktuelle EventName aus dem Timeshift.

Gibt es hier eine Möglichkeit, den EventName der laufenden/zeitversetzten TimeShift-Sendung zu ermitteln?

Über "self.session.nav.getCurrentlyPlayingServiceReference()" bin ich nicht an einen EventNamen gekommen.

Hallo

Ist es möglich, den Event-Namen der aktuell laufenden Timeshift-Sendung in den Timeshiftstate-Screen zu bekommen?

Wenn ich da mal eine längere Pause mache, steht im Display bzw. in der InfoBar schon die nächste Live-TV-Sendung.
Daher hätte ich gern den Namen der aktuellen Timeshift-Sendung zumindest im Timeshiftstate-Screen.

Gibt es da evtl. einen passenden Eintrag für den Screen in der Skin-Datei ?

Noch besser wäre vermutlich ein eigener Display-Screen während des Timeshiftens
Keine Ahnung, ob sowas machbar ist.

Zitat von TommyER

...Man könnte ja auch einen Hotfix raushauen nur für das Problem. Ich brauche den eigentlich sehr häufig ...

Bis das Update kommt, kannst als Zwischenlösung auch in der "/usr/lib/enigma2/python/Screens/MovieSelection.py" in Zeile 61 das IS_DIALOG=True mit einem # auskommentieren
http://git.opendreambox.org/?p…3586c061fa5abb305a7d6#l60

Zeile 61 sollte dann so aussehen:
 #IS_DIALOG=True

Nach einem GUI-Neustart sollte es wieder passen.
Allerdings öffnet sich dann das Menü allein, ohne die Filmliste im Hintergrund.
Aber es löst zumindest erstmal das Problem

Zitat von alpha

...das mit dem swimming probiere ich spaeter mal aus...

Das funktioniert super. Ist genau das, was du dir weiter vorn gewünscht hast
Wenn der Text unten endet, wird auch nicht mehr gescrollt

@zombi
Im OSD ist bei mir im pzymail kein runningtext.
Da läuft nur im Display "PzyMail" als Laufschrift durch.

Das treibt bei mir die CPU auf ca. 60-70% CPU-Last hoch. Genau wie der blinkende Punkt im Display bei laufender Aufnahme im Default FHD.
Vermutlich tritt das CPU-Problem nur im Display auf.
Die Erkenntnis ist jetzt neu für mich - aber Reichi ist da ja dran, zumindest bezüglich des Picture-Blink-Problems.

@arki
Danke für den Widget-Code
Im OSD gibt es da bei mir auch keine Probleme mit der CPU (max. 5,x % für enigma2)
Und das selbst in dem von mir genutzten Skin.

Hab auch mal den Gegencheck zum runningtext-Renderer vom pzymail gemacht.
Da ändert sich auch nichts, die CPU-Last bleibt bei max. 5,x%
(ich glaub, der Code der beiden Renderer ist auch identisch - wollte nur nochmal sicher gehen)

Der vertikale Runningtext ist doch wirklich eine nette Erweiterung.

Zitat von zombi

@pzymail hat garkeinen mehr im DreamOS weil das hatte ich da alles rausgeschmissen und was anderes eingesetzt
pzy-co hatte damals auch nur den original von vlamo ,schon alleine weil er es auch bei anderen Boxen und OE ´s einsetzte .

In der hier installierten Version in Verbindung mit dem hier genutzten Skin ist der runningtext halt noch drin und zeigt eben bei mir seine CPU-lastige Tätigkeit.
Ich hab den bisher aber gelassen, weil das ja nur wenige Sekunden sind.
Ich hatte da aber die Hoffnung, dass ich mit dem Widget von 'arki' beim pzymail die CPU-Last normalisieren kann
Wenn das mit meinem Skin dann grundsätzlich nicht geht, dann hab ich Pech.
Aber ein Versuch ist es allemal wert

Zitat von arki

... Von resource war überhaupt gar keine Rede...

Deine Worte in Post #4

Zitat von arki

…
von 0.5 auf ca 2 % CPU Last ist nicht garade eine Herrausvorderung.
Dr.Best hatte den Rendere das" auf CPU Last gehen" abgewöhnt
...

Zitat

aber wenn es d ich glücklich macht ...

Danke
Dann kann ich das zumindest mal in meinem genutzten Skin testen