Jump to content

Kodi Frontend Thumbnail Erzeugung


janee

Recommended Posts

Hallo,

ich nutze für mein FireTV Kodi als Frontend. Als Backend arbeitet der aktuelle DMS.

Nun ist es so, das beim Livestreaming der DMS die Erzeugung von Thumbnails anstösst und das immer und immer wieder. Das erzeugt eine enorm hohe HDD Last.

Hier der Auszug des Logfiles. Ich vermute ein fehlerhaftes anstossen der Thumbnail Erzeugung.

Hier wurde das Problem schon einmal geschildert.

02.08.17 18:43:16.857 TStreamManager       GetDocument      Kodi/17.3 (Linux; Android 5.1.1; AFTB Build/LVY48F) Android/5.1.1 Sys_CPU/armv7l App_Bitness/32 Version/17.3-Git:20170524-147cec4
02.08.17 18:43:16.857 TStreamManager       GetDocument      c:\wwwroot\upnp\channelstream\0.ts
02.08.17 18:43:16.858 TRecordingEngine     AddReference     TStreamClient: 2
02.08.17 18:43:16.860 TLiveStream          AllocateHardware RTSP Network Device 4
02.08.17 18:43:16.860 TRTSPNetworkStream   SetTuner         TType: 1, Freq: 11494, Symrate: 22000, LOF: 9750, Tone: 0, Pol: 0, DiseqC: 0, FEC: 2, APID: 5102, VPID: 5101, PMT: 5100, SID: 10301, TID: 1019, NID: 1, SatMod: 134, DiseqCVal: 0, Flags: 24
02.08.17 18:43:27.562 CreateThumbs         WM_COPYDATA
02.08.17 18:43:27.562 CreateThumbs         success
02.08.17 18:43:27.566 CreateThumbs         WM_COPYDATA
02.08.17 18:43:27.566 CreateThumbs         success
02.08.17 18:43:27.579 CreateThumbs         WM_COPYDATA
02.08.17 18:43:27.579 CreateThumbs         success

 

Link to comment
7 hours ago, janee said:

Nun ist es so, das beim Livestreaming der DMS die Erzeugung von Thumbnails anstösst und das immer und immer wieder.

 

Woraus schließt du das? Für den Zusammenhang mit Live Streaming sehe ich keine Anhaltspunkte.

 

Vorschaubilder werden für Aufnahmen und Videos erzeugt, z.B. wenn ein Webinterface eine Aufnahmenliste anzeigt oder ein Client /api/mediafiles.html mit dem Parameter thumbs=1 verwendet, um sich über die vorhandenen Videodateien zu informieren. Dann produziert der DMS vorsorglich für alle abgefragten Videos Vorschaubilder, legt sie im Konfigurationsordner\Images\Thumbs\Recordings\ ab und informiert den Client darüber, wie er sie abrufen kann. Jeweils eine kleine Version (*_SM.jpg) und eine winzige Version (*_TN.jpg). Schaue in dem genannten Verzeichnis mal nach.

 

Wenn der Client die gesamte Videosammlung abfragt, macht der DMS das für alle Videos. Aber nur einmal. Wenn die Vorschaubilder bereits vorhanden sind, nicht mehr, d.h. dann sollte es auch nicht mehr zu Log-Einträgen der obigen Art kommen. Eine ständige Wiederholung könnte ich mir höchstens vorstellen, wenn vthumbs.exe immer wieder daran scheitert, die Bilder zu erzeugen bzw. zu speichern. Oder falls irgendjemand oder irgendwas immer wieder das Verzeichnis löscht.

Link to comment

P.S. Ich habe noch einen API-Aufruf gefunden, der zur Erzeugung von Vorschaubildern für Aufnahmen führt. Den kannst du mal selbst im Browser auf dem Server-PC probieren (vorausgesetzt der Webserver-Port ist 8089, sonst musst du die URL anpassen):

 

http://127.0.0.1:8089/api/recordings.html?images=1

 

