Podlive Release - Verpasse nie mehr eine Livesendung!

Wir nutzen für Podlive die API von Studiolink. Wir sind daher davon abhängig welche Daten Studiolink über die API freigibt.

Ich habe Verständnis dafür, dass Studiolink sich rechtlich absichern möchte, welche Daten über eine API nach außen geteilt werden dürfen. Dafür gibt es mehrere Möglichkeiten - einige wurden hier ja schon besprochen.​ Studiolink hat sich für ein Opt-In entschieden.

Wir versuchen gerade das Beste daraus zu machen, indem wir die Podcaster darauf aufmerksam machen und hoffen, dass viele diesen Schalter umlegen. Wir versuchen die Unannehmlichkeiten für die User der App möglichst gering zu halten indem wir den Podcasts eine Woche Zeit geben den Schalter zu aktivieren bevor er dann nächste Woche tatsächlich seine Wirkung entfaltet.

Ich hoffe wir können das Thema bald abhaken und stattdessen darüber nachdenken welche Features wir mit der App realisieren können.

3 „Gefällt mir“

Ich habe die Lösung nun überarbeitet. Jeder/m Streamer*in wird nun beim Stream Login direkt angezeigt, ob er/sie dem neuen API Feature zustimmen will oder nicht. Damit wird jeder vor die Wahl gestellt, ob er/sie die neue API freigeben möchte oder nicht und es kann auch von niemanden übersehen werden. Das kommt einer AGB Einwilligung sehr nahe, ohne wirklich eine zu sein.

Jetzt noch einmal “kurz” warum das Ganze. Dem Argument, ein entstehendes offenes/freies App Ökosystem damit zu beschneiden, halte ich entgegen, dass, wenn jetzt da draußen 20 - 30 Apps wären und jemand wirklich eine Klage anstrebte, der Schaden für dieses Ökosystem wesentlich größer wäre. Und das nur aufgrund meiner Nachlässigkeit vorab vom (vermeintlichen) Rechteinhaber eine Einwilligung für die Weitergabe von Daten (Bilder etc.) zu haben. Selbst Metadaten scheinen dabei eine Rolle zu spielen. Ich hätte diese bisher auch als frei und unbedenklich betrachtet.

In der ersten Variante speziell nur auf die Podlive App hinzuweisen und den Schalter so zu benennen, war einfach dem Umstand geschuldet, dass es halt bisher die einzige Anbindung ist. Im Rückblick betrachtet, war das ein falsches Signal. Ich möchte natürlich keine App diskriminieren.

Nun nehmen wir mal die Schadensersatzforderung aus dem Beispielurteil weiter oben. 150 € für den Text und 100 € für das Bild. Das klingt erstmal wenig, hinzukommen aber noch die Gerichts- und Anwaltskosten. Wenn sich die Klage dann auf 20 - 30 Apps erstreckt, wird die Schadensersatzforderung vermutlich ebenfalls höher ausfallen, insbesondere wenn gegen jeden App Entwickler eine einzelne Klage angestrebt wird. Multipliziert mit mehreren Stream Verletzungen.

Mir ist zwar auch unklar, wie realistisch das Worst-Case Szenario wirklich ist, aber undenkbar ist es nicht. Es kann Jahre lang gut gehen, doch eine einzige Klage kann die App Einnahmen von Monaten evtl. sogar Jahren vernichten. Wäre es da nicht besser, vor Gericht das Argument zu haben, das eine explizite Einwilligung vorgelegen hat?

Der Vergleich mit einem Podcatcher hinkt. Ein Podcatcher hat im Urzustand keinerlei Podcasts sondern wird vom Benutzer selbst befüllt. Das heißt, ein Rechteinhaber dürfte Probleme haben, zu beweisen auf welchen Endgeräten/Apps seine Rechte verletzt worden sind. Bei Podlive sieht das anders aus (siehe Podlive Struktur).

Im Sendegarten hatten wir schon den Fall, dass eine Podcasterwähnung und die Einbindung des Logos in eine Collage zur Folge hatten, vom betreffenden Podcastanbieter aufgefordert zu werden, dieses sofort zu entfernen. Das ist quasi genauso abwegig, weil der Podcast durch die Erwähnung auch nur Vorteile hatte.

