Posts by SHF

    Ich habe Abstürze bei leerer index-Datei beobachtet.

    Aber nur, wenn die Datei 0 Byte hat und vorhanden ist. Wenn sie ganz fehlt, wird sie neu erzeugt.

    Erreichen kann man den Zustand, in dem man während der Index-Generierung "exit" drückt und die Wiedergabe beendet.


    Könnte das, dein Problem sein?

    Sämtliche genannten Zeilennummern stammen cIndexFile::...


    Die Abfrage access(fileName, R_OK)(Zeile 2577) scheint wohl nicht zu reichen.

    Da müsste man wohl mindestens noch auf Grösse >0 prüfen.

    Was bei unvollständigen index-Dateien passiert ist dann auch noch eine Frage. (ist bei mir aber noch nicht aufgetreten)


    Da mein Produktiv-System inzwischen etwas (hust) veraltet ist, wollte ich nicht sofort einen Bugreport aufmachen.

    Raspberry Pi HQ Camera (12.3MP)

    Das Modell mit dem Schraubobjektiv und IMX477R Sensor?

    Und als Objektiv das 6mm Weitwinkel?

    Nur dass es keine Missverständnisse gibt.


    Das Modul hat jedenfalls keine Blende.

    Das Objektiv zwar schon, aber die ist nicht per Software beeinflussbar.

    Man kann die Blende also als fest betrachten und weiterhin ignorieren.


    Die EXIF-Daten sehen mit dem Hintergrund eigentlich auch gut aus.

    Die Linsenparameter fehlen, aber sonst scheint alles wichtige da zu sein.

    Belichtungszeit und ISO sind angegeben, die Blende fest, damit müsste am arbeiten können.


    Eventuell muss man die Linse auch irgendwie konfigurieren und hat dann die Linsenparameter EXIF-Daten?

    Ist ja schliesslich ein Originalzubehör.
    Bei piHDR klappt das ja auch, allerdings haben die wohl ein anderes Kameramodul verwendet "IMX219".

    Ich würde mich generell am Vorgehen von piHDR orientieren.

    Die schiessen die 6 Fotos mit vorgegebener Zeit, festem Weissabgleich und ISO-Wert.

    So liessen sich die stonits notfalls errechnen.


    Ob das mit den "ev" Werten vom Raspi geht habe ich Zweifel.

    Der Bereich +-12 ist für meinen Geschmack auch etwas gross. Üblich ist +-2 vielleicht +-4.

    Ich habe da irgendwie die Befürchtung, dass die Daten von einer Belichtungsserie, nicht zur nächsten passen.


    Auch bei der Nachbearbeitung würde ich mich an piHDR orientieren.

    Nach dem ersten Aufruf sollten die Fotos vorliegen, da kann man abbrechen und die Aufnahmen für weitere Versuche verwenden.


    Entweder könnte man nun den Aufruf von "hdrgen" anpassen oder man fügt einen Fake-Blendenwert bei den Aufnahmen hinzu und schaut, ob es dann geht.


    Da sich die Blende nicht ändert, kann bei allen Aufnahmen immer er gleiche Wert genommen werden. Bei raspistill soll es einfach gehen Exif als Parameter zu übergeben. Bei der Python-API müsste man mal schauen.



    Getestet habe ich bisher die Formate 1920x1080, 1280x720, 720x576, 480x576, 1280x1080.

    720x576 und 480x576 gibt es ja in 4:3 und 16:9.

    Aspectratio wäre also auch noch wichtig, mit der Auflösung allein weiss man noch nicht wie man das darstellen soll.


    Und ob es Interlaced ist oder nicht sollte vielleicht auch noch rein. (Ausgestorben ist das trotz HD ja leider immer noch nicht.)

    Mit den rsp-Daten aus #8 (danke wirbel) als "picam.rsp" abgespeichert bekomme ich mit drei Jpeg-Dateien, aufgenommen mit ev -6, 0, +6 bei

    Ich habe es so verstanden , dass man OHNE "picam.rsp" mit den 3 Bildern so eine rsp-Datei erstellen soll.

    (Im Prinzip wie Panotools die Objektiv-Korrektur-Parameter für Verzerrungen usw. aus überlappenden Aufnahmen berechnet. Damit könnte man übrigens die Fisheye-Aufnahmen auch in eine "bessere" Projektion umrechnen.)


    Dazu müssen die Aufnahmesequenz aber geeignet sein. Das Motiv sollte also jeden Farbkanal des Sensors, komplett abdecken.

    Ich würde mir da die Histogramme der einzelnen Aufnahmen mal ansehen. Da sollte jeder Farbkanal von hell bis dunkel gut belegt sein.

    Was man da am besten an Motiv nimmt, bin ich aber überfragt, ich mach nicht so viel mit HDR. Ich schätze aber, Kontrast bei allen Helligkeitsstufen ist auch wichtig.

    Die Auswahl der Aufnahmesequenz scheint wohl kein Selbstläufer zu sein:

    Quote

    If a scene contains no low frequency content or gradations of intensity, it may be impossible to derive the response curve from the exposure sequence.  Thus it is better to create this information once for a given camera and reuse it for other sequences.


    Ich schätze, das Problem liegt in den Aufnahmen.

    Die Korrekturkurve in der .rsp-Datei ist auch nur eine Gerade. Das ist verdächtig, so gut kann die Kamera eigentlich nicht sein.


    Zunächst würde ich bei den Bildern mal den Rand abschneiden, der verwirrt den Algorithmus nur.

    Das Bild hdr-12.jpg ist auch derart überbelichtet, dass man es streichen kann.

    Bild hdr-6.jpg liefert auch nicht viele Informationen. (Ist bei der "Grösse" aber schwer zu beurteilen.)

    Generell könnten die Wolken etwas wenig Kontrast haben.


    Um wirklich sagen zu können, was los ist, bräuchte man aber das Ausgangsmateriel.


    und ich keine Ahnung habe, welche Werte für die "stonits" zu verwenden sind.

    Haben die jpeg-Dateien wirklich keine Exif-Info integriert?

    So wie ich es verstanden habe wird diese "stonits" üblicherweise daraus generiert. Und mir ist noch keine Kamera untergekommen, die die Exif nicht integriert.


    "stonits" sagt mir zwar nichts, nach der Beschreibung und Einheit (cd/m²) klingt mir das nach Beleuchtungsstärke. Es müsste sich also analog zum Blendenwert, bzw. Belichtungsdauer verhalten.
    Hilft aber auch nicht, wenn man die nötigen Daten nicht hat.


    Ob man mit den "ev"-Werten allein was anfangen kann?

    Eine Erhöhung um 1 EV entspricht einer Halbierung der Lichtmenge, eine Verringerung einer Verdopplung.

    Bei der Korrektur bezieht sich das immer auf die von der Kamera gewählten Werte und wenn man die nicht hat...

    Man hätte immerhin die Verhältnisse der Aufnahmen, da weiss ich aber nicht, ob das reicht.


    Entsprechend angewendet, sehen die Werte vom Pi aber komisch aus. 2^12=4096, das kann eigentlich nicht passen.


    Ich befürchte, man muss wohl alle Werte (Blende, Zeit, ISO, ...) hart vorgeben, wenn man selber rechnen will. Allerdings stelle ich mir das bei wechselnden Lichtverhältnissen schwierig vor.


    Der Raspi kann generell wohl Exif. Es hängt aber wohl von der Aufnahme-Methode ab.

    No Exif information is embedded in JPEG images captured through the video-port.

    Man sollte die Exif-infos in die Bilder zu bekommen, sonst tut man sich bei der Nachbearbeitung echt schwer.

    Da piHDR die "stonits" auch nicht vorgiebt, nehme ich an, dass die da drin sind. Daher ist das, denke ich, der richtige Weg.


    Ich persönlich würde es mit "Hugin" (ein grafisches Frontend zu Panotools) versuchen, mit dem Programm habe ich schon einiges gemacht. Das kann auch Belichtungskorrekturen und HDR und du hast ja quasi eine Panprama-Aufnahmen ohne Bild-Versatz gemacht ;).

    Da ist auch ein Tool zur Linsenkalibrierung dabei. Wenn du Glück hast, reichen die geraden Linien in den Aufnahmen dazu.






    Hmm, wäre es nicht gut, das in einen extra Thread auszulagern?

    Hier kann kls helfen (hat!), aber bei Plugins wird der jeweilige Autor/Maintainer des Plugins gefragt sein, sein Plugin zu checken..

    Grundsätzlich richtig, nur muss man dann erstmal rausfinden welches welches Plugin der Übeltäter ist.

    Da die ganzen Lecks in einem "Topf" landen, hat man erstmal exakt die Probleme wie hier, wenn man versucht das einzugrenzen.

    Ich erinnere mich auch noch wage, dass auch das hier behobene Leck anfangs einem der Ausgabe-Plugins vermutet wurde.


    Den Code zu durchsuchen und zu hoffen, dass man was finden, ist halt nicht besonders effizient. Besonders, wenn man nicht weiss, was und wo man suchen muss.

    Alle Versuche den Fehler erstmal einzukreisen, bevor man etwas ändert oder im Detail sucht, sind am EPG gescheitert.

    IMHO wäre also keine doofe Idee mal zu überlegen, ob man sich zukünftig die Arbeit erleichtern kann.


    Die Idee von M-Reimer mit dem "erzwungenen Aufräumen" erscheint mir Potential zu haben.

    Den VDR in einen ähnlichen Zustand, wie vor dem exit() ist kein grosses Ding, dann hätte man wenigstens einen Ausgangspunkt für Vergleiche.


    Das Chaos, dass das aktuelle Leck im Speicher angerichtet hat, sollte in so einem "aufgeräumten" Zustand auch noch vorhanden gewesen sein.

    Das heisst, man hätte zumindest gesehen, dass da was ist und auch wie viel. Und ich denke, man man hätte auch eine Idee, was es sein könnte und was nicht ist.


    Wenn ich die Zeit finde, werde ich über die Feiertage mal ein bisschen in die Richtung basteln.

    Es ist ja nicht notwendig, im ListGarbageCollector alte cEventszu löschen und dafür in eit.c. immer neue zu erstellen. Diese könnten ja stattdesen aus dem GarbageCollector geholt und wiederverwendet werden.

    Ich weiss nicht, ob sich das lohnt.

    Da sich die Länge der Strings ziemlich sicher ändern wird, gewinnt man nicht viel, befürchte ich.


    Meine Frage war eher deshalb, weil der ListGarbageCollector theoretisch blockieren könnte, wenn sich da viel tut.

    5 Sekunden sind eine schon eine recht lange Zeit, so dass der Timeout mehrfach zurückgesetzt werden könnte. In der Zeit könnte sich einiges im ListGarbageCollector anstauen.

    Dauerhaft wird es wohl nicht bockieren, aber für die Dauer eines EPG-Scan halte ich es für denkbar. Im Worst Case hätte man dann das EPG 2 mal im RAM liegen.

    Bei vielen Kanälen und wenig RAM kann das schon eng werden.


    Ich denke eher daran, eine neue Stable Version 2.6 freizugeben.

    :tup

    Trotzdem möchte ich den Wunsch mach einer finalen, heilen Version 2.4.8 äussern.

    Nicht alle User können (oder wollen) gleich komplett Updaten (mit den Plugins zieht das ja immer so einen Rattenschwanz hinterher). Der eine oder andere wird also noch eine Weile beim 2.4 Zweig bleiben und da wäre es schön, wenn die letzte offizielle Version "abgedichtet" ist.

    Gerade bei diese doch recht "kritischem" Fehler sehe ich sonst gepatchte 2.4.7 Pakete kommen, was für User und Paketbauer nicht wirklich hilfreich ist.

    Auch wenn dieses Leck gefunden ist -übrigens: super Arbeit! :tup- ist das Thema ja noch nicht ganz vom Tisch. Bei einigen Plugins bestand, wenn ich recht erinnere, ja auch der Verdacht.


    Man kann "new" und "delete" überschreiben und dann eigene Logfunktionen bauen, nichts anderes machen sicherlich die Leck-Detektoren.

    Libleak macht das so für malloc, free, calloc, realloc und fork, siehe libleak.c Zeile 680-750.

    Die "Magie" findet in den paar Zeilen statt, der ganze Rest ist nur die Auswertung.

    Was nach LEAK_EXPIRE Sekunden nicht freigegeben wurde, wird als may-leak geloggt.

    Bei sinnvoller Wahl dieser Zeit sollte man kurzfristig benutzte Puffer usw. schon mal aus dem Log haben.

    Blöderweise bleibt beim VDR noch immer viel zu viel drin.


    Das Konzept von Libleak ist eigentlich echt gut, man muss nur überlegen, wie man die ganzen Meldungen bzgl. EPG los wird.

    Möglichkeit 1: Man schaltet das EPG ab. (zB. mittels EPGboarder-Plugin) Das Macht aber nur Sinn, wenn man sicher ist, dass das Leck dann noch Aktiv ist.

    Möglichkeit 2: Man bastelt sich ein Skript, was logdatei von libleak ausmistet.


    Das EPG macht es auch generell so schwierig den Speicherverbrauch einzuschätzen.

    Die Events veralten über den Tag auch und werden weggeräumt. Morgens um 6 auf einen Schlag wieder einen Haufen neue.

    Das erzeugt schon ein imenses Rauschen und der langsame Abfall über den Tag ist tückisch. Ein kleines Leck sieht man so erst nach ein paar Tagen.


    Um das mal weiterzuspinnen: Kann man nicht auch gezielt ein "Wegräumen" erzwingen? Also nur mal angenommen ich lasse einen VDR nur ein paar Stunden laufen mit einem Logging wie oben beschrieben. Wenn das Aufräumen überall sauber läuft, dann sollte bei sauberem Beenden des VDR ja kein einziger Pointer nicht sauber freigegeben worden sein. Andernfalls kann ja was nicht stimmen. Natürlich räumt der Kernel dann den ganzen Prozess weg, aber sauber wäre eben wenn das Programm vor dem Eingreifen vom Kernel alles schon freigegeben hat.

    Gute Idee, das mal soherum zu versuchen.

    Eigentlich sollte doch direkt vor dem endgültigen "exit()" alles aufgeräumt sein, wenn sauber gearbeitet wurde.

    Globale Variablen und wahrscheinlich noch ein paar andere Sachen werden noch noch da, aber alles Speicherintensive, wie Listen und Puffer sollt freigegeben worden sein. Man müsste nur mal schauen, dass man eine gute Stelle erwischt, nicht dass implizt schon was weg geräumt ist, was man noch untersuchen will.

    Man könnte da mal einen Halt einbauen und schauen, wie es da mit dem Speicherverbrauch aussieht. Eigentlich sollte da nicht mehr viel sein, so dass es möglich wird Coredumps zu ziehen und die zu vergleichen.

    Wenn nach ein paar Tagen Laufzeit der Coredump grösstenteils aus "Leck" besteht, gibt das meist wertvolle Hinweise auf die Ursache.


    Ich habe kurz in die Datei reingesehen. VonListGarbageCollector oder Purge habe ich nichts gefunden, nur cSchedules::Cleanup().

    Da erwarte ich auch nicht was zu sehen, die Funktionen reservieren ja keinen Speicher.

    Viele der "frees after expired" dürften aber daher stammen. Da wird aber nicht der Callstack angegeben.



    Verständnisfrage:

    Von dem ListGarbageCollector gibt es doch nur eine Instanz, oder hab ich da was übersehen?

    Wenn dem so ist, könnte man Purge() theoretisch doch blockieren, in dem man jede Sekunde ein ListObject mit Put() rein schiebt?

    Im aktuellen Stand gibt es die Optionen "ja", "nein" und "erlaube leere", letzteres, weil ich es verständlicher fand als die alte Bezeichnung "wenn vorhanden". Aber inhaltlich entspricht es dem ehemaligen Code.

    Sorry, war dann ein Missverständnis meinerseits.


    "wenn vorhanden" habe ich immer als, wenn ein Untertitel gesendet wird zu verstehen.

    AFAIK wurde das damals auch mal so erklärt.


    Funktioniert hat es jedenfalls immer wie erwartet. Ob es das auch in wirklich allen denkbaren Fällen tun würde hab ich aber nicht versucht.

    Die Diskussion ist jetzt, ob es sinnvoll ist, das zu ändern in so was wie "erlaube das eins leer und eins gefüllt ist" oder dies als weitere(?) Option einzubauen.

    Dann würden auch solche Untertitel als gleich beurteilt und kein Timer erzeugt.

    "eins leer und eins gefüllt" Es gibt doch nur einen Untertitel ???


    Oder meint ihr die gleiche Sendung wird einmal mit und einmal ohne Untertitel gesendet?

    In dem Fall macht der Vergleich den Untertitels aber eh keinen Sinn und sollte auf "aus" stehen.

    Wenn der Untertitel nicht zuverlässig ist, hat er keinen Informationsgehalt, sollte also auch nicht verglichen werden. Schon rein logisch.


    "wenn vorhaden" macht Sinn, wenn der Untertitel bei manchen Folgen vorhanden ist, bei anderen nicht.

    Code: Beispiel:
    1. Lieblingsserie                   ~ Folge 17 ~ Unterhaltung, D 2011
    2. Lieblingsserie Weihnachtsspecial ~ __leer__ ~ Unterhaltung, D 2011
    3. [...]
    4. Lieblingsserie                   ~ Folge 17 ~ Unterhaltung, D 2012
    5. Lieblingsserie Weihnachtsspecial ~ __leer__ ~ Unterhaltung, D 2012

    Aktuell ist sowas eher selten geworden, vor ein paar Jahren war sowas bei den Privaten aber durchaus üblich.

    Eine wirklich verlässliche Art, Wiederholungen zu vermeiden, wird es nicht geben, es reicht ja, wenn bei einer Neuausstrahlung im Untertitel eine Jahreszahl dazukommt. Ich denke immer noch, es ist besser Wiederholugen zuzulassen als Aufnahmen zu verpassen.

    Man kann die Erlaubte Abweichung höher drehen, damit kann man einige Fälle noch abfangen.

    Wenn die EPG-Macher zu kreativ werden ist aber irgendwann Schluss.

    Im Zweifelsfall immer lieber aufnehmen als verpassen. Löschen kann man die Aufnahme ja immer.


    Die Sonderfälle Ausstrahlung ohne Untertitel, Aufnahme mit und andersherum, sollten also jeweils zur erneuten Aufnahme führen.

    Ich denke, das war auch immer so, zumindest ist mir da nie ein Fehlverhalten aufgefallen.

    Im obigen Fall mit N24 und N24Doku kann man ja im Suchtimer den Kanal vorgeben.

    Gerade mit beiden Sendern ist das eh so eine Sache.

    Das EPG oft extrem unzuverlässig. Nachts geht es einigermassen, aber tagsüber ist es eine reines Glücksspiel, ob das kommt, was angezeigt wird.

    Dann kürzen die beiden Sender auch gerne mal Sendungen um ein paar Minuten, damit es mit den Nachrichten passt. Primär tritt das auch tagsüber auf.

    Der Zeitversatz in der Ausstrahlung ist anscheinend auch teilweise zu knapp für epgsearch. Vorlauf, Nachlauf und dann noch die Zeit bis zum nächsten Update. Bei mir klappt das oft, aber oft auch nicht.

    Inzwischen hab ich meine entsprechenden Suchtimer nur noch auf Doku laufen und das auch nur in den Nachtstunden. Das Programm ist ja das gleiche und die Sender wiederholen eh alles x fach.

    Ich habe ein paar allocs aus dem libleak-log rausgepickt -> https://pastebin.com/raw/Tsjyp43M Das sind überwiegend reallocs. callstack[2957]z.B. ist da richtig gut dabei. Vielleicht hilfts ja.

    Libleak hatte ich letztes Jahr oder so auch schon mal versucht. Leider bekommt man da alle EPG-Einträge als falsch positiv angezeigt, weil die z.T. eine Lebensdauer von 2Wochen oder sogar mehr haben.


    Für mich sieht es aber aus, als ob die Bereiche korrekt wieder freigegeben werden.

    Das würde ich auch bei den Anderen sagen.

    Allenfalls könnte bei den "components" irgendwo ein Rechenfehler beim Index vorliegen, da sollte nochmal wer anders einen Blick drauf werfen.


    Die Meldungen kannst du IMHO jedenfalls ignorieren und raus filtern, sonst siehst du den Wald vor Bäumen nicht.

    Ich schätze aber, danach bleibt auch noch eine Menge über.


    Ich hatte es damals übrigens anders herum versucht, das EPG zu unterdrücken. Das hat aber nicht wirklich gut geklappt.

    Man könnte noch versuchen den EPG periodisch mittels svdrp "CLRE" zu leeren, so dass die Einträge nicht älter als "LEAK_EXPIRE" werden können. Das hatte ich noch nicht versucht.

    Auf einem Produktiv-System mit EPGsearch ist das halt keine gute Idee und ich habe am Arbeitsplatzrechner leider keinen DVB-Empfang.


    Was mit aber aufgefallen ist, dass hier ganz oft 1byte alloziert wird, auch wenn strlen(ShortText) == 0 ist. Wäre es nicht richtig, es so zu machen, wie hier?

    IMHO ist es legitim leere Strings zu erzeugen.

    Es kann am Ende praktischer sein, einmal sicherzustellen, dass der String existiert, als immer wieder auf Nullpointer abfragen zu müssen.

    Viel Speicher braucht das auch nicht.


    Code
    1. 117 int l = max(dest ? strlen(dest) : 0, strlen(src)) + 1; // don't let the block get smaller!

    Wobei mir eben die Zeile aufgefallen ist:

    strlen(dest) +1 kann doch kleiner sein als der reservierte Block?

    Der Block kann dann doch kleiner werden, aber halt erst beim zweiten Aufruf der Funktion.

    Oder täusche ich mich da?

    Ein Speicherleck ist das aber wohl eher nicht.

    Früher hatte man beim Untertitel die Auswahl zwischen "Ja", "Nein" und "wenn vorhanden". (Ich müsste mich schwer täuschen, wenn dem nicht so war)

    Ich hatte jedenfalls die meisten Timer auf "wenn vorhanden" um Serienspecials ohne Untertitel nur einmal aufzunehmen.

    Das hat auch gut geklappt, bis zu einem Update auf eine Version, wo "Ja" raus geflogen ist und "wenn vorhanden" zu "Ja" wurde :§$%.

    Aktuell stehen alle übrigens alle Untertitel auf "Nein", weil's zu sehr genervt hat.


    Kann man nicht einfach die alte Auswahl "Ja", "Nein" und "wenn vorhanden" wieder herstellen und die aktuellen "wenn vorhanden" zu "Ja" machen?

    Dann ändert sich für den User beim Update nichts und die Bezeichnungen sind wieder logisch.


    Ich sehe übrigens für alle Optionen "Ja", "Nein" und "wenn vorhanden" sinnvolle Anwendung und würde sie wahrscheinlich auch alle nutzen.

    Seit meinen letzten Versuchen zu dem Thema ist mir noch eine Idee gekommen, die ich aus Zeitgründen aber nicht weiter verfolgt habe.


    Mir war aufgefallen, dass (fast?) alle Datenstrukturen im VDR irgendwie von ListObject() erben. Warum nicht einfach da einen Zähler einbauen?

    Im Konstruktor 1 hoch und im Destruktor wieder runter zählen.

    Wenn die Zahl der Instanzen immer weiter hoch läuft, weiss man dass irgendwo vergessen wird erzeugte Datenobjekte wieder zu löschen.

    Wenn nicht, dass man wo anders suchen muss.


    So ganz sicher, ob das wirklich so klappt, bin ich nicht. Ich hatte bislang nur die Idee und es mir noch nicht angesehen.

    Nach Kanalwechsel hin und zurück ist der Empfang ok.

    Gäbe es eine Möglichkeit, das zu erkennen und ein retuning auszuführen?

    Für mich sieht das nach einem abgestützten Decoder aus ein retuning bringt da nicht viel. Dafür aber ein Decoder-Reset.


    Ich würde zum Test mal auf einen anderen Kanal auf dem gleichen Transponder umschalten.

    Da sollte nicht neu getunt werden. Wenn das hilft ist ein retuning unnötig und der Fehler liegt im Ausgabeplugin.



    femon zeigte eine sehr niedrige, ca 5%, Qualität an.

    Normal ist die Besser?

    Es gibt Karten, die da keine sinnvollen Daten liefern.


    Normalerweise ist es Aufgabe des Tuners den Kanal zu halten und nach zu tunen. Wenn das nicht mehr geht, würde ich auf einen schleichenden Hardware-Defekt tippen.

    Als langjähriger EPG-Search User hatte ich schon öfters verhunzte Aufnahmen durch EPG-Fehler. Ganz neu ist das Thema also nicht.

    Wirklich vertrauen tu ich den EPG-Machern jedenfalls nicht mehr.

    Seit ich das EPG von anderen Transpondern ignoriere, ist es insgesamt schonmal besser geworden und die Zahl an abgebrochenen Aufnahmen deutlich gesunken (siehe: Arte EPG verhindert Suchtimeraufnahmen).


    Vor dem Akzeptieren der EPG-Events wäre IMHO ein Test auf Plausibilität ratsam. Primär geht es ja um Überschneidungen, die sollten sich recht einfach finden lassen. Dann ist man sicher, dass das EPG stimmig ist, das würde auch den EPG-Search Usern helfen.

    Ausserdem fallen so alle Fehler auf, nicht nur die, wo zufällig jemand einen Timer gesetzt hat.


    Im aktuellen Fall ist die VPS-Zeit von 23:50 sowieso komisch, üblich ist doch eher vor dem offiziellen Start?

    Wenn man die VPS-Zeit wegen Überlappung auf 23:49 oder besser 23:20 korregiert hätte, wäre das Problem doch nicht aufgetreten, nehme ich an?


    Apropos VPS:

    Komplett falsch gesetzte Running-Flags (oder ist das now and next?) hatte ich auch schon.

    Da war den ganzen Abend eine Sendung vom Vormittag drin und das auch auf einem anderen Receiver.

    Ich habe die DVBSKy S952 (v.2.x und v.3.x) hier am laufen und die Karten sind an sich sehr zuverlässig.


    Den Stromstecker auf der Karte hast du aber doch angeschlossen? Ohne gibt es merkwürdige Empfangsprobleme!


    Ich würde die Ursache eher im PCIe-Passthrough / Virtualisierung suchen.

    Problem ist halt, dass die DVB-Daten in Echtzeit rein kommen und auch von der Karte abgeholt werden müssen. Zudem sind die Puffer auf den Karten oft eher klein.

    Wenn die Interrupt-Verarbeitung etwas zu lange braucht, ist schnell der Puffer auf der Karte übergelaufen. Mehrere DVB-Karten im System verstärken das Problem natürlich noch.

    Das betrifft prinzipiell aber alle DVB-Karten, daher habe ich meine Zweifel, ob ein einfacher Kartentausch wirklich eine Lösung ist.


    Ich weiss nicht, was du schon versucht hast, aber ich würde Richtung Latenz minimierung / realtime / Interrupt-Zuweisung schauen.
    VM-Ware verwende ich zwar nicht, aber auch da sollte sich eigentlich was zu dem Thema finden lassen.

    evtl. testweise mal sie tiefsten CPU-Sleepstates deaktivieren.

    btw.: Was läuft denn sonst noch so alles auf dem Rechner?


    Ansonsten hilft halt die Karten aus dem Server zu verbannen (zB. SATIP) oder auf die Virtualisierung zu verzichten.

    Braucht man trotz Multischalter die Extra-Stromversorgung?

    Ja!

    Ohne die Schaltspannung hast du auch an einem Multischalter nur die vertikalen Kanäle (wenn überhaupt).


    Die LNB-Versorgung hängt ausschliesslich an dem Stecker!

    Afaik auch Teile des Tuners. Ohne Stromstecker geht es bei der Karte jedenfalls nicht!



    Der Stecker ist der übliche 6polige Stomstecker für Grafikkarten. Adapter von 5-1/4" Floppy oder SATA-Stromsteckern hat eigentlich jeder Computerfritze liegen.


    Quote

    DVBSky S952 S2 Twin PCI-e Rev.1.0b mit Chipsatz Montage DS3103/TS2022

    DVBSky S952 S2 Twin PCI-e Rev.2.0a mit Chipsatz Montage M88DS3103

    DVBSky S952 S2 Twin PCI-e Rev.3.0a mit Chipsatz Montage M88RS6000

    Die PCI-Bridge unterscheidet sich auch:

    Rev.1.x und Rev.2x Karten haben die CX23885 von Connexant.

    Rev.3.x Karten haben SM-2032 von Somagic (Chip) bzw. Spin Master Ltd (Treiber).

    Die Rev.3 ist praktisch eine komplett andere Karte.

    Im März 2011 ist diese Option wieder rausgenommen worden, die Option heisst immer noch "If Present", verhält sich aber wie das alte "Yes".

    Ich scheue mich etwas, an der Schraube zu drehen, weil sich wohl die Mehrheit an das Verhalten gewöhnt hat oder es richtig findet.

    Setz den Schlagschrauber an, meine vollste Unterstützung hast du! :]


    Ich hab mich an diese blödsinnige Änderung nie gewöhnen können. So wie es momentan ist, ist die Funktion für mich jedenfalls unbrauchbar und kann nur abgeschaltet bleiben.

    Besonders nervend ist das Verhalten, wenn ab und an Serienspecials kommen, die keine Untertitel haben. Hat bei mir eine ganze Weile gedauert, bis ich raus hatte, was da los ist.

    Die deutsche Beschreibung ist mit "wenn vorhanden" ist IMHO momentan auch völlig irreführend.

    Edit: "vorraussetzen", "erzwingen", "zwingend", "strikt" oder "immer" würden das aktuelle Verhalten eher beschreiben.


    btw.:

    Die Funktion "Timer nach Löschen neuprogrammieren" greift auch für von EPGsearch selbst gelöschte Timer, was IMHO nicht sinnvoll ist.

    Wenn EPGsearch den Timer löscht, dann macht es das aus dem Grund, weil das Event nicht mehr im EPG ist. (Programmänderung, EPG-Ausfall, ...) Wenn das Event wieder auftaucht, sollte der Timer auch wieder gesetzt werden, alles andere macht keinen Sinn.

    Ich hatte mich hier mal an einem Patch versucht, weiss aber nicht, ob das so sinnvoll ist.

    Da das "ö"s in "Die_Höhle_der_Löwen" vorhanden sind halte ich den Zeichensatz als Ursachen für unwahrscheinlich.


    Wie sollte denn der Titel von "P5LLAW~P" eigentlich lauten? Vielleicht bringt einen das auf eine Idee.


    Meine Vermutung ist, dass da eher ein Verzeichnisnahme zu lang geworden ist. Daher das --dirnames

    ... da anscheinend niemand wirklich eine Idee hat.


    Mich erinnern diese Tilden "~" in den Dateinahmen an die langen Dateinamen von Windows 95, wie sie unter DOS aussahen.


    Meine Vermutung daher, dass die Dateinamen zu lang sind, oder da irgendwelche Zeichen drin sind, die zu den Problemen führen.


    VDR-Option --dirnames=250,40,1 (alias --vfat) wäre IMHO einen Versuch wert.

    Wenn ich für Lancom dann allerdings noch ewige Konfig hab, bin ich nicht viel besser dran, als mit OpenWRT.

    Von der Konfiguration finde ich OpenWRT angenehmer und logischer als die Fritzboxen.


    Zum SMS-Send via HTTP empfehle ich einfach mal in deren Forum die Frage zu stellen. Kostet ja nichts und ist schnell gemacht.

    Da wird sicher jemand LTE verwenden und sich besser auskennen als ich DSL-User.

    "Local server" ist korrekt gesetzt?


    Interessant ist, dass hier die Domain mit angehängt ist, obwohl ich die beim nslookup nicht angegeben habe.

    "Expand hosts" macht das, falls aktiviert (Advanced Settings).


    Ist eventuell "All Servers" oder "Strict order" aktiviert? Sollten beide aus sein.


    Die domain 'tvdr.de' ist öffentlich. Das könnte die Ursache sein, warum "Filter private" nicht geht.

    Bei mir OpenWRT 19.7 tritt das Problem nicht auf, allerdings hab ich ein 192.168.x.x Subnetz eingerichtet.