Beiträge von kfb77

Zitat von kls

ohne irgendwelche Plugins, die da mitmischen

markad mischt nicht mit, sondern schaut nur zu.

Ich logge nur die VPS Events um sie später ggf. als Schnitt Information zu verwenden. Ich ändere aber nie was an den Events.

Ja, hat sich geklärt und ich habe es in markad gefixed.

Trotzdem schön, wieder wieder ein Lebenszeichen von dir zu lesen.

Zitat von g3joker

Muss die Raute vor dem Channellogo_languages nicht auch weg?

nicht nur das, die Einrückung von "-de" muss bleiben.

channellogo_languages:
# - au
# - be
# - cz
  - de

Zitat von Taipan

Kannst Du da einen Blitzschutz empfehlen?

Sorry, keine eigene Erfahrung, habe kein Gartenhaus und ich würde Outdoor auch nie Kupfer machen. Suche einfach mal bei einem Online Händler deiner Wahl danach.

Den Vorschlag von M-Reimer finde ich gut, damit habe ich auch meine Terrasse mit WLAN versorgt. Und wenn das Gartenhaus nicht sehr weit weg ist, ist das dafür auch eine simple Lösung.

Und wenn es kein WLAN (oder besser gleich LWL) sein soll: Ich gehe mal davon aus, dass das Gartenhaus keine eigene Stromversorgung und Erdung hat (also über das Haupthaus angebunden ist). Falls doch, auf keinen Fall mit Kupfer verbinden.

Ein Außenkabel wird gerne zum Problemfall: Wasser dringt ins Kabel ein, Tiere beißen es auf, brüchig werden durch UV, ...

Hoffentlich nicht so lang, weil dann wäre auch noch Blitzschutz und Potentialausgleich ein Thema.

Oder WLAN Bridge oder gleich LWL.

Die Version 3.3.5 von vdr-plugin-markad ist verfügbar.

2023-08-23: Version 3.3.5
- additional compare channelID for VDR VPS events, thx to MarkusE@vdr-portal.de for reporting and testing
- fix broken build with gcc 4.8 (easyVDR3, yavdr0.6)
- tune thresholds for black screen, silence and scene change optimization
- some minor bug fixes and optimizations, see git

MarkusE : Vielen Dank für das unermüdliche Testen der VDR VPS Events im markad Plugin. Da ich epg2vdr einsetze, bekomme ich die Probleme damit nicht mit. Bitte vor dem bauen in der Datei plugin/debug.h den Kommentar vor "#define DEBUG_DUP_EVENTID" entfernen, dann ist die besprochene Syslog Meldung wieder drin.

Außerdem baut markad wieder unter Ubuntu 14.04. Ich vermute, das wollte CKone hier anmerken. Nochmal zur Erinnerung: Ich teste nicht mehr unter Ubuntu 14.04, bearbeite aber noch bis April 2024 (EOL Ubuntu 14.04) hier im Forum gemeldete Probleme.

Hast du inzwischen o.g. Syslog Meldung bekommen ?

Das Thema lässt sich sicher sehr schwer reproduzieren, aber ich übernehme das mal so in die nächste Version.

Zitat von davie2000

Diese DLAN-Teile bauen doch eigentlich rund um das Elektrokabel ein WLAN auf

Nein, die verwendeten Frequenzen sind viel niedriger (max. 68 MHz). Das Übertragungsverfahren ist eher mit dem von DSL vergleichbar. Darum stört es ja auch oft die DSL Anbindung.

Zur eigentlichen Frage: Die Datenübertragung geht über nicht abgeschirmte Stromleitungen, das kann (muss aber nicht) alles mögliche stören.

Werfe sie mal ins Wasser, vielleicht geht sie dann wieder.

Jetzt bin ich aber neugierig, mit welchem Compiler geht es denn nicht ? Unter Ubuntu geht es "mit dem was so dabei ist", ab 14.04.

Bei den EIT Events war mir klar, dass die nur pro Kanal eindeutig sind, da prüfe ich schon immer auch den Kanal.

Bei den Events vom VDR dachte ich, die sind eindeutig. Und es ist mir nie aufgefallen, da ich epg2vdr nutze und somit eh keine VDR VPS Events bekomme.

