Beiträge von FireFly

Zitat von kfb77

Es geht nicht darum, die Nachkommtstelle so zu bauen, dass sie der VDR korrekt verarbeitet, sondern es darum zu klären, was richtig ist.

Ja, das habe ich versucht zu klären, in meinem http://firefly.vdr-developer.o…ches/marks2bytepos.pl.tgz habe ich das schon vor Ewigkeiten als Frame Number implementiert ohne Probleme zu haben, aber da muss wohl kls mal antworten ....

Zitat von kfb77

1. VDR berechnet mittels dieser Funktion den Time String: 05:58.56

Wo berechnet das VDR? Ich dachte, das hätte Markad in die marks-Datei eingetragen?

Im Deinem ersten Post zeigt er in Zeile 1 ja nur den String an, den er aus der marks-Datei mit cConfig::Load() gelesen hat:

Zitat von kfb77

Aug 31 15:43:20 user.debug VDR-2404-Dev vdr: [430726] cConfig::Load(): DEBUG s 0:05:58.56

und in Zeile 6 gibt dann seinen internen Frame-Index aus, womit die Schnittmarke dann zu 06:00.26 wird

Zitat von kfb77

muss sich aus 9006 wieder 05:58.56 ergeben, oder nicht ?

Nein. Ums nochmal herauszustellen: die .56 sind keine Hunderstel Sekunden, d.h. keine Zeitangabe sondern die Anzahl der Frames !

05:58.56 ist übrigens wegen der ".56" keine "gültige" Schnittmarke, da bei 25 fps die max. Frame Number 24 sein kann (aber wird im VDR trotzdem berechnet).

".56" als Frame Number bedeutet ja 2 ganze Sekunden a 25 Frames + 6 Frames, deshalb gibt der VDR 05:58.56 als 06:00.26 aus

Frame 8964 wäre 0:05:58.14 in der marks Datei.

Probiere doch mal die von Markad berechneten Schnittmarken im VDR OSD zu verschieben und schaue, was dann in der marks-Datei steht für Deine gewünschte Schnittposition ....

Oder Du schreibst keinen Time Code in die marks-Datei sondern die Frame Number, also 8964. So wie ich das im Sourcecode gesehen habe sollte der VDR das auch verarbeiten, dann bliebe Dir die Umrechnung erspart ....

Zitat von kfb77

Quelle ?

Tja, da wird schwierig Ich interpretiere man 5 vdr so:

h:mm:ss.ff comment
   where  hh:mm:ss.ff  is  a  frame  position within the recording, given as "hours, minutes, seconds and (optional) frame number". 

Was ich gerade erst gesehen habe: Es darf in Deiner Berechnung oben demnach nicht heißen: (5*60+58,56)*25 = 8964

sondern: (5*60+58)*25+56 = 9006

Der Punkt ist kein Dezimalpunkt, sondern die Abtrennung für die Frame Number. Der Index, den HMSFtoIndex berechnet, ist die absolute Nummer des Frames innerhalb einer Aufnahme. Bei mir ist die Frame Number bei einem kurzen Check auch überall <50.

Vielleicht hilft die Beschreibung von kls hier weiter: RFC: Frames von 0 zählen

Hmm, nach meinem Verständnis ist f die absolute Anzahl Frames (innerhalb einer Sekunde) und nicht abhängig von der Bildwiederholfrequenz.

Womit setzt Du die Schnittmarken? Manuell mit VDR oder werden die von Markad gesetzt? Wie berechnet Markad die Position?

Zitat von kfb77

wo der Zeit String in die Frame Nummer umgerechnet wird

Das passiert in cMark::Parse(const char *s) in der Funktion HMSFToIndex()

Die Anpassung der Indexposition passiert in cIndexFile::GetClosestIFrame().

IIRC wurde das eingeführt, als die Frameposition nicht mehr bei 1 begann sondern bei 0 um alte marks-Dateien korrekt einlesen zu zu können (ohne Gewähr).

Mit sind bisher keine Unzulänglichkeiten beim Schneiden mit VDR aufgefallen. Sind das bei Dir besondere Aufnahmen? alte oder SD oder von ausländischen Sendern?

Sehr schön. Damit compiliert es wieder und die EPG-Bilder werden auch angezeigt

Ja, ich weiß, deshalb hatte ich die Version oben angegeben. Ich bin mir aber noch nicht im Klaren darüber, was das an Abhängigkeiten für Libraries bedeutet und welche Auswirkungen das haben kann.

Danke, aber mit dem neuesten Stand kompiliert es nicht mehr mit GCC 7.5

C i18n.o
In file included from stringhelpers.h:19:0,
                 from tools.h:24,
                 from live.cpp:10:
to_chars10.h:18:10: fatal error: charconv: Datei oder Verzeichnis nicht gefunden
 #include <charconv>
          ^~~~~~~~~~
compilation terminated.
In file included from stringhelpers.h:19:0,
                 from tools.h:24,
                 from setup.cpp:5:
to_chars10.h:18:10: fatal error: charconv: Datei oder Verzeichnis nicht gefunden
 #include <charconv>
          ^~~~~~~~~~
