Podlive Release - Verpasse nie mehr eine Livesendung!

derrobert · 2017-07-04T21:16:57.408Z

Ihr bietet ein kommerzielles Produkt auf der Basis einer Community-getriebenen API an. Entschuldige, wenn sich mein Mitleid in Grenzen hält. Ich verstehe Dein/Euer Problem, habe aber mit Sebastian die Erfahrung gemacht, dass er, obschon gut beschäftigt, durchaus bereit ist zu kommunizieren und solche Änderungen in Zukunft sicherlich nicht mehr von heute auf morgen einführt sondern Euch und anderen eine gewisse Vorlaufzeit bietet. Das ist in meinen Augen ein Kommunikations-Problem und kein systemisches.

Wie fast alles in diesem Thread.

jonasschoen · 2017-07-04T21:41:18.520Z

Guten Abend zusammen,

interessant, was sich hier für unerwartete Diskussionen entwickeln können. Nachdem ich den Thread gelesen und etwas nachgedacht habe, finde ich folgende zwei Möglichkeiten sinnvoll:

1. OnAir nur nutzbar, wenn dem Auslesen der API von externen Anbietern ohne Einschränkungen zugestimmt wird

Diese Option ist entspricht @timpritlove’s und @rstockm’s Auffassung und dafür müsste StudioLink im Prinzip wieder in den Ausgangszustand von vor ein paar Stunden gebracht werden. Sollte sich Sebastian (@sreimers) dazu entscheiden, fände ich aber eine Übergangsphase sinnvoll, in der den OnAir-Nutzern (Audio-Produzenten) ein Hinweis angezeigt wird, dass es eine API gibt, diese offen ist und es konkret ein Produkt (und in Zukunft vielleicht weitere) gibt, die die Streams in einer kostenpflichtigen App anzeigen. Bei der Weiternutzung des Dienstes nach einer festgelegten Frist würde diese Tatsache (die ja im Prinzip keine Änderung ist) als akzeptiert gelten, wie man das von AGB-Änderungen großer Anbieter kennt. Aus meiner Sicht sollte bei dieser Option auch eine Möglichkeit gegeben werden, seinen Podcast restlos von OnAir zu löschen.

2. OnAir bekommt ein Opt-out für Erscheinen in externen Angeboten via API

Diese Option greift @derrobert’s Verweis auf die robots.txt bei Webcrawlern auf. Die Inhalte jeder öffentlichen Webseite sind auch öffentlich einsehbar, egal ob mit oder ohne Webcrawler. Allerdings bietet die robots.txt eine Möglichkeit, Webcrawlern (und somit vor allem Suchmaschinen) mitzuteilen, dass man dort nicht gelistet werden möchte. Ob dies berücksichtigt wird, ist eine andere Frage, aber die Idee basiert eben auf dem freundlichen Einverständnis verschiedener Akteure. Und es stimmt schon, dass damit die Auffindbarkeit des eigenen Angebots stark eingeschränkt werden kann, wenn man denn möchte. Diese Option würde den OnAir-Nutzern (Audio-Produzenten) eine Wahlmöglichkeit geben mit dem Standard, dass gelistet wird. Auch hier müsste Sebastian eine Änderung vornehmen, die vermutlich aber nur im Umbennenen der Option und Umkehrung der Funktion besteht.

Beide meiner Vorschläge widersprechen dem, was Sebastian bereits umgesetzt hat und es würde sicher etwas zu Verwirrungen führen, wenn es jetzt noch einmal geändert wird. Und ich möchte auch klar betonen, dass es Sebastians Entscheidung ist und ich mich nicht darin einmischen möchte, wie er seine Plattform gestaltet, denn am Ende haftet er womöglich. Langfristig macht es aus meiner Sicht aber schon Sinn, hier eine durchdachte Lösung zu finden, die für Podcaster möglichst einfach bedienbar ist (deshalb wenn Opt-out, weil wahrscheinlich selten) und es Entwicklern wie @funkenstrahlen und @phranck ermöglicht, in einer App auch wirklich ein großes Angebot der streamenden Podcasts zu präsentieren.

Danke für’s Lesen, gute Nacht

simondueckert · 2017-07-04T21:46:07.881Z

