ich arbeite gerade daran, den Suchindex zu erweitern. Elasticsearch leistet für die Performance gewaltige Dienste
Ich hab die Tage die Kapitelmarken in den Index gebracht, sodass eine Suche auch diese umfasst. Das war auch schon vorher in der MariaDB so, aber da war’s halt… langsam
Wie auch immer: Das klappt aktuell leider nur mit den Kapitel, die per Podlove Simple Chapters im Feed stehen. Ich würde das gerne auf die Kapitel erweitern, die auch in den Audiodateien stecken, aber das ist etwas problematischer.
Was ich aktuell brauche, um den Prozess zu schärfen: Möglichst viele Beispiele von MP3-Dateien, die Kapitel beinhalten. Ich sag Euch auch warum:
Würde ich die komplette Datei einer Folge herunterladen, würde das den Traffic, den ich generiere ziemlich gewaltig ausufern lassen. Ich tippe auf 20 bis 30 TB im Monat. Das ist aber nicht nötig. Der @ePirat hat mich auf die richtige Spur gebracht: Es reichen ja die ersten paar X KByte einer MP3, um die Kapitel auszulesen, denn die ID3-Tags sollten vorne stehen. Wie groß aber X ist, das müsste ich austesten. Und dafür brauche ich Eure Dateien.
Wenn also ausgerechnet DU mir helfen kannst, weil Deine MP3 Kapitelmarken beinhalten, dann würde ich mich über folgendes freuen (in aufsteigender Reihenfolge des Freuens)
a) Podcasttitel
b) Episoden-IDs bei fyyd
c) URLs der Episoden
Damit kannste zielgerichtet auslesen, wieviel Du von nem MP3 mit MP3-Chaptern Du herunterladen musst. Der ID3-Tag-Standard hat da lauter Infos zu, wie lang das Tag ist und wo was zu finden ist.
Lohnt sich mal reinzuschnuppern
Danke, aber die Specs hab ich ja. Überraschung ist halt, dass es (für z.B. ffmpeg) nicht reicht, gerade genug zu holen, damit die Kapitel im Download sind. Sieht so aus, als ob die zumindest einen Teil des MP3 brauchen, um das Zeug richtig einzulesen.
Nun hab ich zwei Möglichkeiten:
Selbst schreiben und halt nur die ersten paar KByte holen oder
rausfinden, wieviel zB ffmpeg braucht
Punkt eins ist Arbeit, hilft aber Traffic zu sparen. Blöderweise muss ich dann aber für unterschiedliche Dateiformate unterschiedliche Programme warten/schreiben
Punkt zwei produziert im Zweifel mehr Traffic, ist aber einfacher einzusetzen und zu warten.
Da hab ich das Problem mit den Beispieldateien nicht, die hab ich selbst im Dutzend billiger hier rumliegen. Kapitel will ich aus allen Dateien herauslesen, in denen ich welche finden kann.
So, vielen Dank, auch wenn’s nicht so viele waren, hat es vermutlich dennoch gereicht.
Erkenntnis: Das will ich nicht selbst machen. ffmpeg (ffprobe) ist hier eine große Hilfe und die wissen, was sie tun.
Die Formate und Programme lassen es leider auch nicht zu, dass ich nur die ersten paar KByte runterlade. ffprobe macht zumindest einen Check, ob die Daten wirklich da sind und verweigert die Mitarbeit, wenn das zu sehr abgeschnitten wird.
Es sollten aber, vorbehaltlich weiterer Tests, in allen Fällen ein MByte reichen, um die Kapitel zu bekommen und damit kann ich leben. Im Mai kamen knapp 62000 Episoden in die Datenbank hinein, das wären dann also was um die 60GByte im Monat. G’schissen
Interessant ist, dass es mir mit den naheliegenden Suchbegriffen nicht möglich war, einer Suchmaschine Informationen über die Details der Kapitelformate bei mp4 zu finden. Vielleicht stelle ich mich doof an, aber das war schmerzhaft. Für mp3 war’s nicht besser
Ich bin weiter offen für Ideen und Kommentare hier, aber für mich war’s das erst einmal.
Alternativ kann man ja ffprobe direkt auf die URL loslassen.
Normalerweise holt das weniger Daten, allerdings halten sich manche Server anscheinend nicht an die Grenzen in Range Requests für den Header und schicken mehr zurück.
Wäre jetzt an jemandem mit großem Testset zu prüfen, was in Summe die sparsamere Methode ist.
Vielleicht wär das generell ne Strategie, erstmal n MB zu downloaden und zu schaun, of ffmpeg was mit anfangen kann.
Wenn nicht, lädste noch ein MB nach und hängst es an das bereits heruntergeladene ran. Dann wieder schaun, obs ffmpeg diesmal schluckt. Usw. Bis ffmpeg was sinnvolles ausspuckt.
Das könnte nen guter Kompromiss sein, der auch all die MP3s abfängt, bei denen in den ersten MB noch nicht die Chaptermarker drin sind.