Wenn ich es mir wünschen könnte, wäre ich natürlich auch bei der ersten Implementierung geblieben.

#Streams, die sich an einen definierten Nutzerkreis richten
Ein möglicher Grund sich gegen die API zu entscheiden sind auch Streams, die sich nur an einen definierten Personenkreis richten. In der ursprünglichen Version wurde jeder „Studio Link OnAir“-Stream sofort in der in Podlive-App angezeigt. Das ist, glaube ich, auch nicht jedem klar, dass er/sie plötzlich in X Geräten auftaucht und unmittelbar live gehört wird. Jetzt ist es deutlich und auch, wie sich das Verhalten anpassen lässt.

Dem kann man wieder entgegen halten, dass dann Studio Link OnAir nicht das richtige Tool dafür sei. Mag sein, aber wenn ich anfange, solche Nutzungsszenarien in Frage zu stellen und auszuschließen (über AGBs etc.), ist Studio Link dann wirklich noch ein offenes Projekt? Ich möchte eigentlich ungern (rechtswidrige Inhalte ausgenommen) als Plattform hier den Zugang künstlich beschränken.

Warum keine AGBs?

Das Problem ist, auch hier wäre ein Opt-In zwingend notwendig und die Frage ist auch wo, die AGBs akzeptiert werden müssten, um wirklich rechtskräftig zu sein. Im Zweifel vor dem Download, bzw. Öffnen der eigentlichen App selbst.
AGBs müssen ebenfalls rechtlich einwandfrei formuliert sein, ansonsten lockt das wieder Abmahnanwälte auf den Plan. Der Aufwand dafür ist also wesentlich höher und erfordert zusätzlich einen Opt-In auf Seite des Streamers. Da diese Erlaubnis auch nur nachträglich erfolgen kann, hätte das auch die gleichen Konsequenzen wie der Opt-In über den API Schalter.

Keine Bilder in der Podlive App

Ich glaube, ohne Grafiken wäre die App wirklich kaputt. Die Coverbilder machen in der App einen wichtigen Bestandteil aus. Abgesehen davon, scheint die Rechtslage bzgl. Metadaten zumindest uneindeutig. Hätte damit grundsätzlich aber weniger Bedenken.

Podlive Struktur

Technisch ist die Studio Link OnAir API gegenwärtig genau auf die Bedürfnisse von Podlive abgestimmt. Ob bzw. wann es eine öffentliche API geben wird, kann ich momentan nicht sagen. App EntwicklerInnen können mich aber gerne anschreiben.

Podlive holt sich über die Studio Link OnAir API alle Metadaten inclusive der Bilder ab, speichert diese und verkleinert sie für verschiedene Ansichten in der App. Darauf greift dann die App selbst zu. Das bedeutet, die Apps sind kein reiner Browser/View und Cache vom Studio Link Server oder von der API, sondern komplett auf einer eigenen Infrastruktur gehostet mit Übernahme und Verarbeitung der Daten. Da es sich dabei bisher nicht um datenschutzrelevante Inhalte handelte, hatte ich da auch zunächst keine Bedenken.

Aber mit Blick auf das Urheberrecht sieht das anders aus. Übernommen werden die Daten aktuell, wenn mindestens Titel, Beschreibung und ein Cover-Bild gesetzt sind. Das heißt, schon in der Ursprungsversion war es nicht mit nur einem Klick getan, um in der Podlive App zu landen.

Kommunikation/Fazit

Ich stimme zu, in der Kommunikation ist einiges schief gelaufen und da habe ich mit meiner Entscheidung auch dazu beigetragen. Mir ging - und geht - es wirklich um das Wohl aller Beteiligten, rechtlich einigermaßen sicher zu sein und jedem die Freiheit zu geben, sich auf der Plattform optimal entfalten zu können.

