Diese nicht, aber die jeweiligen DVB-Treiber em28xx_dvb und cx231xx_dvb schon.
Dann könnte das ja so auch funktionieren.
Grüße
kamel5
Posts by kamel5
-
-
Eine weitere Möglichkeit (und so habe ich es bei mir gemacht) ist, die adapter_nr bei Treibern die das unterstützen, anzugeben.
z.B. bei mir in der "/etc/modprobe.d/local.conf":options ddbridge msi=1 adapter_nr=4
options smipcie adapter_nr=2,3
Meine zweite DVB-Karte (TT6400) bekommt dann automatisch die Nummer 0 und 1, egal in welcher Reihenfolge die Karten vom System erkannt werden.Leider haben die beiden oben genannten Treiber, em28xx und cx231xx, diesen Parameter nicht.
Grüße
kamel5 -
Ist schon seltsam, bei mir werden die Balken auch mit "menuselection.patch" korrekt angezeigt. Außerdem sollten die Balken bis an den rechten Rand gehen. Das könnte ein Font-Problem sein.
Das ist doch der estuary4vdr-skin? Dann wird die Uhrzeit oben auch mit dem falschen Font angezeigt.
Gemäß "globals.xml" sollten für diesen Skin folgende Fonts zusätzlich installiert sein:
<fonts>
<font name="regular">Lato:Regular</font>
<font name="bold">Lato:Bold</font>
<font name="digital">DS-Digital:Normal</font>
</fonts>
Ansonsten werden die Standard-Fonts genommen.Grüße
kamel5 -
Hallo,
es gibt ein neues Release 1.2.26:
- Fix cSkinDisplayMenu::SetItemEvent war versteckt [-Woverloaded-virtual=]
- Prepare for libxml2 2.15.0Grüße
kamel5 -
olebowle ,
ich habe mir das jetzt mal angesehen. Es sieht so aus, das sich das default-Verhalten von "standalone" in der Version libxml2 2.15.0 geändert hat. Bisher war es so, das "standalone=no" default war, neu ist es "standalone=yes", wahrscheinlich aus Sicherheitsgründen.
Was ist zu tun:
In allen xml-Dateien unter z.B.: "estuary4vdr/xmlfiles/" nachsehen, ob es da einen Eintrag mit dem Bezug auf eine Datei "*.dtd" gibt, z.B.:<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE displayaudiotracks SYSTEM "../../../dtd/displayaudiotracks.dtd">und das dann so ändern: in der ersten Zeile "standalone="no" " einfügen
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE displayaudiotracks SYSTEM "../../../dtd/displayaudiotracks.dtd">Mit dieser Änderung hat es bei mir dann funktioniert. Anpassungen am skindesigner-Plugin selbst sind nicht nötig.
Bei den von mir mit ausgelieferten Skins, estuary4vdr und metrixhd, werde ich das im git ändern. Bei allen anderen Skins gibt es leider das Problem, das ich da keine Anpassungen machen kann.
Bei Deinem bevorzugten Skin musst Du das also selbst machen.
Grüße
kamel5 -
olebowle ,
ich denke nicht, das die beiden Sachen etwas miteinander zu tun haben.
Der Fehler bezieht sich ja auf das "attribute text on drawtext".
Du könntest nochmal testen, ob ein anderer Skindesigner-Skin geht, oder ob es da die gleichen Fehlermeldungen gibt.
Ich kann mir das aber leider im Moment nicht selber ansehen, da ich gerade im Urlaub bin, erst wieder nächten Monat.
Grüße
kamel5 -
Ein Umschalter kann aber immer nur eine Quelle gleichzeitig, oder?
Ja, nur eine Quelle.
Den Mixer hatte ich schon mal gesehen, wollte aber was mit rot/weiss Cinch.
Da wäre dann der erst genannte Mixer geeignet, möglicherweise gibt es sowas auch mit mehr Eingängen.
Oder gibts dann Qualitätsverluste?
Naja, Steckverbinder können natürlich immer eine Schwachstelle sein. Im NF-Bereich für Heimanwendungen würde ich da aber kein großes Problem sehen.
Alternativ gibt es aber auch Adapterkabel 6,35mm Klinke auf Cinch-Stecker, z.B.:
https://www.ebay.de/itm/1340146292…J5NMRM8J7BCQZ7H
Grüße
kamel5 -
Ich hätte da jetzt zB an so einen Mixer gedacht: https://www.amazon.de/Mini-Audio-DJ-…7-0988536?psc=1
Brauchst Du wirklich XLR-Anschlüsse und Phantomspeisung? Das sollte bei den genannten Mikrofonen eigentlich nicht nötig sein.
Ich würde da eher an so etwas denken:
Eingangsumschalter: gibt es auch mit mehr Anschlüssen
https://www.fruugo.de/4-wege-bidirek…BCABEgIIGfD_BwEoder als Mixer:
https://www.amazon.de/dp/B0BZ451WX7/…4e28&th=1&psc=1
https://www.amazon.de/dp/B0FDWYP44M/…843ac34e28&th=1Grüße
kamel5 -
Manchmal werden die nicht richtig abgespielt, aber vielleicht wird es mit dem Patch ja besser.
Die Patche von mir haben da eigentlich keinen Einfluß drauf, da geht es nur um die "info.vdr"-Datei.
Ein Problem, wenn es nicht richtig abgespielt wird, könnte auch die "index.vdr"-Datei sein. Mit der aktuellen VDR-Version kann die aber leider nicht mehr neu erzeugt werden. Du kannst ja mal probieren, die "index.vdr"-Datei umzubenennen und dann nochmal abzuspielen. Dann geht zwar kein "Vor- und Zurückspulen", wenn es dann aber richtig abgespielt wird, liegt es wahrscheinlich daran.
Grüße
kamel5 -
-
kls ,
kannst Du Dir bitte noch folgenden zusätzlichen Patch ansehen.
Durch die Änderungen von "0001-Fix-cutting-off-PesRecording-v2.patch" scheint es jetzt so, das die Prüfung in cRecording::cRecording(), ob die Info-Datei existiert, nicht mehr nötig ist.
Das:
FILE *f = fopen(InfoFileName, "r");
if (f) {
if (!info->Read(f))könnte man auch durch:
if (info->Read()) {
ersetzen, da in "info->Read()" auch geprüft wird, ob die Datei vorhanden ist.
Update:
Der angehängte Patch funktioniert so nicht. Ich habe ihn erst einmal gelöscht. Wenn die aktuell laufende Aufnahme bei mir beendet ist, hänge ich einen neuen Patch an.Grüße
kamel5 -
Was sollen die Änderungen in den *.po-Dateien?
Sorry, das ist mir durchgerutscht. Da gibt es ja keine Änderungen.
Dann kann man IMHO die Errors in info.vdr auch gleich weglassen.
Sehe ich auch so.
Ok, anbei der aktualisierte Patch, jetzt ohne po-Dateien
und ohne Rückschreiben des Errorfeldes.Der Patch enthält auch eine Änderung in "cRecordingInfo::Write()", der die Reihenfolge von "channelName" und "channelID" gemäß der alten "info.vdr"-Datei zurückschreibt.
Diese Änderung habe ich wieder entfernt, ich weiß nicht mehr, wo ich das her hatte, vielleicht eine Fehlinterpretation.
Grüße
kamel5 -
Da fehlt wohl noch irgendwo die Sonderbehandlung für alte info.vdr-Files. Wenn das jemand ergänzen mag, übernehm ich das gerne.
Ok, im Anhang mal ein Patch dazu. Ich habe versucht, das so wenig wie möglich invasiv zu machen. Nach einem Schnitt wird damit die "info.vdr"-Datei richtig angelegt und auch aktualisiert. Zusätzlich wird noch die Zeile mit den "Errors" eingetragen. Ich weiß aber nicht, ob bei alten Aufnahmen Fehler gezählt werden, da wird wahrscheinlich immer "0" drin stehen.
Der Patch enthält auch eine Änderung in "cRecordingInfo::Write()", der die Reihenfolge von "channelName" und "channelID" gemäß der alten "info.vdr"-Datei zurückschreibt. Möglicherweise könnte man diese Änderung auch lassen, denn die Reihenfolge scheint beim Einlesen keine Rolle zu spielen.
Ich konnte bei meinen Tests keine grundsätzlichen Probleme mit dem Patch feststellen, das schließt aber nicht aus, das ich etwas übersehen habe.
Grüße
kamel5 -
das war leider schon immer so.
Das mag sein, ich weiß aber nicht ob das kls schon so bekannt ist. Wenn es so bleibt dann kann ich auch damit leben. Ich habe mich in der Vergangenheit nur gewundert, das nach einem Schnitt einer alten Aufnahme, keine Info mehr angezeigt wurde. Heute habe ich mir das dann mal genauer angesehen...Wenn der Timestamp der info-Datei neuer als das letzte Einlesen ist, wird sie mit neueren VDR-Versionen erneut eingelesen. Ob das auch für die ältere info.vdr gilt müsstest Du mal ausprobieren.
Ja, mit dem neueren Format ("info" Datei) funktioniert es, nur mit dem alten nicht.
Grüße
kamel5 -
kls ,
ich bin im Moment dabei meine alten Aufnahmen etwas zu bereinigen (vor dem TS-Format) und habe dabei festgestellt, das zwar der Schnitt mit der aktuellen Version noch funktioniert, die "info.vdr" Datei aber nicht angelegt wird. Es wird stattdessen eine "info" Datei angelegt, die kaum Informationen enthält:
z.B. nur noch:
E 0 0 0 FF FF
F 25
P 99
L 99
O 0Sollte das noch gefixt werden?
Nach einem händischen Kopieren der "info.vdr" Datei in das Verzeichnis der geschnitten Aufnahme wird nach einem VDR-Neustart die Information wieder angezeigt, ein Neueinlesen der Aufnahmen reicht aber nicht.
Grüße
kamel5 -
Neue Version 1.3.11 im git:
- Check if eventlast is not nullptr
- Fix not showing the footer in cRecMenuTimeline()
- Optimize cRecMenuTimeline
- Optimize cRecMenuItemText
- Add buttons to cRecMenuSearchTimerEdit
- Optimize looking in cDetailView::RerunstoText()
- Add DeleteRecording() to cRecMenuRecordingSearchResults()
- Add "Delete" to cRecMenuSearchTimerEdit()
- Optimize looking in recmanager.cGrüße
kamel5 -
Ein Standard Aufnahme Verzeichnis für alle neuen Aufnahmen lässt sich aber nicht einstellen, oder habe ich da was übersehen?
Ich denke nicht, zumindest habe ich dazu im VDR-Setup nichts gefunden. Das würde aber auch nicht helfen, da Timeshift-Aufnahmen im Prinzip auch Standard-Aufnahmen sind.
Grüße
kamel5 -
Jetzt würde ich gerne z.B. ein Unterverzeichnis des Aufzeichnungs-Ordners für die Timeshift Aufnahmen festlegen, den ich auf das Lokale Dateisystem mounten kann.
Timeshift, sowohl die originale Pause vom VDR und auch mit dem permashift-Plugin, nutzt die originale Aufnahme-Funktion des VDR, d.h. man kann da so wie es jetzt programmiert ist, kein separates Verzeichnis festlegen. Alle Timeshift-Aufnahmen, die ja auch mit dem "@" gekennzeichnet werden können, landen im obersten VDR-Video-Verzeichnis.
Ich möchte alle Arten von Aufnahmen, die nicht an den Server übergeben werden, z.B. in einen Unterordner verlegen.
Das geht so unabhängig voneinander auch nicht.
Man kann natürlich trotzdem zum Ziel kommen:
Dazu müsste man den Server in ein Unterverzeichnis vom VDR-Video-Verzeichnis mounten (so habe ich das z.B. gemacht), dann landen alle Aufnahmen erst einmal lokal, und dann:
1. durch ein Post-Recording-Script jede fertige Aufnahme auf den Server verschieben (ich mache das z.B. per Hand, weil ich vorher alle Aufnahmen händich schneide)
2. Bei jedem Timer ein entsprechendes Verzeichnis (auf dem Server) festlegen, das ist bei Einzel-Aufnahmen natürlich mühsam, bei Suchtimern kann man das im Plugin-Setup als "Standard Aufnahme-Verzeichnis" einstellen.Grüße
kamel5 -
cinfo ,
schau mal hier: RE: Kernel 6.15.0 - TTS2-6400 , das scheint ein ähnliches Problem gewesen zu sein.
Grüße
kamel5 -
Ich hatte die gleiche Anzeige wie in #105 hier auch auf verschiedenen Browsern. Bei mir hat dann geholfen, nicht nur den Browsercache zu löschen, sondern auch noch "Cookies und Websitedaten". Danach war die Anzeige wieder OK.
Siteprefs.css habe ich nicht angefasst.Grüße
kamel5