compilation terminated.

Letzten Samstag gings noch. Da muss ich erst mal schauen, wie ich das beheben kann.

Funktionieren die EPG-Bilder mit ChannelID bei jemandem anderem mit dem aktuellen Stand?

BroadcastSVDRPCommand("UPDR");

Und mit jeder neu gestarteten Aufnahme auf meinem Wohnzimmer-VDR liest der Archiv-Server-VDR wieder alle seine Aufnahmen komplett neu ein obwohl dort keine Änderungen gemacht wurden??

Das wäre kontraproduktiv

Ich nutze live ohne TVscraper und bisher findet live nur EPG-Bilder im Format <eventID>_*, allerdings ist die EventID nur innerhalb eines Kanals eindeutig, so dass u.U falsche Bilder angezeigt werden.

Der angehängte Patch sucht die EPG-Bilder zuerst im Format <channelID>_<eventID>_* und wenn damit nichts gefunden wird fällt er zurück auf die Suche nur mit der Event-ID.

MarkusE: kannst Du den Patch aufnehmen?

Leute, da steht doch:

Zitat von pixelpeter

ERROR: Kernel configuration is invalid

also erst mal nix von vtuner. Und weiter:

Zitat von pixelpeter

include/generated/autoconf.h or include/config/auto.conf are missing.

Run 'make oldconfig && make prepare' on kernel src to fix it.

Hast Du das gemacht? Existiert die include/generated/autoconf.h ?

Zitat von wirbel

Versuchen wir beide das aufzudröseln.. Ich habe das Plugin nicht geschrieben, ich verwalte nur einen fork.

Ja, das hatte ich damals auch gemacht vom Original-Repo für meine Patches.

Zitat von wirbel

Bei Satip sind devices leere Container, denen je nach Bedarf von einem der Server ein 'tuner' zugeordnet wird. Zeitweise oder gar keiner.

Sorry, dass ich zuerst "Tuner" geschrieben hatte, ich meinte diese device-Container.

Und da gab's damals das Problem, dass beim Attach() nach dem device-Container mit benötigten Transponder gesucht wurde, der bei Assign() zugewiesen wurde. Wenn aber der EPG-Scan den gleichen Transponder gerade auf einem anderen device-Container benutzt hatte und das vor dem zugewiesenen device gefunden wurde, dann wurde dieses benutzt und das zugewiesene nie freigegeben so dass irgendwann keine device-Container mehr frei waren. Daher habe ich mich gefragt, ob diese dynamische Zuordnung überhaupt nötig ist und wofür das gut sein soll.

Mein Verdacht war, dass das auch bei dem hier beschrieben Problem von Pixelpeter der Fall war, aber mit dem gemeldeten maximalen Signalpegel ist das ja nicht der Fall. Trotzdem habe ich gelegentlich auch das Problem, dass ein Sender schwarz bleibt oder erst nach mehreren Sekunden hell wird, allerdings mit einem OctopusNet. Da das Problem aber gefühlt nur alle 1-2 Monate auftritt ist es schwer zu debuggen.

Hmm, entweder verstehe ich Dich nicht oder Du verstehst mich nicht. Ich meine das rein SATIP-Plugin intern.

Ich versuchs nochmal anders: Wie erfolgt die Zuordnung der VDR-Devices zu den cSatipFrontend-Objekten innerhalb des SATIP-Plugins? (Alles danach wird vom SATIP-Server dynamisch zugeordnet "as client requests come in", da hat das SATIP-Plugin keinen Einfluss drauf.)

Zitat von wirbel

Weil jeder satip server mit voller Absicht kein definiertes tuner device bereit stellt, sondern das nächste zur Verfügung stehende.

Das ist doch die Verbindung zwischen satip-Plugin und satip-Server, das finde ich ja auch in Ordnung.

Mir ist nicht klar, warum das Satip-Plugin noch eine Zwischenschicht hat mit der Klasse cSatipFrontends. Da wird ja in Matches() geschaut, ob es ein cSatipFrontend gibt, dass bereits den Transponder getuned hat. Warum da nicht einfach eine statische Zuordnung machen der VDR Devices zu den Satip-Plugin-Frontends und die Satip-Plugin-Frontends verbinden sich dann dynamisch mit einen Tuner am Satip-Server.

Zitat von wirbel

1. satip device 0 wird der zweite tuner auf dem server zugeordnet.

Wieso ist das eigentlich keine 1:1 Zuordnung (also satip device 0 -> tuner 1, device 1-> tuner 2 etc)? Welchen Vorteil bringt das?

Der VDR macht ja auch schon eine Zuordnung zu Devices und durch diese Zwischenschicht im satip-Plugin mit Assign/Attach waren die Fehler erst möglich, für die ich damals Patches geschrieben hatte ...

Danke fürs testen, das %llX kommt dann beim nächsten Update ...

Zitat von MartinKG

also bei mir kompiliert es wenn ich folgendes ändere

Danke, damit compiliert es bei mir auch noch. Vermutlich haben sie in neueren libxml2-Versionen etwas an dem typedef von xmlErrorPtr geändert.

