Liveevents mit Podlove

Hallo Leute,

ich habe dünn in Erinnerung, dass mal ein Modul für Livesendungen geplant war. Mit Kalender und allem pi, pa und po.
Kann aber auch sein, dass ich mich irre und nur Halus habe.

Ist da was unterwegs oder lohnt es sich für mich, das Thema mal aus Richtung der Hörsuppe anzugehen? Da steht nämlich seit ziemlich genau immer ganz vorne in der ToDo-Liste ein WP-Plugin für Podcasts, mit dem Termine verwaltet und zu mir / xenim(?) oder sonstwo hin geschoben werden können.

Nur, sowas mach ich nicht, wenn das für Podlove in der Mache ist. Da klink ich mich dann lieber rein :slight_smile:

An Datenquellen, die besser strukturiert sind, als einfache ical-Dateien bin ich natürlich auch immer interessiert und würde das auch zügig einbauen.

Was schwebt dir da technisch vor? Eine json/xml/…-Datei, die man von der Wordpress-Installation pollen kann oder zusätzlich auch das Aufrufen von Callbacks bei der Hörsuppe/xenim oder bei irgendeiner Art Hub (Pubsubhubbub?!)?

Ich habe das Thema mit @martinhering und @ericteubert schon mal durchgesprochen und wir sind gerade dabei, eine neue Spezifikation zu definieren. Ein Entwurf findet sich in unserem Podlove-Publisher-Trello unter https://trello.com/c/71QPQCuF/441-podlove-streaming-extensions.

Grundidee ist, dass Podcasts ihre Live-Ankündigungen direkt im Feed mitliefern, allerdings könnte die selbe Spezifikation auch für Standalone-Dokumente verwendet werden. Die Hörsuppe könnte so die Information automatisch beim Parsen der Feeds abholen ohne große iCalender-Arithmetik machen zu müssen.

Ich würde mir Feedback zu der Spezifikation wünschen. Wir planen für den Publisher schon lange, Live-Ankündigungen mit einzubauen und denken, dass sich der Aufwand in Grenzen hält und wir das eigentlich auch bald mal umsetzen können.

Ha! Danke Tim, das hab ich gesucht.
Wir melden uns :wink:

Ich misch’ mich jetzt mal dazu, stehe ich doch mit allen von euch mehr oder weniger in Kontakt. :blush:

Ich finde die PSE sehr nuetzlich und wichtig. Wie erwaehnt, ich bin am Bau eines Live-Streaming Clients fuer den Mac (evtl. auch fuer iOS). Bisher habe ich dafuer die Dienste von Xenim verwendet, weil sie in meinen Augen zwei nicht zu unterschaetzende Feature bieten:

  1. Notification, wenn ein Stream beginnt/beendet ist
  2. aktuelle Hoererzahl eines gerade streamenden Podcasts im Response

Allerdings, das habe ich auch schon hier und da verlauten lassen, ist der Content (also die Metadaten zu den Podcasts und ihren Episoden/Events) mehr als duerftig. Ich kann nur spekulieren, woran das liegt. Ich vermute mal, die Damen und Herren Podcaster finden das Handling damit zu umstaendlich oder sie sind einfach zu faul.

Von der technischen Seite bin ich ein echter Xenim-Fan. Aber warscheinlich auch nur deshalb, weil ich selbst aus der technischen Ecke komme. Die Podcaster aber brauchen etwas, woran sie gar nicht vorbeikommen es zu benutzen. Wie eine Drehtuer - wer rein/raus will, muss da durch… Doch leider streamt auch nicht jeder via Xenim (was ich mir wuenschen wuerde :wink:), denn die beiden o.g. Feature sind fuer einen Client goldwert.

Von daher denke ich jetzt einfach mal laut. Neben den PSE, die unbedingt kommen sollten, wuerde ich mir wuenschen, dass man Funktionalitaeten, wie sie die Hoersuppe und Xenim bieten, irgendwie verheiraten kann.

Ich kann im eurem Trello-Board nicht schreiben, deshalb hier:

Ist mehr als eine Sprache in einem Stream verfügbar (durch mehrere Audiospuren oder Untertitel) sollten die Sprachen durch Kommata separiert aufgeführt werden.

Das würde ich anders machen. Wenn man die Sprachen als XML-Attribute an den einzelnen Streams einfügt, kann man mit XML-Mitteln danach suchen und muss nicht bei jedem Streams-Element den Attribut-String parsen. Vielleicht so:

