Frage aus Consumersicht: Feed-Aktualisierung relativ datenintensiv

Moin Sendegate,

Ich habe mal eine wahrscheinlich blöde Frage aus Hörendensicht.
Mir ist aufgefallen, dass beim Aktualisieren der Feeds in Antennapod, Podcasts, die über Podlove gehostet werden jedesmal ungewöhnlich viel Traffic verursachen.
Ich bin zur Zeit in meinem Handytarif in die Drossel gelaufen und habe jetzt ein paar mal beim Aktualisieren der Feeds das ganze unter dem Log Tab bei den Downloads beobachtet.
Während die allermeisten Feeds vom Status „Download anstehend“ direkt zu fertig gesprungen sind, wurden bei den auf Podlove gehosteten Podcasts jedesmal mehrere MB runtergeladen. Besonders auffällig war das bei Metaebene Produktionen, Lage der Nation und JSFP. Audiodump allerdings ist zum Beispiel nicht weiter aufgefallen.

Gibt’s dafür eine einfache Erklärung?
Eigentlich hätte ich erwartet, dass Feeds, die seit der letzten Abfrage nicht modifiziert wurden, nicht nochmal runtergeladen werden…

Sorry nochmal für die Noob-Frage und schönes Wochenende

Das ist die Frage wieviele Episoden dir zum Download angeboten werden. Du kannst nen Feed so einstellen dass dir vielleicht nur die letzten 10 angezeigt, werden, aber wenn du da die letzten 200 Episoden anbietest, dann lädt er auch die Metadaten der letzten 200 Episoden runter. Das läppert sich.

Ich nehme mal an, dass das auch an HTML-Shownotes liegen könnte. Das beobachte ich auch schon eine Weile, habe aber keine echte Lösung, weil auch nachgefragt wird, Links der Shownotes direkt in der App zu haben. Paged Feeds könnten hier helfen. Das ist mit Podlove möglich, wird aber von Apple nicht unterstützt und damit fallen in vielen Verzeichnissen Episoden raus. Das sorgt dann auch wieder für Nachfragen. Esist kompliziert.

Um die Größe der Feeds geht’s mir eigentlich primär gar nicht.
Ich zielte eigentlich eher darauf ab, warum überhaupt jedesmal was runtergeladen wird.
Wie gesagt springt das Gros meiner Abos direkt von Download anstehend zu erledigt, daher vermute ich, dass bei denen vom Server sowas wie „not modified“ geantwortet wird.
Und da ich zur Zeit gedrosselt bin, kann ich quasi jedem Bit einzeln die Hand schütteln…

Ach so. Daran hatte ich noch gar nicht gedacht. Wenn das irgendwie einstellbar wäre, wär das ja sehr gut.

Fuer das Problem der „staendigen Nachfrage“ und damit dem enormen Traffic-Overgead gibt es mittlerweile eine Lösung mit WebSub.

Ob sich WebSub wirklich verbreitet, wird m.E. einzig ökonomische Gründe haben, also ob Google, Apple … Spotify, Amazon … das Konzept aufnehmen. Da letztere aber schon gegen RSS aus allen Rohren schießen, bin ich eher skeptisch, dass sich eine vernünftige technische Lösung - allein aus der Kraft der Podcasterwassersuppe - durchsetzen wird.

Hier mal eine etwas vereinfachende Erklärung des zugrundeliegenden Problems und die Lösung dazu … https://blog.castopod.org/castopod-supports-websub/

Müsste nachgeforscht werden, warum genau die Clients hier den Feed ziehen. Der Feed sollte gleichbleibende etag / last-modified HTTP Header haben so lange sich darin nichts ändert, und dann sollten die Clients auch nicht den Feed laden.

Wobei z.B. Metaebene Feeds nicht direkt vom Publisher ausgeliefert werden, da ist noch ein Proxy dazwischen (nicht meiner :grimacing:). Die Lage hat wenn ich mich richtig erinnere auch eine angepasste Auslieferung. Möchte nicht ausschließen, dass der Publisher hier was falsch macht (wobei wir uns hier sehr auf die WordPress-eigene Feed-Auslieferung verlassen), aber es existieren auch viele angepasste Auslieferungswege, worauf ich nur hinweisen wollte.

Es gibt im Publisher auch ein PubSubHubbub Modul, aber nennenswert durchgesetzt hat sich der Ansatz nicht.