Schön, dass es doch noch geklappt hat.
Ich habe den Patch nochmals gecheckt, das Image sollte drin sein. Kann aber sein, dass sich Git mit Binaries in Patches etwas schwer tut. Mir ist das dieser Tage bei irgendeiner Git-Operation (die Details sind mir leider schon entfallen) etwas Ähnliches passiert. Auch da musste ich das Image nochmals per Hand einspielen.
Danke
- bei mir ist das Grau aber (Standardpalette "Veltliner")
nicht da:
Die Timer-Anzeigen sind nicht Teil der Themes, sondern finden sich alle im Verzeichnis live/img im Git-Verzeichnis. Von dort wird die Grafik auch geladen:
<img src="img/<$ en.timer_is_active ? "record_timer.png" : "record_inactive_timer.png" $>"Schau also bitte einmal, ob du eine Datei live/img/record_inactive_timer.png findest oder kopiere die beigefügte Grafik () einmal dorthin und rufe danach make install-web auf. Beim Browser hilft zudem oftmals ein vollständiger Reload (Shift+Relload beim Firefox) oder das Leeren des Caches.
Viele Grüße
Stefan
Was ist anders bei mir (oder dir) ?
Keine Ahnung, aber mit dem Stand vor der besagten Änderung bzw. dem aktuellen Stand und dem Patch geht es jedenfalls. Ob es alle Aufzeichnungen betrifft oder nur die, bei denen es mir aufgefallen war, ist ebenfalls unklar.
Was ich aber in dem Zusammenhang vermisse, wäre, dass ein vorhandener Timer (natürlich zu einem anderen Zeitpunkt, sonst wird er ja als aktiver Timer angezeigt) auch in den Suchergebnissen angezeigt werden würde. Das verhindert versehentlich doppelte Timer zur gleichen Sendung.
Das habe ich bisher noch nie vermisst, was aber auch an meiner Vorgehensweise liegen mag: Wann immer ich eine Sendung (Film) aufnehmen möchte, suche ich nach ihren Wiederholungen und programmiere sie alle. Vor allem auch deshalb, weil bei sich gerade bei HD-Aufzeichnungen gerne mal TS-Fehler einschleichen. Und Aufnahmen mitten in der Nacht verzichten auch auf den einen oder anderen Werbeblock bzw. eingeblendete Programmhinweise, die man dann notfalls auch mal herausschneiden kann.
Doppelte Timer sind bei mir also fast schon der Normalfall. Wenn ich einen Timer dann nicht mehr benötige, setze ich ihn auf inaktiv (deshalb Patch Nr. 10) oder lösche in gleich.
Eine solche Erweiterung müsste sich aber wohl am besten Markus vornehmen, denn so tief stecke ich im Timer-Manager nicht drin…
Viele Grüße
Stefan
Ich habe die Farbe nur per Hue geändert. Den Kreis mit einem hinsichtlich der Schattierung perfekten Grau zu füllen, ist etwas aufwändiger – war jetzt aber gar nicht so schlimm:
Damit sieht es dann zum Beispiel so aus:
Ich nutze Live ohne den Tvscraper. Bis einschließlich Version 3.1.8 hat Live immer existierende Aufzeichnungen gefunden und in der Programmübersicht aufgelistet. Doch seit einer Codeänderung im März 2023 findet Live im Programm ohne die Scraper-Daten keine existierenden Aufzeichnungen mehr.
Gibt es äußer mir noch andere Nutzer, die ohne den Scraper unterwegs sind? Falls ihr dieses Problem ebenfalls kennt, hätte ich hier einen Patch, der das Problem löst, für die Scraper-Gemeinde aber diesbezüglich ohne Einfluss ist:
Der Patch hat allerdings noch eine kleine "Nebenwirkung", denn habe die Darstellung existierender Aufzeichnungen in der Programmübersicht visuell etwas überarbeitet.
Auch habe ich die Funktion, welche, die Namen von Aufzeichnungen fürs Suchen und Sortieren normalisiert, dahingehend überarbeitet, dass nicht nur wie bisher Interpunktionszeichen eliminiert, sondern auch Whitespace-Sequenzen zu einem einzigen Space konsolidiert werden. Das sollte auf die Funktion für den Scraper aber keine Auswirkung haben – mag das vielleicht mal jemand testen?
MarkusE: Im Code wird noch ein weitere Spalte verwaltet, die aber – so meine Interpretation – ohne Offline-Referenz den Tabellenaufbau zerstört (die Zeile weicht dann um eine Spalte ab). Ich habe diesen Teil auskommentiert, aber das solltest du dir vielleicht nochmals anhand von Spieldaten ansehen und eine adaptive Lösung vorschlagen. Im Patch ist das hier:
- if (archiveDescr.length != 0) col_span1--;
+// if (archiveDescr.length != 0) col_span1--;Viele Grüße
Stefan
wird (mit Patch Nr. 8 für das Timer-Popup) zu:
mit den Details des ersten Timers:
Hallo zusammen,
ich nutze selbst ein paar Patches, die vielleicht für den einen oder anderen von euch von Interesse sein könnten. Markus hat vorgeschlagen, solche Patches hier im Forum in jeweils einem Thread kurz vorzustellen und euer Votum einzuholen, ob sie ins Git sollen:
Bislang zeigt Live in allen Übersichten jeden Timer mit einer grünen "Lampe" an, egal, ob der Timer aktiv ist oder auf inaktiv gestellt wurde. Dies betrifft die Programmübersichten, die Zeitleiste, die Suchergebnisse von Suchtimern und die Detailanzeigen. In der Zeitleiste werden Sendungen, für die ein Timer gesetzt ist, hellrot unterlegt, wobei auch hier nicht zwischen aktiv und inaktiv unterschieden wird.
Der Patch zeigt an allen Stellen für anstelle der grünen für aktive Timer eine hellblaue Lampe für inaktive Timer an. In der Zeitleiste werden die entsprechenden Sendungen statt hellrot für aktive nun hellgrau für inaktive Timer unterlegt.
Weil pro Beitrag immer nur fünf Dateien hochgeladen werden können, findet ihr die Screenshots weiter unten.
Lasst man die Farbwahl auf euch wirken, vor allem bezüglich der Unterscheidbarkeit von grün zu hellblau. Falls ihr den inaktiven Timer mehr Richtung dunkelgrau haben möchtet – kein Problem. Mir war er dann nur zu "unauffällig".
Viele Grüße
Stefan
wird zu:
wird zu:
Wenn im Setup alle Streaming-Funktionen eingeschaltet sind:
bleiben (siehe oben) leere Spalten verborgen. Hier und in den Details:
… finden sich nun alle Streaming-Buttons.
Hallo zusammen,
ich nutze selbst ein paar Patches, die vielleicht für den einen oder anderen von euch von Interesse sein könnten. Markus hat vorgeschlagen, solche Patches hier im Forum in jeweils einem Thread kurz vorzustellen und euer Votum einzuholen, ob sie ins Git sollen:
Mal sehen, ob ich noch alles zusammen bekomme: Der Stream-Button zum Abspielen eines Kanals oder einer Aufzeichnung im Media-Player ist nicht an allen Stellen vorhanden, selbst wenn er in den Einstellungen unter "'Aufnahme in Mediaplayer abspielen' in Listen anzeigen" aktiviert ist. Diese Einstellung wird auch nicht immer korrekt geprüft, weshalb der Stream-Button bspw. in der Listenansicht von "Was läuft?" (eigentlich in jeder Toolbox und damit auch rechts in der Detailanzeige) fehlt. Zudem wird in der Listenansicht eine leere Spalte ausgegeben, wenn die Wiedergabe über Browser bzw. Media-Player abgeschaltet ist. Und während der Stream-Button im Header der Programmübersicht vorhanden ist, fehlt er bei der Fernbedienung, von wo aus man das Streaming ja vielleicht auch starten möchte. Auch empfinde ich den lilafarbenen Knopf als sehr kalt.
Der Patch verknüpft den Stream-Button konsequent mit der Einstellung im Setup und fügt ihn auch der Fernbedienung hinzu. Damit erscheint er auch in jeder Toolbox und somit in der Detailanzeige. In der Listenansicht der von "Was läuft?" wird eine Spalte für die Wiedergabe im Browser oder Media-Player ausgeblendet, wenn die entsprechende Funktion abgeschaltet ist. Das lilafarbene Icon wird durch ein orangefarbenes ersetzt, das ein wenig an die Pylonenfarbe des VLC-Media-Players erinnern soll.
Weil pro Beitrag immer nur fünf Dateien hochgeladen werden können, findet ihr die Screenshots weiter unten.
Viele Grüße
Stefan
wird zu:
Hier noch mit Fortschrittsbalken:
wird zu:
Hallo zusammen,
ich nutze selbst ein paar Patches, die vielleicht für den einen oder anderen von euch von Interesse sein könnten. Markus hat vorgeschlagen, solche Patches hier im Forum in jeweils einem Thread kurz vorzustellen und euer Votum einzuholen, ob sie ins Git sollen:
Die Abfolge von Ellipsen ("…") und dem Link "mehr" finde ich von der Anordnung her unschön. Anstelle von "mehr …" gefiele mir "… mehr" deutlich besser. Außerdem steht der Text an einigen Stellen direkt am Rahmen an, während er an anderen Stellen um ein paar Pixel abgesetzt ist. Auch sollte in Popups der Hinweis "Für Details klicken" etwas vom davorstehenden Text abgesetzt sein.
Dieser Patch stellt die Abfolge von Ellipsen und dem "mehr"-Link um und setzt die Ellipsen mit einem Leerzeichen vom Text ab, sodass bei einem Satzende nicht gleich vier Punkte hintereinander kommen. Die Programminformationen sind einheitlich abgesetzt und der Klick-Hinweis in den Popups ist etwas vom Text abgesetzt.
Weil pro Beitrag immer nur fünf Dateien hochgeladen werden können, findet ihr die Screenshots weiter unten.
Viele Grüße
Stefan
Ich habe mir die Implementierung vor einer gefühlten Ewigkeit schon einmal kurz im VDRAdmin angeschaut. Soweit ich mich erinnere, nutzt(e) VDRAdmin das Interface von svdrpsend.
Damals bin ich jedenfalls nicht weitergekommen – vor allem auch deshalb, weil mir die VDR-APIs zum Implementieren einer gleichwertigen Zeitleiste nicht geläufig waren (sind). Aus dem Bauch heraus wäre meine Vorgehensweise, die Logik für die Ermittlung der Devices bzw. den Algorithmus zur Darstellung der Zeitleiste aus dem VDRAdmin abzuleiten und diese mit den internen APIs des VDR-Core zu "re-engineeren".
Viele Grüße
Stefan
Vielleicht würde es ja auch Sinn machen, die Zahl generell auf "defekte Frames" umzustellen, auch bei der original Aufnahme?
Ich fände das eh sinnvoller.
Jetzt fehlten nur noch ein paar Tasten, mit denen man Blöcke fehlerhafter Frames (das erste bzw. letzte I-Frame eines Blocks) gezielt ansteuern könnte – so wie Sprungmarken. Dann könnte man vor dem Schneiden noch schnell checken, ob sich die Fehler im Vor- bzw. Nachlauf oder in einer Werbeunterbrechung befinden.
Ja ja, ich weiß schon: die Sache mit dem kleinen Finger und dem ganzen Kerl... 
Viele Grüße
Stefan
Das hatte ich gesehen und auch schon in diese Richtung überlegt. Allerdings wäre dann die Semantik von "O" nach dem Schneiden (fehlerhafte Frames) eine andere als vor dem Schneiden (fehlerhafte Rahmenbits, wie ich vermute)...
Danke jedenfalls
Stefan
Genau das mache ich derzeit, was aber ein wenig lästig ist und im Nachgang immer viel Handarbeit erfordert.
Hallo Klaus,
erst einmal vielen Dank für deine Überlegungen. Wenn sich die Fehler nicht beim Verarbeiten (Schneiden) des Datenstroms "en passant" ermitteln lassen, scheint dein Ansatz wohl am zielführendsten zu sein.
Noch ein paar ergänzende Gedanken: Schnittmarken können ja laut Handbuch ja immer nur an I-Frames gesetzt werden. Insofern bräuchte man also nur per I-Frame vermerken, wie viele Fehler in ihm selbst und den folgenden B-Frames aufgetreten sind. TS-Fehler müssten für den gedachten Zweck auch nur auf Granularität solcher Schnittblöcke protokolliert bzw. beim Schneiden akkumuliert werden. Blöcke ohne TS-Fehler bräuchte man dabei nicht protokollieren, wenn man fehlende Blöcke als fehlerfrei betrachtet.
Landet ein protokollierter Block (I-Frame mit seinen B-Frames) in der geschnittenen Aufzeichnung, wird die Zahl seiner TS-Fehler aufaddiert. Entfällt ein protokollierter Block, sind seine TS-Fehler ohne Belang. Ein nicht protokollierter Block ist per definitionem fehlerfrei.
Textbasiert kann eine Datei mit den TS-Fehlern per Block recht groß werden. Insofern wäre ein binäres Dateiformat wie bei index mit Tupeln von (struct tIndexTs block, uint64_t tsErrors) wohl günstiger. [uint64_t deshalb, damit man die Datei mit od -tx8 schön ausgeben lassen kann.]
Schick wäre das alles schon. Bezüglich der Frage, ob sich der Aufwand für dich lohnt, hoffe ich auf eine wohlwollende Einschätzung...
Viele Grüße
Stefan
Hallo Klaus,
wieder einmal vielen Dank für das VDR-Update. Noch eine Frage zu den TS-Fehlern: Wenn man eine Aufzeichnung schneidet, kann es ja durchaus passieren, dass die TS-Fehler im "abgeschnittenen" Teil lagen und in der geschnittenen Aufzeichnung nicht mehr enthalten sind. Trotzdem bleibt in den Infos die ursprüngliche Fehlerzahl stehen.
Siehst du eine Chance, die Zahl der TS-Fehler beim Schneiden neu zu ermitteln, sodass die geschnittene Aufzeichnung diesbezüglich "korrekt" ist?
Danke & Grüße
Stefan
Hi,
hier noch meine zwei Cents, wie man so schön sagt: Leider eignen sich nicht alle meine Eingänge gleich gut für HD-Aufnahmen, denn einige führen mit höherer Wahrscheinlichkeit zu TS-Fehlern. Insofern versuche ich, HD-Aufnahmen bevorzugt auf die "guten" Eingänge zu legen, was mit ein bisschen jonglieren meist gelingt.
In diesem Kontext vermisse ich seit VDRAdmin die Zeitleiste mit der Prognose, welche Aufnahme (ohne zwischenzeitlichem Kanalwechsel) welches Device verwendet.
Aus meiner Sicht wäre das somit auch ein cooles Feature...
Viele Grüße
Stefan
Hi Klaus und Markus,
auch ich hatte gestern nach dem Upgrade auf v2.6.8 unerklärliche Abstürze. Aufgefallen ist das beim Editieren der Suchtimer von EPG-Search, bei denen ich u.a. reguläre Ausdrücke mit mehreren Alternativen (Pipe-Zeichen, "|") nutze und bei deren Speicherung genau die von Markus zitierte Codestelle (Zeile 5) durchlaufen wird.
Weil der VDR laut Core-Dump aufgrund eines Längenfehlers von realloc innerhalb von vasprintf gecrasht ist:
#0 0x00007259bba969fc __pthread_kill_implementation (libc.so.6 + 0x969fc)
#1 0x00007259bba42476 __GI_raise (libc.so.6 + 0x42476)
#2 0x00007259bba28885 __GI_abort (libc.so.6 + 0x28885)
#3 0x00007259b78b3abb n/a (libGraphicsMagick-Q16.so.3 + 0xb3abb)
#4 0x00007259bba42520 __restore_rt (libc.so.6 + 0x42520)
#5 0x00007259bba969fc __pthread_kill_implementation (libc.so.6 + 0x969fc)
#6 0x00007259bba42476 __GI_raise (libc.so.6 + 0x42476)
#7 0x00007259bba287f3 __GI_abort (libc.so.6 + 0x287f3)
#8 0x00007259bba89676 __libc_message (libc.so.6 + 0x89676)
#9 0x00007259bbaa0cfc malloc_printerr (libc.so.6 + 0xa0cfc)
#10 0x00007259bbaa4c6c _int_realloc (libc.so.6 + 0xa4c6c)
#11 0x00007259bbaa5862 __GI___libc_realloc (libc.so.6 + 0xa5862)
#12 0x00007259bba88115 __vasprintf_internal (libc.so.6 + 0x88115)
#13 0x00007259b5938da3 vasprintf (libvdr-epgsearch.so.2.6.8 + 0x87da3)
#14 0x00007259b5924b53 _ZN10cSearchExt6ToTextEv (libvdr-epgsearch.so.2.6.8 + 0x73b53)...habe ich zwar im Plugin gesucht, dort aber nicht gleich die entscheidende Codestelle gefunden. Zumal der Crash erst beim 14. regulären Ausdruck (davon dem 7. mit mehr als einem Pipe-Zeichen) aufgetreten ist. 
Nach Einspielen des Patches läuft wieder alles wie gewohnt. 
Danke euch und viele Grüße
Stefan