Das sollte dir sämtliche Aufnahmen als XML aufzählen, mitsamt den dazugehörigen Vorschaubild-Dateien. Und die Vorschaubilder erzeugen, sofern noch nicht vorhanden. Schaue danach mal ins svcdebug.log.

 

Ich habe hier zumindest einen Fall gefunden, in dem der Aufruf CreateThumbs scheitert und deshalb bei jedem API-Aufruf wiederholt wird: Eine Radioaufnahme. Der Fall ist überhaupt nicht berücksichtigt. Der DMS gibt dem Client hier sogar eine nicht existierende Vorschaubild-Datei an. Lars als Video-Fan konnte sich vermutlich nicht vorstellen, dass jemand sowas abwegiges macht wie Radio aufnehmen...

Link to comment

Hallo Griga,

ich habe das LOG gerade nicht zur Hand.

Meine externe Festplatte, wo einige Aufnahmen draufliegen, ist zur Zeit nicht am Rechner. Da heißt, einige Aufnahmen sind "Missing".

 

vor 11 Minuten schrieb Griga:

http://127.0.0.1:8089/api/recordings.html?images=1

Im Code vom Kodi Addon steht

bool Dvb::GetRecordings(ADDON_HANDLE handle)
{
  CLockObject lock(m_mutex);
  httpResponse &&res = GetHttpXML(BuildURL("api/recordings.html?utf8=1"
      "&images=1"));
  if (res.error)
  {
    SetConnectionState(PVR_CONNECTION_STATE_SERVER_UNREACHABLE);
    return false;
}

 

vor 12 Minuten schrieb Griga:

Das sollte dir sämtliche Aufnahmen als XML aufzählen, mitsamt den dazugehörigen Vorschaubild-Dateien. Und die Vorschaubilder erzeugen, sofern noch nicht vorhanden.

 

Kann das das Problem sein? Also die Gerade nicht verfügbaren Aufnahmen (da HDD nicht aktiv) + der Aufruf????

Link to comment

Kann sein, wenn die nicht verfügbaren Aufnahmen in der Aufnahme-Datenbank stehen und noch keine Vorschaubilder erzeugt wurden. Soweit ich sehen kann, wird bei dem Vorgang nirgendwo überprüft, ob die Aufnahme als Datei existiert. Das merkt dann erst vthumbs.exe, nachdem es gestartet wurde.

 

Mit dem Bereich habe ich mich bislang noch nicht befasst. Da scheint es einen gewissen Korrekturbedarf zu geben ;)

Link to comment

Wenn ich helfen kann, mache ich das gern.

Ich werde heute abend nochmal ein paar logs erzeugen und hier anheften.

 

Normalerweise läuft ja ein automatismus, der zyklisch auf neue Inhalte prüft und die Thumbs dann erzeugt. 

Das heißt ja auch, dass die Last auf dem System überschaubar bleibt.

In diesem Fall ist die Last schon beträchtlich (FFMPEG Prozess beansprucht die HDD zu 100% (200+x MB/s)) über den gesamten Zeitraum.

 

vor 15 Minuten schrieb Griga:

wenn die nicht verfügbaren Aufnahmen in der Aufnahme-Datenbank stehen und noch keine Vorschaubilder erzeugt wurden.

Die Vorschaubilder sollten aber schon erzeugt worden sein. Ich checke das später noch einmal.

Link to comment
1 hour ago, janee said:

In diesem Fall ist die Last schon beträchtlich (FFMPEG Prozess beansprucht die HDD zu 100% (200+x MB/s)) über den gesamten Zeitraum.

 

...wobei unwahrscheinlich ist, dass der Versuch, nicht verfügbare Aufnahmen zu bearbeiten, die CPU so beansprucht. Demnach müsste es noch etwas anderes sein, das eine ständige Neuerzeugung der Vorschaubilder verursacht.

 

Mit den Informationen, die du jetzt hast, ist es hoffentlich zu ermitteln.

 

Link to comment
vor 10 Stunden schrieb Griga:

