in eigener Sache: Daten! Überall Daten!

Gestern hat mir eine Mail vom Markus eine alte Idee in den Kopf zurückgebracht, die ich nun mit heißer Nadel und kaltem Kaffee zusammengehackt habe.

Es geht um etwas, das man vielleicht API nennen könnte. Ob das stimmt, überlasse ich anderen zur Beurteilung, aber bleiben wir mal bei dem Begriff.

Es gibt nun also ein Auslassventil für all die schönen Daten, die ich hier wie ein alter Drache seinen Goldschatz bisher gehortet habe. Bisher gibt es “nur” ein paar Grundfunktionen, die es aber schon in sich haben sollten.

Ihr könnt ohne Authentifikation darauf zugreifen, ein Limit oder ähnliches gibt es erst einmal nicht. Ob das so bleibt, weiß ich nicht, jedoch glaube ich nicht, dass meine arme Kiste darunter zusammenbrechen wird.

Was also gibt es? Natürlich Podcastdaten. Daten über einzelne Podcasts, deren Episoden, Livetermine und dann noch eine Funktion, mit derer Hilfe Ihr den Kalender anzapfen könnt.

Ich habe eine kleine Dokumentation dazu zusammengewürfelt, die Ihr Euch hier anschauen könnt. Der Schlüssel zu den meisten Daten wird der slug des Podcasts sein, für den Ihr Daten haben wollt. Der simpelste Weg an den zu gelangen, ist sich den URL der Infoseite zu diesem in der Hörsuppe anzuschauen. Dieser lautet für z.B. Not Safe For Work (das gerade anfängt live zu laufen) http://hoersuppe.de/podcast/nsfw. Der Slug ist hier also “nsfw”.

Was man damit anstellen kann oder auch nur will? Keine Ahnung, die Ideen müsst nun Ihr haben. Der Markus z.B. wird zu gegebener Zeit die Daten des Reliveradios anreichern. Ich habe nur eine Bitte: Stellt nicht einfach nur Funktionen nach, die es hier bereits gibt, wie z.B. den Livekalender. Das führt im Zweifel nur zu Verwirrung für die Nutzer, wenn der Datenstand zwischen Original und Kopie nicht der gleiche ist.

Wenn was nicht stimmt, Fragen offen sind oder Ihr mich lobpreisen und mit Gold, Weihrauch und Myrre überschütten möchtet, wisst Ihr ja, wo Ihr mich findet.

Und nun

https://i.chzbgr.com/completestore/12/11/30/dRaTyZNalkCN0kB9F2uXTg2.jpg