Wir sind ja im Podcasting nicht die ersten, die mit dem Thema Rechte an Metadaten zu tun haben. So sehr mir die Idee völlig freier Metadaten in Feeds gefällt, sehe ich doch auch im Bereich des Bloggings Urteile, die die Verwendung von Metadaten als Urheberrechtsverletzung sehen (http://www.zdnet.de/41539840/urheberrechtsverletzung-durch-einbinden-eines-rss-feeds, http://www.moenikes.de/ITC/2011/06/28/rss-feeds-einbinden-ohne-entsprechende-rechtseinraumung-ist-rechtswidrig).

Tim’s Argument, die Podcatcher Apps nutzen die Metadaten auch, stimmt zwar, ich kann aber auch verstehen, dass sich wenig risikofreudige Entwickler dieser möglichen rechtlichen Gefahr nicht aussetzen möchten. David Weinberger hat mal in einer tollen Rede in der Library of Congress (http://www.hyperorg.com/blogger/2004/11/21/library-of-congress-mp3s/) gesagt, das online die Grenze zwischen Daten und Metadaten verschwimmt und genau in diesem Graubereich sind wir hier.

343max · 2017-07-05T02:58:21.794Z

Erst mal möchte ich hier sagen, wie sehr ich mich freue, dass jemand einen Studiolink Client für iOS zu bauen. WMR hat schon 14 Follower, was mehr ist als ich gedacht hätte. Ich schau mir den noch mal etwas genauer an und werde ihn gerne kräftig bewerben wenn er funktioniert. Die 4$ die ich abdrücken musste finde ich angemessen. Ich weiß wie schwer es ist mit iOS Software Geld zu verdienen und werde mich nicht über Preise für eine gute App beschweren die weniger kostet als ein Kaffee. Danke für die ganze Arbeit!

Des weiteren finde ich ja sehr erleichternd, das – anders als ich anfangs befürchtete – niemand abgemahnt wurde oder juristisch bedroht oder sonst wie angepisst wurde sondern sich alles ja doch in einem zivilisiertem Rahmen bewegt und jeder mit jedem redet. Da finde ich den ganzen Aktionismus mal eben alle Podcasts rauszukegeln und die Wortwahl dann doch ziemlich übertrieben und unglücklich. Soweit ich das überschauen kann hat hier niemand irgendwen zu irgendwas gezwungen. Ich halte auch das Risiko einer Abmahnung für relativ gering und das finanzielle Risiko für überschaubar. Wenn euch was a eurer App liegt solltet ihr sie nicht ohne Not so beschneiden, weil ich die Angst, dass die meisten Podcasts aus Unwissenheit oder Verpeiltheit nicht dabei wären für extrem berechtigt halte. Hätte ich nicht zufällig auf einen Tweet geantwortet hätte ich diese ganze Diskussion hier nie mitbekommen. Irgendwann hätten sich dann vielleicht mal Hörer bei mir beschwert und alles wäre unnötig kompliziert und langwierig gewesen. Um ehrlich zu sein: weil ich heute nicht mehr an den Rechner komme und morgen nicht mehr dran denke kann es immer noch passieren, das ich vergesse mich einzuopten. Und wenn nicht für WMR dann eben für nerds.fm, sobald man mehr als einen Podcast haben kann. Bitte, macht es zumindest opt-out und nicht opt-in.

Und meine Meinung zu der ganzen Debatte nun auch noch: es sollte keine Möglichkeit zum opt-out geben. Zum einen halte ich die Interpretation der CC-Lizenz, das sie sich auch darauf bezieht, das sie nicht innerhalb einer kommerziellen Software dargestellt/angespielt werden darf für arg talibanesk. Nach der Logik dürften CC-NC Bilder/Videos/Musik auch nicht in kommerziellen Browsern wie Safari, Edge oder Chrome abgespiegelt werden, oder auf kommerziellen Hardwareplayern oder Autoradios. Ich finde diese Interpretation als juristischer Laie zumindest extrem abwegig. Damit kommen wir zum zweiten Punkt: meine Tweets stehen schon seit Jahren unter einer CC-NC Lizenz, was übrigens die Welt Kompakt mehrfach nicht davon abgehalten hat mich ungefragt abzudrucken. Was würde nun Twitter tun wenn ich sie auffordern würde meine Tweets nicht mehr in kommerziellen Clients wie Tweetbot anzuzeigen? Falls sie überhaupt reagieren würden würden sie mir vermutlich freundlich daraufhinweisen, dass ich ja gern meinen Account löschen kann. Und das solltet ihr auch tun (das hinweisen, nicht das löschen). Es macht die Software für euch als Entwickler, für die Hörer und für die Macher unnötig komplizierter und senkt ihren Nutzen enorm. Es dürfte den Supportaufwand um einiges erhöhen. Wenn man eine Schnappatmung bekommt, weil sich jemand nebenbei mit seiner kostenlosen geilen Infrastruktur ein Trinkgeld dazu verdient dann ist die Lösung des Problems ganz einfach: einfach die Plattform nicht mehr nutzen. Aber so weit ich das sehe scheint das in diesem Thread ja wirklich niemand zu wollen, weswegen es ja noch absurder ist, warum es das Feature und die Diskussion überhaupt gibt.

rstockm · 2017-07-05T07:19:03.213Z

Mal eben auf der Metaebene:

343max:

Da finde ich den ganzen Aktionismus mal eben alle Podcasts rauszukegeln und die Wortwahl dann doch ziemlich übertrieben und unglücklich. [/quote]

…

[quote]Und meine Meinung zu der ganzen Debatte nun auch noch: (…) Zum einen halte ich die Interpretation der CC-Lizenz, das sie sich auch darauf bezieht, das sie nicht innerhalb einer kommerziellen Software dargestellt/angespielt werden darf für arg talibanesk.

<3

Das ist so perfekt-typisch Internetforum: Man ärgert sich so über die übertriebene Wortwahl aller Schreibenden, dass man 10 Zeilen später erst mal die dickste Wortkeule des ganzen Threads rauspackt

Aber dass sich @343max und ich einmal in irgendwas inhaltlich einig sind, kommt auch mal gar nicht so häufig vor

johannes_k · 2017-07-05T08:38:59.729Z

derrobert:

(warum das im Einzelnen auch immer der Fall sein sollte - hier sollten wir meiner Meinung nach immer die Entscheidung des Einzelnen zunächst akzeptieren, so sinnlos sie uns persönlich auch vorkommen mag)

Ich denke nicht, dass man die sinnlosen Entscheidungen Einzelner akzeptieren muss/sollte. Das ist zwar erstmal „nett“ gedacht, aber wenn man diese Einstellung weiter denkt höchst gefährlich.

derrobert · 2017-07-05T13:49:28.611Z

Weiß zwar nicht, was daran gefährlich sein soll, die Standpunkte anderer Menschen als solche zu akzeptieren, aber es hat ja niemand gesagt, dass auf alle Meinungen oder Inputs auch sofort reagiert werden soll.

Grundsätzlich geht es doch nur darum nicht alle Feature-Wünsche sofort als “Blödsinn” abzutun, nur weil man sich selber in diesem Moment nicht vorstellen kann, wozu das gut sein soll. Nicht mehr aber eben auch nicht weniger.

funkenstrahlen · 2017-07-05T15:08:34.751Z

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.

sreimers · 2017-07-05T15:41:27.793Z

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.

phranck · 2017-07-05T16:22:30.853Z

sreimers:

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.

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?

rstockm · 2017-07-05T19:52:08.019Z

sreimers:

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.

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.

lukasbestle · 2017-07-06T05:37:01.194Z

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.

funkenstrahlen · 2017-07-10T10:51:47.671Z

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

Sendegarten

SEG027 Strahlenblüten

Stefan Trauth (@funkenstrahlen) Das Internet, ein rechtsfreier Raum? Mitnichten. Auch und gerade in der Online-Welt ist es ratsam, Recht und Ordnung zu wahren. Insbesondere bei Angeboten, die sich an die allgemeine Öffentlichkeit richten. Viel zu...

funkenstrahlen · 2017-07-14T12:57:48.287Z

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:

Podlive

Podlive - Never miss a live streaming podcast

Never miss a live streaming podcast

funkenstrahlen · 2017-09-20T06:38:01.135Z

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

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:

Simulator Screen Shot - iPhone 7 Plus - 2017-08-21 at 15.32.19_iphone7plusgold_portrait.jpg2000×2000 199 KB

Simulator Screen Shot - iPhone 7 Plus - 2017-08-21 at 15.32.07_iphone7plusgold_portrait.jpg2000×2000 192 KB

Simulator Screen Shot - iPhone 7 Plus - 2017-08-21 at 15.32.28_iphone7plusgold_portrait.jpg2000×2000 230 KB

Simulator Screen Shot - iPhone 7 Plus - 2017-08-21 at 15.32.10_iphone7plusgold_portrait.jpg2000×2000 292 KB

h2m · 2017-09-21T19:06:52.731Z

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?

funkenstrahlen · 2017-09-21T19:20:11.914Z

h2m:

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.

john_dillinger · 2017-10-12T09:34:52.439Z

Hi @funkenstrahlen,

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

vgl:

2017-10-12 11.31.53.jpg1242×2208 333 KB

funkenstrahlen · 2017-10-12T18:13:25.428Z

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

john_dillinger · 2017-10-12T18:33:12.124Z

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

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