http://127.0.0.1:8089/api/recordings.html?images=1

 So, ich habe mir die Sache nochmals genauer angesehen. Mit diesem Aufruf wird auch jedes mal ein die Thumbnailerstellung aufgerufen. Im Konfigurationsverzeichnis gibt es jedoch eine entsprechende LOG Datei. (thmbdebug.log) Diese habe ich mir dann angesehen und immer die selben Aufnahmen (es waren einige wenige) darin entdeckt. Die Aufnahmen sind defekt und somit kann kein Thumnail erstellt werden. Das heißt aber auch, dass bei jeden API Aufruf (und wer weiß wie oft das Kodi Frontend das macht) die Thumbnailerstellung gestartet wird.

Die hohe Festplattenlast wird erzeugt, wenn ffmpeg ein verwertbare Position in der Aufnahme sucht.

 

Könnte man bei solchen Fällen nicht ein Standardthumbnail hinterlegen?

 

 

 

 

 

 

Link to comment

Ohne mich mit dem Thema intensiv beschäftigt zu haben sollte man sich vielleicht aber erstmal überlegen wie man den Ablauf rund um Erstellung, Bereitstellung und Abruf durch den Client der Vorschaubilder sinnvoll organisiert? 

 

Mit dem o.a. API Abruf schickt der Client den DMS doch jedes Mal auf die große Reise durch alle Aufnahmeverzeichnisse um festszustellen ob Vorschaubilder vorhanden oder? 

Link to comment
2 hours ago, janee said:

Mit diesem Aufruf wird auch jedes mal ein die Thumbnailerstellung aufgerufen. Im Konfigurationsverzeichnis gibt es jedoch eine entsprechende LOG Datei. (thmbdebug.log)

 

Stimmt. Die kannte ich noch gar nicht :blink: Gut recherchiert. Das ist hilfreich.

 

2 hours ago, janee said:

Könnte man bei solchen Fällen nicht ein Standardthumbnail hinterlegen?

 

Das Problem bei der Sache ist, dass die Erzeugung von Vorschaubildern asynchron in einem anderen Prozess stattfindet. D.h. wenn der DMS die Erzeugung via vthumbs.exe anstößt, erfährt er nicht das Ergebnis. Das liegt erst zu einem undefinierten späteren Zeitpunkt vor.  Der DMS könnte solch ein Standard-Bild prophylaktisch speichern, bevor er ffmpeg via vthumbs.exe beauftragt, und dann wird es überschrieben oder auch nicht...  wäre zu probieren, ob das geht. Effizient ist diese Vorgehensweise jedoch nicht gerade ;)

 

vthumbs.exe stammt von Lars. Christian hat mir vor einiger Zeit den Quellcode zugeschickt, aber es weiß keiner so genau, ob der wirklich aktuell ist und der Binary entspricht, die mit dem RS/DMS ausgeliefert wird. Das kommt noch hinzu.

 

Über die Sache muss ich jetzt erst mal nachdenken....

 

2 hours ago, nuts said:

Mit dem o.a. API Abruf schickt der Client den DMS doch jedes Mal auf die große Reise durch alle Aufnahmeverzeichnisse um festszustellen ob Vorschaubilder vorhanden oder? 

 

Hä? Die Vorschaubilder liegen doch nicht in den Aufnahmeverzeichnissen. Wo sie sich befinden, habe ich bereits erläutert.

 

Link to comment

Die Thumbs könntest du doch mit in die Sqlite Datenbank legen, ähnlich der Logos. Ist effizient und relativ flott bei Abfragen etc.

Nur so ein Gedanke ...

 

Link to comment

Das musst du näher erläutern. Erstens wüsste ich nicht, das irgendwo Logos in einer SQLite-Datenbank liegen, und zweitens wie willst du ffmpeg dazu bringen, Vorschaubilder dort abzulegen?

 