Am Tag vom Podlive Release erreichten mich mehrere Hinweise (nicht nur von Martin vom Metercast), die die automatische Datenweitergabe an Podlive ohne explizite Zustimmung kritisch sahen und die Ursprungsversion rechtlich in Frage gestellt haben.

Das hätte vielleicht durch eine bessere Kommunikation darüber, wie das Preismodell von Podlive nach der Betaphase aussieht, entschärft werden können. Manche sind davon ausgegangen, dass sich die Podlive App, nach dem Muster der Xenim App, über Spenden finanziert.

Es tut mir leid, wenn ich mit Hinzunahme der Opt-In Entscheidung jemanden verletzt habe. Ich habe ja selbst zahlreiche Entwicklungsstunden investiert, um Podlive ins „Studio Link OnAir“-Universum zu bekommen, und mir liegt auch sehr daran, dass @funkenstrahlen, @phranck und zukünftige Entwickler*innen damit erfolgreich sind.

Mir geht es allein darum, das System langfristig vor Schaden zu bewahren, die für mich (Studio Link) oder Podlive existentiell bedrohlich sein könnten. Diese Bedenken konnte kein Beitrag hier bisher vollständig aus dem Weg räumen. Meiner Einschätzung nach, ist es nach wie vor ein offenes Problem.

Ich denke und hoffe, dass Podlive sich trotzdem prächtig entwickeln wird. Keine Streamer*in dürfte nun noch den Opt-In-Hinweis übersehen können. Wenn ihr Verbesserungsvorschläge habt, nehme ich diese gerne entgegen.

Mir ist transparentes Handeln sehr wichtig und hoffe sehr, dass ich damit die Hintergründe die zu meiner Entscheidung geführt haben, ausreichend beleuchten konnte.

10 „Gefällt mir“

Und das hat mich von Anfang an stutzig gemacht. Ich komme bei solchen Aussagen zu dem Schluss, dass das gleiche Konzept Podlive ohne Probleme akzeptiert worden waere, wuerde die App nichts kosten. Das ist ein bisschen viel Konjunktiv, ich weiss. Aber was haette eine Spendenfinanzierung am Gesamtkonzept geaendert?

Brauchbare Lösung würde ich sagen, da sehr “in your face” - den Text finde ich auch schon gut, müsste man mal durch Leute die jetzt den ganzen Hintergrund nicht kennen beurteilen lassen.

4 „Gefällt mir“

Ich finde das auch eine super Lösung. Zum einen geht es nicht um nur eine App, sondern um die ganze API und zum anderen ist es nun weniger wahrscheinlich, dass Podcasts “aus Versehen” nicht in der App erscheinen. Gleichzeitig bekommt man die Möglichkeit dazu - und das ist auch zu respektieren.

4 „Gefällt mir“

Im aktuellen sendegarten haben wir unter anderem auch darüber gesprochen.

3 „Gefällt mir“

Ich habe hier im Podlive Blog nochmal detailliert erklärt, wie das geht wenn man möchte das der eigene Podcast Livestream auch via Podlive gehört werden kann:

3 „Gefällt mir“

Hallo Podcast Hörer,

Ich freue mich endlich das neue Update mit euch teilen zu können! Ich habe in den letzten Wochen an einigen Neuerungen gearbeitet. Podlive ist nun für iOS 11 optimiert!

Falls der Podlive Account in der Keychain gespeichert ist, können die Logindaten nun automatisch ins Anmeldefenster kopiert werden.

Der Chat öffnet sich nun in der Safari App. Die bisherige Möglichkeit funktioniert unter iOS 11 nur noch eingeschränkt, da nach einmal Schließen und wieder Öffnen des Chats der Loginstatus verloren geht.

Das User Interface wurde an vielen Stellen verbessert und an das Design von iOS 11 angepasst.

In der Ansicht um neue Podcasts zu entdecken gibt es nun auch einen Bereich für neue Podcasts, die gerade erst dazu gekommen sind. Dort werden Podcasts angezeigt die sich in den letzten 4 Wochen angemeldet haben.

Im Entdecken Bereich wird nun direkt zu jedem Channel die Followerzahl angezeigt statt der Author.