Im Git ist ein update, bitte probiert es damit nochmal.

Zitat von nobanzai

Sorry, nicht böse sein, aber langsam verliere ich etwas den Überblick.

Was ist denn nun der Unterschied zwischen tvscraper, scraper2vdr und jetzt xmltv4vdr

Da bin ich Dir gar nicht böse, das ist eine gute Frage, die ich aber auch nicht vollständig beantworten kann.

• xmltv4vdr bekommt die Daten von externen EPG-Anbietern und kann die EPG-Einträge selektiv (Filme/Serien/alle) anreichern
• "TVScraper uses the thetvdb.com API for collecting series metadata and
  themoviedb.org API for movies." (von https://github.com/MarkusEh/vdr-plugin-tvscraper)
• scraper2vdr setzt meines Wissens auf EPGD, das zwischen mehreren VDRs geshared werden kann und bietet zusätzlich noch einen Webserver (was für meine Zwecke aber zu monströs wäre) (RE: scraper2vdr howto ?)

Bitte ergänzen bzw. berichtigen!

Zabrimus: Schaue ich mir an. Welchen Compiler nutzt Du? Mein gcc 7.5.0 meldet nämlich nichts....

Nachdem ich Ende 2018 xmltv2vdr ausprobiert hatte und das bei mir nicht stabil lief, hatte ich angefangen darin einiges zu verbessern. Da das aber nach und nach so viele Änderungen am Code und auch am Konzept waren, habe ich mich irgendwann entschlossen ein neues Plugin daraus zu machen und es xmltv4VDR zu nennen.

Das Plugin xmltv4VDR dient dazu, die vorhandenen EPG-Informationen der Sender mit Bildern und zusätzlichen Informationen im xmltv-Format aus externen Quellen anzureichern.

Das bedeutet auch, dass keine Events hinzugefügt werden sondern nur vorhandene ergänzt werden.

Die Schnittstelle zum Einlesen der externen xmltv-Infos ist gegenüber xmltv2vdr unverändert geblieben, so dass vorhandene Skripte und Verfahren weiter benutzt werden können. Für tvsp2xmltv sind einige Patches dabei, um es auf die aktuellen Gegebenheiten anzupassen.

Zusätzlich können Episoden-Infos von http://www.eplists.de den Events hinzugefügt werden. Die Episodenfiles werden in einem Verzeichnis erwartet (müssen also via Skript geholt werden) und werden vor jedem externen EPG-Update in die Episoden-DB eingelesen.

Weitere Details im README.

Features:

• epgsources Schnittstelle ist gegenüber xmltv2vdr unverändert, d.h. vorhandene Plugins zum Holen der EPG-Infos können weiter verwendet werden
• alle externen Infos (EPG und Episode Files) werden im UTF8-Format verarbeitet
• Serien-Infos von http://www.eplists.de werden optional hinzugefügt
• Serien-Infos werden zusätzlich im XML-Format ins AUX-Feld des EPG Events geschrieben zum einfachen Auslesen durch andere Plugins oder mit Tools (z.B. svdrpsend LSTE)
• selektive Änderung des EPG: es kann für jede EPG-Komponente ausgewählt werden, für welche Sendungsart die externe Info übernommen werden soll:
  • keine
  • nur Filme
  • nur Serien
  • nur Filme & Serien
  • alle

Sowohl die Zuordnung der externen Events als auch der Serieninfos aus eplists zu den VDR-Events ist abhängig von der Qualität der Daten, d.h. wenn Title und Shorttext einer Sendung (Event) zu sehr abweichen, dann ist keine Zuordnung mehr möglich und somit keine 100-prozentige Trefferquote erreichbar.

Downloadseite: https://github.com/FireFlyVDR/vdr-plugin-xmltv4vdr

aktuelle Version: 0.4.3-Beta

FireFly

Zitat von nobanzai

Ich bin mir an der Stelle nicht sicher, wie epgsearch arbeitet.

Wenn man %variable% verwendet, müsste er doch die Variable im Verzeichnisnamen ersetzen, sobald die Info da ist, oder? Irgendwo habe ich das mal gelesen, meine ich.

Aus epgsearch MANUAL:

Calling a system command
      You can call external commands. The returned string will be assigned to a variable
              %uservar%=system(scriptname[, parameters])
      Calls the script "scriptname" with the parameters defined in the optional list of 'parameters'. This can be an arbitrary expression containing other users, but not again a system call or a conditional expression.


      Sample:
              %myVar%=system(/usr/local/bin/myscript.sh, -t %title% -s %subtitle% -u %myOtherVar%)
      The script must return a string without line break!

      If the script returns nothing, an empty string will be assigned to the  e %Result%.

Calling a TCP service
      You can call a TCP service with the following syntax:
               %uservar%=connect(<addr>, <port>, [<data>])
      This will connect to <addr> through the given port and pass the optional given data. <addr> can be an IP address or the domain name of
      the TCP service. The result returned by the service must be terminated with a line feed

Habe ich aber noch nie benutzt