Um die Tatsache, dass ein asynchroner Prozess Vorschaubilder mit gegebenem Pfad und Dateinamen auf der Festplatte ablegt, kommst du nicht herum. Das Problem ist, wie man verhindert, dass erfolglose Versuche ständig wiederholt werden. Legt man dafür ein separates Gedächtnis an (z.B. ein Flag "Vorschaubilderzeugung bereits probiert" in der Datenbank), ist die nächste Frage, wie man dieses Gedächtnis mit dem tatsächlichen Festplatteninhalt synchron hält. Ein Anwender, der das Verzeichnis löscht, um alte nicht mehr benötigte Bilder loszuwerden und eine Neu-Erzeugung zu erzwingen, wäre sicher nicht erfreut, wenn diese unterbleibt, weil in der Datenbank steht, dass es die Bilder bereits gibt.

 

Link to comment
1 hour ago, Griga said:

Erstens wüsste ich nicht, das irgendwo Logos in einer SQLite-Datenbank liegen

 

Jetzt weiß ich es :) Gerade gefunden: Logos.db3. Laut Code landen dort alle Bildchen, die Clients in einer bestimmten Größe anfordern, so dass sie der DMS nicht direkt von der Festplatte liefern kann, sondern mit GDI+ umskalieren muss. In diesem Fall ist das kein ausgelagerter asynchroner Prozess, sondern findet innerhalb der Routine statt, die die Anforderung des Clients bearbeitet. Der muss also warten, bis das Bild vorliegt. Lars hat dort eine optionales Performance-Logging eingebaut, wahrscheinlich um herauszufinden, ob es schneller geht, in der Datenbank gecachte Bilder zu liefern oder sie on-the-fly zu produzieren.

 

Seit 4 Jahren betreue ich jetzt den RS/DMS und treffe immer noch auf Bereiche, von denen ich noch nie gehört habe :wacko:

 

Link to comment

Ich meinte mit "großer Reise" den Vorgang bei dem der DMS überprüft ob für eine Aufnahme ein Vorschaubild existiert. Das muss bei jedem API Abruf erfolgen, da sonst ja bei Bedarf keine neuen erstellt werden könnten. 

Oder wird dazu einfach die SQLite Datenbank abgefragt? 

 

Die Bilder direkt in der SQLite Datenbank zu speichern wäre sicher möglich (ffmepg erstellt Datei auf der Festplatte und anschließend die Datei in die Datenbank schreiben, Datei wieder löschen, ggf. geht das auch ohne den Zwischenschritt des Datei speichern). Aber ob das wirklich besser ist?

Edited by nuts
Link to comment
vor 6 Stunden schrieb Griga:

Jetzt weiß ich es :) Gerade gefunden: Logos.db3.

Ja die DB meinte ich :original:

 

vor 8 Stunden schrieb janee:

Ist effizient und relativ flott bei Abfragen etc.

 

Ist nur eine Vermutung von mir. Das müsste man natürlich erst einmal abklopfen.

 

vor 6 Stunden schrieb nuts:

Die Bilder direkt in der SQLite Datenbank zu speichern wäre sicher möglich (ffmepg erstellt Datei auf der Festplatte und anschließend die Datei in die Datenbank schreiben, Datei wieder löschen, ggf. geht das auch ohne den Zwischenschritt des Datei speichern). Aber ob das wirklich besser ist?

 

Zumindest ein Flag wie "Vorschaubild ist erstellt" wäre für das Einsammeln der Informationen schon sinnvoll.

So kann der DMS relativ einfach feststellen, was noch erstellt werden muss und was schon vorhanden ist, ohne erst einmal auf Dateiebene zu schauen.

Link to comment
8 hours ago, nuts said:

Die Bilder direkt in der SQLite Datenbank zu speichern wäre sicher möglich (ffmepg erstellt Datei auf der Festplatte und anschließend die Datei in die Datenbank schreiben, Datei wieder löschen, ggf. geht das auch ohne den Zwischenschritt des Datei speichern). Aber ob das wirklich besser ist?

 