Bitte mal mit dem Branch eventID testen, da wird jetzt auch bei VDR VPS Events zusätzlich der Kanal geprüft.

Es ist in dieser Version eine zusätzliche Debug Meldung aktiv. Bitte auf syslog Meldungen "markad: StatusMarkAd::FindRecording(): duplicate eventID ..." achten, dann wurde auf einem anderen Kanal die gleiche eventID gefunden. Die Meldung kommt dann in der finalen Version wieder raus, ich möchte nur mal sehen, wie oft das vorkommt.

Zitat von MarkusE

Doch, die Event IDs sind nur innerhalb eines Kanals eindeutig.

OMG, dann liegt es daran. Dann muss ich auch den Kanal noch vergleichen.

Ich habe mal die Log Files mit hier verglichen, das ist das gleiche Problem.

Also wohl doch keine Race Condition, weil der Lock ist jetzt ja ganz am Anfang vom Handler Aufruf.

Keine Ahnung, wo der Event erfunden wird. Es kann ja wohl nicht sein, dass EventIDs mehrfach vorkommen.

kls oder ?

Bitte mal mit dem Branch VPS den Fehler versuchen zu reproduzieren. Damit werden alle VPS Stop Events mit Kanal und Titel ins Syslog geschrieben. Dann werden wir ja sehen, zu welcher Sendung der Event gehört. Ich befürchte, das reproduzieren wird nicht einfach werden.

Die Version 3.3.4 von vdr-plugin-markad ist verfügbar.

2023-08-11: Version 3.3.4
- tune thresholds for black screen, silence and scene change optimization
- replace deprecated AVFrame::interlaced_frame with AV_FRAME_FLAG_INTERLACED for FFmpeg 6
- performance optimization: prevent multiple index scans for same mark position
- some minor bug fixes and optimizations, see git

[mpegts @ 0x5587c691fec0] PES packet size mismatch
[mpegts @ 0x5587c691fec0] Packet corrupt (stream = 1, dts = 4534808530).
[mpegts @ 0x5587c691fec0] PES packet size mismatch
[mpegts @ 0x5587c691fec0] Packet corrupt (stream = 2, dts = 4534805477).

Die habe ich auch. Bei ein paar Stichproblem ist es immer genau an einer Stelle in beiden Audio Streams. Das kann aber wohl nichts mit dem Video Problem zu tun haben.

Ich nutze das, um einen Plan B für den Start der Sendung zur haben, falls ich keine anderen Kriterien finde. Vor allen bei den ÖR kommt es oft vor, dass das Logo durchgehend bleibt.

Ich werde erst mit Start der Aufnahme aufgerufen. Wenn ich da sofort Event 4 vorfinde, gibt es zwei Möglichkeiten (egal ob VPS Timer oder ohne):

1. Aufnahme wurde zu spät gestartet und läuft bereits. In diesem Fall darf ich kein Start weg schreiben, da er ja verpasst wurde.

2. Sender sendet kein Event 1 oder 2 vor Event 4. VDR hat eben bei Event 4 gestartet, statt wie sonst bei Event 2. In dem Fall könnte ich den Aufnahmestart weg schreiben.

Ich habe aber aktuell keine Idee, wie ich die beiden Fälle sicher unterscheiden könnte, somit ist die aktuelle Strategie, in dem Fall lieber nichts wegzuschreiben, als was falsches.

Denkbar wäre, zwei neue Felder RECODRINGSTART und RECORDINGEND, dass du als Plan B nehmen könntest. Würde dir das helfen ?

Das Bild, das du aus Wiki zitiert hast, ist ja auch nur verwirrend.

Wenn die Quelle Frame A dann B hat, wird ja A first und B second übertragen und es kommt A/B zeilenweise gemischt raus.

Oder nicht ?

Nochmal nachlesen hilft: sorry for the noise, ihr habt Recht.

Auch das bezweifle ich. Es kommen immer die beiden Halbbilder eines Vollbildes nacheinander, dann die beiden Halbbildes des nächsten Vollbildes. Die Technik stammt von 1920, das gab es keine Intelligenz, die die Bilder wieder sortieren hätte können. Der Deinterlacer war die Trägheit der Bildschirmröhre.