<pse:streams media="audio" description="Standard Audio with Live Translation">
<pse:stream lang="en" type="audio/mpeg" bitrate="128000" url="http://streams.xenim.de/metaebene-translation.mp3" />
<pse:stream lang="gsw" type="audio/mpeg" bitrate="128000" url="http://streams.xenim.de/metaebene-translation.mp3" />
<pse:stream type="audio/ogg" bitrate="128000" url="http://streams.xenim.de/metaebene-translation.ogg" />
<pse:stream lang="de" type="audio/opus" bitrate="128000" url="http://streams.xenim.de/metaebene-translation.opus" />
<pse:stream type="audio/aac-adts" bitrate="128000" url="http://streams.xenim.de/metaebene-translation.aac" />
<pse:stream type="audio/aac-aacp" bitrate="128000" url="http://streams.xenim.de/metaebene-translation.heaac" />

</pse:streams>

Die Sprache wäre in diesem Fall eine Eigenschaft der einzelnen Streams, da ja ein Stream theoretisch mehrere Sprachen liefern kann. Aber vermutlich ist das ein recht seltener Fall, denn warum sollte man eine Sprache streamen, wenn man sie nicht gehört hat.

Die Sprache sollte man aber vielleicht trotzdem im <pse:streams> Element spezifizieren. Gibt es mehrere Sprachen macht man einfach mehrere Gruppen (die dann ja im Prinzip auch auf den selben Stream verweisen könnten, wenn der tatsächlich mehrere Sprachen liefert.

Ich ändere das mal, so dass man pro Gruppe nur eine Sprache angeben kann. Danke für den Hinweis.

Hihi… wenn ich’s recht betrachte, macht das den zweitältesten Dienst der Hörsuppe überflüssig, nämlich die Livefeeds.

Eine Verständnisfrage zu den Trello-Regeln (bei euch), @timpritlove : Du hast das die Spezifikation verlinkt und darüber wird dort auch diskutiert. Wenn ich nun generelle Fragen/Einwände/whatever habe, kann ich die bei der Spezifikation stellen, obwohl die Fragen ggf. nichts mit dem XML direkt zu tun haben?

Als Aggregator könnten Deine Live-Feeds immer noch sinnvoll sein. Du kannst natürlich auch alles direkt als PSE aggregieren, aber sinnvoll wäre das immer noch.

Trello ist für uns am Ende doch eher eine TODO-Liste als ein Debattierclub. Das Sendegate ist da mehr für Diskussion geeignet. Von daher gerne hier. Oder auch auf englisch in der Podlove Community :slight_smile:

Ähm. Ich glaube, ich bleibe lieber bei Deutsch. Mein Englisch ist eher mau :smiley:

Die Idee, Liveevents als spezielle Episoden in den Feed zu werfen für die Podcatcher ist natürlich großartig. Leider haben praktisch alle größeren Podcatcher inzwischen die eigenen Caches/Server/wasauchimmer zwischen die Apps und die Feeds gezogen. Was dann gerne mal zu Verzögerungen führt.

Wenn der Liveevent ein paar Tage vorher im Feed steht: alles gut. Wenn’s kurzfristig wird, wird ein Großteil des Publikums es nicht mitbekommen.

Kurz und gut: Da wird’s zu Problemen kommen. Ich bekomme einen Großteil der Events in meinem eigenen Livefeed nie in den Podcatcher und muss bei z.B. instacast inzwischen manuell einen Reload des Feeds erzwingen, damit ich die Livefolgen im Podcatcher habe.

Kann @martinhering vll was dazu sagen?

Und es wird wie immer einen nicht unerheblichen Haufen Podcasts geben, die das eben nicht nutzen. So ganz überflüssig wird’s nie werden und so lange es 1 Mensch nutzt, wird’s bleiben. Ich könnte mir vorstellen, dass die shownotes sich über Liveinfo im Feed der Podcasts freuen.

Dass das nicht jeder nutzen wird oder nutzen kann ist mir natürlich wohl bewusst. Mehr tun als sinnvolle Standards zu bauen können wir nicht, die Verbreitung wird eher davon abhängen, wie gut das dann umgesetzt wird.

Wer hätte vor drei Jahren gedacht, dass Kapitelmarken eine solche Verbreitung erfahren würden?

Also ich denke, die ganzen Aggregator-Dienste brauchen schon so mind. 1 Stunde, um eine neue Folge zu sehen. Manche schaffen das auch in 30 min. Verlassen würde ich mich aber nicht drauf. Viele Aggregatordienste würden die Episode mit den Streaming-Links eh rausfiltern, weil die Episode kein Enclosure enthält. Und darauf setzen, dass alle den Standard einbauen, würde ich auch nicht. Das Live-Model passt meistens eh nicht in traditionelle Podcast-Clients rein. Ich denke eher, man sollte auf neue Apps setzen, die die Podcastfeeds zwar parsen, aber sich nur um die Live-Informationen kümmern. Und diese dann auch anders darstellen.

Für welchen Zeitpunkt sind diese Informationen gedacht? Nur während der Sendung oder auch als Ankündigung im Vorfeld?

Wenn es auch als Ankündigung gedacht ist, fehlt ein Flag, ob das jetzt läuft oder nicht. Ich überarbeite auch gerade das Notification-System von xenim, über das bisher Benachrichtigungen zu Twitter und ins IRC gesendet werden. Dort wird in Zukunft auch ein HTTP-Callback konfigurierbar sein, über den ein solches Flag aktualisiert werden könnte.

Im Zuge dieser Erweiterung wäre es auch gut an das Problem der Zuordnung von Stream zu Folge zu denken: Also welche Folge da jetzt läuft, wenn ein Stream startet. Nach dem bisherigen Entwurf scheint da die guid als eindeutiger, unveränderlicher Identifier am geeignetesten zu sein. Dann müsste man allerdings diese meistens eher unhandliche GUID in den Metadaten des Streams unterbringen.

Ich habe jetzt mal in den Feed der Freakshow geguckt: In http://freakshow.fm/feed hat die GUID keinen Wert, in der Version, die über FeedBurner läuft (http://feeds.feedburner.com/mobile-macs-podcast) scheint das in Ordnung zu sein.

Im Beschreibungstext ist noch ein Typo: “bitrare”.

Es ist vor allem und primär als Ankündigung gedacht. Was Du mit “ob das jetzt läuft oder nicht” meinst und was da ein “Flag” signalisieren soll ist mir gerade unklar.

Tja, problematisch. Derzeit bevorzuge ich eine Implementierung, bei der die GUID des Ankündigungs-RSS-Eintrags nicht identisch ist mit der der Episode. Das müsste man mal testen, wie sich die Podcast Clients verhalten. Kann auch sein, dass eine identische GUID nicht nur nicht problematisch sondern auch wünschenswert wäre, da Clients doppelte Einträge anzeigen (auch wenn die Ankündigung aus dem Feed verschwindet).

In iTunes war es schon immer so, dass Einträge ohne <enclosure> ohnehin komplett ignoriert werden, das gilt aber wohl nicht für jeden Client da draussen. Hier bin ich mir über die Implikationen einfach noch nicht im Klaren.

Davon abgesehen finde ich die Zielsetzung einer Zuordnung von Stream und Episode noch etwas unklar: was genau soll damit erzielt werden? Ein Announcement ist ja recht klar: es wird eine Live-Sendung geben und zwar am/um/über. Der Mitschnitt wird ja im selben Feed später selbst nachgeliefert.

Der erste Feed ist der reine Blog-Feed, der für diese Diskussion ohnehin irrelevant ist. Dass hier die <guid> leer ist, ist ein Bug (fahre gerade die Publisher 2.1 beta) und das sollte natürlich nicht so sein.

Wenn sich die GUID eines Eintrages ändert, ist der Nutzen dieser Sache für externe Dienste hinüber. Wie soll ich z.B. für xenim für gelaufene Sendungen dann die URL zum fertigen Podcast oder der Aufzeichnung nachtragen können, wenn ich die Ankündigung und den Podcast nicht in Verbindung bringen kann? Auf ähnliche Probleme stoßen sicher auch die Shownotes, die ein Pad auf Basis der Ankündigung erstellen könnten.

Dies ist kein Problem innerhalb von Podlove. Kurzer Blick über den Tellerrand auf xenim: Das xenim-System bekommt Audiodaten auf einem Kanal, auf dem mehrere Podcasts senden können. Um das richtig anzuzeigen, auf den richtigen Accounts zu twittern, etc muss jetzt automatisiert herausgefunden werden zu welchem Ankündigungsbeitrag im Podcastfeed dieser Inhalt jetzt gehört. Bisher wird dazu hauptsächlich das Sendungskürzel (z.B. FS124) verwendet. Da diese aber gelegentlich noch nicht vorhanden oder in dieser Form nicht sinnvoll sind, würde die GUID eine eindeutige Identifikation ermöglichen. Dazu müsste der Podcaster diese GUID aber aus Podlove herauskopieren und im Icecast-Source-Client eintragen.

Die URL des Podcasts ist ja tatsächlich im Eintrag enthalten: im <link> Element. So wie ich mir das vorstelle würde sich die URL nicht ändern, aber vielleicht die GUID.

Muss darüber noch mal ein wenig nachdenken, aber wenn eine ID erforderlich ist könnte man natürlich auch noch über eine separate ID nachdenken, die Stream und Aufzeichnung verbindet, z.B. durch einen Verweis auf die Ankündigungs-GUID.