Illusorisch. Ist euch nicht klar, was "asynchroner Prozess" bedeutet? Der DMS weiß nicht, ab wann ein Bild verfügbar ist und ob überhaupt. Die Erzeugung der Aufnahmeliste für Clients geht in Millisekunden über die Bühne. Die daraus resultierenden Aufträge für die Vorschaubilderzeugung (das können 100 Stück oder mehr sein) werden von  vthumbs.exe gecached und dann nach und nach an ffmpeg delegiert (der Start von 100 FFmpeg Instanzen quasi gleichzeitig würde vermutlich nicht auf Begeisterung stoßen...)   Das läuft vollkommen unkoordiniert mit Vorgängen im DMS ab und kann sich über eine längere Zeit hinziehen. Um herauszufinden, ob und wann ein Vorschaubild fertig ist, wäre ein erheblicher Aufwand im DMS nötig, nämlich ein Hintergrundthread, der periodisch durch Festplattenzugriffe feststellt, welche beauftragten Bilder schon auf der Platte vorliegen.

 

Quote

Zumindest ein Flag wie "Vorschaubild ist erstellt" wäre für das Einsammeln der Informationen schon sinnvoll.

 

Trifft auf das gleiche Problem. "Vorschaubilderstellung wurde versucht" wäre denkbar - das ist nämlich das einzige, was der DMS mit Sicherheit weiß, ohne ständig (!) auf der Festplatte nachzuschauen. Mit welchem Problem das wiederum verbunden ist, habe ich bereits beschrieben.

 

Link to comment
vor 44 Minuten schrieb Griga:

Um herauszufinden, ob und wann ein Vorschaubild fertig ist, wäre ein erheblicher Aufwand im DMS nötig, nämlich ein Hintergrundthread, der periodisch durch Festplattenzugriffe feststellt, welche beauftragten Bilder schon auf der Platte vorliegen.

 

... oder vthumbs.exe signalisiert den DMS das er fertig ist (z.B. über die API, IPC ...) da kann man das Ergebnis sogar schon mit übertragen. Die Technik hat der DMS doch schon.

 

Link to comment
2 hours ago, janee said:

.. oder vthumbs.exe signalisiert den DMS das er fertig ist

 

Die Frage ist eher, wann FFmpeg fertig ist. vthumbs.exe macht die Vorschaubilder ja nicht.

 

Wie auch immer, alles, was mir bislang dazu einfällt, erfordert einen mehr oder weniger großen Umbau, den ich gerne vermeiden möchte, denn das muss dann alles wieder in verschiedenen Szenarien getestet werden, neue Bugs müssen gefunden und behoben werden usw., das kostet tierisch viel Zeit.

Link to comment

Ich würde vorgeschlagen den Prozess des Erzeugens von fehlenden Vorschaubildern so wenig wie möglich durchzuführen.

 

Für eine fertige Aufnahme möglichst direkt nach der Aufnahme versuchen ein Vorschaubild anzulegen.

Ansonsten wäre der Vorgang etwas für einen Prozesstask der vom Benutzer gestartet werden kann oder/und eine periodische Aktivität wie das automatische EPG Update.

Link to comment
8 minutes ago, nuts said:

Für eine fertige Aufnahme möglichst direkt nach der Aufnahme versuchen ein Vorschaubild anzulegen.

 

Wird bereits gemacht, sofern man den Timer nicht per Hand stoppt.

Link to comment

Der wird ja auch nicht wiederholt. Außer für Bilder, deren Erzeugung scheitert. Das Problem ist, wie der der DMS das mitkriegen und sich merken soll. Ich versuche erst mal, die Fälle auszusieben, bei denen es vorhersehbar scheitert, also insbesondere Radioaufnahmen. Der DMS ist in der Hinsicht schlecht organisiert. Es ist der Datenbank nicht eindeutig zu entnehmen, ob es sich um eine TV- oder Radio-Aufnahme handelt.

 

Abfragen, ob Vorschaubild-Dateien bereits auf der Festplatte existieren, sind unerheblich. Das erfordert normalerweise nur einen Festplattenzugriff, danach hat Windows das Inhaltsverzeichnis des Ordners für Folgeabfragen im Cache.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...