14 Comments

  1. Wäre es dann sinnig, alte Folgen komplett in die DB zu beamen? Ich frage für einen Podcast, der über 200 Folgen mehr hat als die Suppen-DB kennt.

  2. Jupp, Andre.

    Du stehst gaaaanz oben auf der Liste, was das Nachtragen “alter” Episoden betrifft. Es wurmt mich, wenn sowas nicht vollständig ist.

    Gibt es denn irgendeine Chance, an die alten Episoden per Feed aus Deinem s9y zu kommen? Bei WP wüsste ich ja wie, s9y ist mir da eher unbekannt.

  3. Also die normalen Feeds haben alle das selbe Limit von 100 Items. Wenn ich die Doku richtig lese, kann man mit den richtigen Parametern nen Feed aller Einträge in der Kategorie bekommen. Ich hab da nur den dumpfen Verdacht, dass der PHP-Prozess dabei in nen Timeout läuft. Sind ja auch ‘nur’ 984 Dateien in meinem Archiv, die dann alle in nen Feed gestopft werden wollen. Mal davon abgesehen, dass ich keine Ahnung hab, ob die Links zu Podshow/Mevio überhaupt noch tun. Aber schlimmstenfalls hab ich ein lokales Archiv aller Uploads. Ist auch nur 42 GB groß.

    • Hmhmhm… Das wir dein größeres Projekt, vermute ich. Wobei es ausgerechnet bei Dir sicher lohnen würde, schließlich hat das den Charakter einer historischen Dokumentation. Vielleicht bau ich mir mal einen Crawler, der Deine Webseiten durchforscht und sich dort die Informationen klaut… Ein Feed wäre natürlich bequemer, über den würde ich den Reader laufen lassen und gut.

      Das timeout in php lässt sich ja regeln. Im Zweifel müsste das Ganze ja nur einmal erzeugt werden. Vielleicht solle ich mal nach Hamburg kommen, wenn nicht gerade zum 29c3 ;)

  4. Der Hammer! Ich bin begeistert.

    Feature-Request: mmh ich fürchte ja dass das Datum gar nicht zur Verfügung steht (man könnte es aus dem Dateinamen raten) aber: Episodennummer?

    Ansonsten, Lob, Gold (nja Flattr-Abo) und Myrre für dich!

    >> Ich habe nur eine Bitte: Stellt nicht einfach nur Funktionen nach, die es hier bereits gibt, wie z.B. den Livekalender.

    Hmm naja ich hätte schon ne Idee, wie man den Live-Feed… nicht besser, nicht schlechter aber “anders” machen könnte :D

    • Episodennummern sind so ein Ding. Die gibt’s ja gar nicht. Jedenfalls nicht als Metadaten aus den Feeds, die ich habe. So könnte ich nur raten, ob die 100te Sendung, die bei mir im Feed landet auch die Episode 100 ist. Der Mangel ist allerdings vorhanden und erkannt. Ob er gelindert wird… ich wage es zu bezweifeln.

      Was den Livefeed angeht hast Du jetzt zwei Möglichkeiten: Du verräts mir, worum es geht und ich schaue, ob es Sinn hat und ich das umzusetzen vermag, oder Du machst halt mal :)

  5. >> Was den Livefeed angeht hast Du jetzt zwei Möglichkeiten: Du verräts mir, worum es geht und ich schaue, ob es Sinn hat und ich das umzusetzen vermag, oder Du machst halt mal :)

    Oooch wie ich mich kenne bring’ ich es eh nicht zur Publikationsreife, also warum hinterm Berg halten? XD (ich bin nur nicht sicher ob eine Kommentarspalte der richtige Ort ist, aber was soll’s, ignoriert das eben XD)

    Ersteinmal habe ich mich falsch ausgedrückt, ich sagte “live feed” aber ich meinte eher “live link” oder “live playlist” also http://hoersuppe.de/live/

    Derzeit gibt es entweder einen LiveStream, dann wird dieser gestartet (HTTP 302?) oder es werden Episoden gespielt.

    Meine Idee ist relativ simpel: In dem Moment, in dem die Playlist abgerufen wird wird eine playlist generiert deren Länge bis zum nächsten Live-Event reicht. Ich persönlich dachte an freie Musik, aber andere Podcasts gingen natürlich auch. Am Ende der Playlist wird der Streamlink platziert.

    Ein Beispiel: Der nächste Stream beginnt in 3 Stunden und 27 Minuten. Das bedeutet ich kann in ca. 3:20 oder so hineinschalten (hab da selbst nicht so die Erfahrung wann die typischerweise angehen). Dann schau ich in die letzten Episoden und stelle fest aha, ein Podcast von 2:20, rein in die Playlist sind noch 1h:07 zu überbrücken okay, noch ein Podcast, der 90Minutencast ist zu lang aber da ist einer mit 44 Minuten, in die Playlist. Bleiben noch 23 Minuten oder etwas weniger. Das kann man mit Musik überbrücken, einfach random Musikstücke reinwerfen (deren Längen freilich bekannt sein müssen) bis mindestens 15 Minuten voll sind.

    So… oder so ähnlich :D (btw. könnte man auch sowas wie Werbung einstreuen, Werbung für Podcasts fürs Podcasting, für die Hoersuppe oder Podperlen)

  6. Ich glaube, ich komm an die Timeout-Konfiguration nicht ran. Ich bilde mir ein, irgendwo mal was von mehr Einstellungen an s9y gelesen zu haben, die man per URL-Parameter angeben kann. Wenn ich mal Langeweile hab, wühl ich mal mehr als eine Suche tief.

    Zeit in größerer Menge hab ich die ersten paar Wochen im Januar, da hab ich Uhr-Laub.

  7. Das mit dem Live-Stream-Feed geht auch einfacher: Reliveradio einwerfen bis ein anderer Live-Stream streamt. Dann muss man das ‘was spiel ich denn?’ Problem nicht nochmal lösen.

  8. Andre… im Prinzip ja, ich habe damit 1,5 Probleme:
    1. Ich wüsste nicht wie man einen Player anweisen könnte den Track zu wechseln ohne dass der laufende zuende ist. VLC arbeitet da ständig an Kommandos, die man auch in Playlisten einpflegen kann (so im Stil vlc://after:300(skip) oder so… das ist ausgedacht). Aber das funktioniert natürlich nur im VLC und überdies fehlen ganz viele Funktionen, die man möchte
    2. (und das ist eben nur ein halber): Der Relive-Cast würde abgebrochen, nicht zuende gespielt.

    Ich schau mal, heute werde ich wohl eh keine Zeit habe (Vorcast und LNP habe ich hinter mir, Fanboys läuft und Radio Tux kommt noch und heute Abend hab ich dann Realleben… kurzum: Tag voll). Aber ich schau mal ob ich morgen was zeigbares auf die Beine kriege.

  9. Ach so noch ein Makel den ich beim Rumspielen mit der API gestern bemerkt habe und den ich schon mehrfach bei Podpott angekreidet habe: Es gibt ein Datenfeld namens “Twitter”.
    Das finde ich ein wenig zu speziefisch. “In der Szene” scheint sich ja appt.net oder wie das heißt zunehmend zu verbreiten, ich persönlich bevorzuge noch immer status.net (besser bekannt unter der Referenzimplementierung identi.ca).

    Kurzum: Dieses Datenfeld wird der Vielfalt des sozialen Netzes meiner Meinung nach nicht gerecht. Sinniger wäre ein Array of “socialmedia” in denen jeweils zwei Datenfelder stehen nämlich die “ID” (wie twitter.com/username oder username@identi.ca oder username@diaspora.pod.org oder facebook.com/user/username etc. aber durchaus warum nicht andere Kontaktdaten wie username@jabber.org oder 12345678@icq.com) und jeweils den Namen des Protokolls dazu (ostatus, ostatus, diaspora, facebook, xmpp oder oscar) und wie gesagt könnte/sollte das Datenfeld “SocialMedia” (oder “contact”) durchaus eine Liste oder ein Array darstellen, welches mehrere solcher Kontaktoptionen enthalten kann.

    Freilich weiß ich nicht wie gut sich das in deine derzeitige Datenstruktur einfügt, aber “Twitter” hielt ich für suboptimal XD

    • So. Das mit dem Kontakt ist erledigt. Mail, Twitter, ADN sind mal drin. Ob ich mehr pflegen mag, wage ich zu bezweifeln :)

      Darüber hinaus stehen nun auch wieder halbwegs verlässliche Streamserverdaten in der API.

  10. @Deus Figendi Die Idee ließe sich durchaus im geringen Rahmen verfolgen. Allerdings müsste erkennbar sein, dass nach dem Ablauf der Playliste wirklich ein Livepodcast ansteht.

    Mal notieren *kritzel*

    Und das mit den SM-Daten ist nur so halb richtig. Ich habe nicht nur Twitter. Da gibt’s, wenn vorhanden auch ADN in den Daten, allerdings sind die nicht in einem Feld zusammengefasst. Da hast Du wiederum völlig recht, das könnte zusammengefasst werden. Die Mailadresse des Podcasts hab ich ja in vielen Fällen durch den Feed auch.

    Auch das: notiert, ist nämlich umsetzbar. Nur Facebookdaten wird’s hier nicht geben ;-)

Comments are closed.