In der Liste mit allen Podcasts gibt es nun auch eine Suchleiste.

Viele Ansichten laden nun mehr Podcasts auf einmal. Damit ist es nicht mehr so oft nötig auf “Mehr Laden” zu drücken.

Podlive unterstützt nun AirPlay 2 Langform Audio. Damit kann der Livestream zum Beispiel weiterlaufen, während ein Anruf reinkommt und die Stabilität des Streams wird erhöht.

Die meisten Texte im User Interface unterstützen nun die automatische Schriftgröße.

Der Playbutton wurde vergrößert und ist nun leichter zu treffen. Damit könnt ihr Podlive nun auch nach einem Glas Wein weiter problemlos nutzen :stuck_out_tongue_winking_eye:

Ich habe das Background Notification System überarbeitet. Damit wacht die App deutlich seltener im Hintergrund auf und braucht so weniger Strom.

3D Touch Quick Actions für den Home Screen hinzugefügt.

An einigen Stellen 3D Touch Peek und Pop implementiert.

Viele kleine Fehlerbehebungen und Performance Verbesserungen. Der ganze Code wurde umgestellt auf Swift 4.

Ich hoffe euch gefällt das neue Update! Ich freue mich von euch zu Hören! Ihr können eine Bewertung im App Store hinterlassen oder eine Nachricht an support@podlive.io schreiben.

Stefan

Hier noch ein paar Screenshots:




3 „Gefällt mir“

Wir würden auch gerne mal Episoden live streamen, wo und wie kann man sich als Podcast bei euch anmelden? Oder geht das irgendwie über Studio Link On Air?

Das freut mich zu hören! Klar könnt ihr das mal machen. Hier steht ausführlich erklärt wie es geht.

2 „Gefällt mir“

Hi @funkenstrahlen,

sag mal ist es normal, dass podlive sooo viel akku braucht?

vgl:

Hallo John,

das sollte natürlich nicht so sein! Tut mir Leid, dass du das Problem hast.

Meine Vermutung woher das kommt: Es gibt aktuell noch ein Problem, dass die App zu häufig im Hintergrund aufgeweckt wird durch Push Notifications. Der Fix dafür ist schon fertig und erfordert nur noch ein Server Update. Das kann ich allerdings erst umstellen, sobald ein Großteil der User die App auf den aktuellen Stand aktualisiert hat und es ein Update für den Mac gibt. Sonst würden die User auf dem alten Stand einige Funktionen nicht mehr haben und das möchte ich vermeiden. Lange wird das aber nicht mehr dauern, bis das soweit ist.

Ich denke also, dass sich dein Problem damit dann erledigen wird.

Was mich ein bisschen wundert ist, dass iOS hier überhaupt keine Background Zeit anzeigt. Könnte vielleicht daran liegen, dass das Aufwecken im Hintergrund wirklich nur extrem kurz passiert. 11% in 1min on Screen zu verbrauchen ist absolut unrealistisch. Das schafft ja nicht einmal ARKit.

Workaround: Du kannst in den Einstellungen Background App Refresh für Podlive abstellen. Dann werden aber einige Dinge nicht mehr wie gewohnt funktionieren. Sollte aber das Akku Problem beheben, da die App dann nicht mehr im Hintergrund aufwachen kann.

Sobald das Server Update eingespielt ist, würde ich gerne noch einmal Kontakt mit dir aufnehmen und klären ob das Problem behoben ist.

liebe Grüße
Stefan

1 „Gefällt mir“

Hi Stefan,

entschuldige bitte meine fehlenden Manieren im Post oben und danke für die schnelle Antwort.

Mich hat es nur gewundert, dass es so viel ist und ja, das Fehlen der Hintergrundaktivität ist auch etwas komisch. Es ist jetzt nicht so, dass ich die App oft benutzen würde, mich interessieren nur die pushes der live Sendungen :slight_smile:

Gern warte ich auf das Update, ich hab jetzt keine großen Einschränkungen im Akku beobachtet, obwohl es so aussieht als ob die App viel zieht…

Danke und viele Grüße,

Stefan

1 „Gefällt mir“