Ich bekomme immer wieder Klagen, dass Folgen in den Podcatchern zwar als vollständig runtergeladen aussehen, aber irgendwo mittendrin einfach abbrechen. Anscheinend tritt das Problem bei Android am häufigsten auf, zumindest kommen die meisten Klagen von Adroid-Usern. Ich habe nicht die leiseste Ahnung, woran das liegen kann und bitte um Hinweise*, die zur Lösung des Problems führen können.
*Bitte erklärt es mir, wie ihr es einem Kind (oder Deppen, ist ja im Prinzip dasselbe) erklären würdet!
Ich tippe mal auf Probleme mit HTTP Range Requests (also der Unterstützung des Ladens der Datei in mehreren Teilen). Soll ich mal ein paar Tests machen?
(OffTopic: Kinder sind keine Deppen, in diese Falle tappen am Anfang alle Eltern, und die Kinder verwenden das dann gegen uns…)
Das beobachte ich schon ‘ne Weile mit “podkicker” unter Android.
Ich behelfe mir mit “wget” unter Linux, das klappt problemlos.
Das nur als Hinweis. Dentaku könnte recht haben.
Scheiße. Gerade nochmal probiert. Ich kann’s nicht reproduzieren!
Sicher, dass das an dir liegt? Ich dachte bisher, das wäre ein Bug in AntennaPod gewesen, denn das fiel mir zum ersten mal auf, als das “automatisch herunterladen” Feature neu war. Ich könnt’s nicht beschwören, aber ich bilde mir ein, das sei auch bei anderen Podcasts vorgekommen. Und seit den letzten Updates von AntennaPod ist es auch nicht mehr passiert. Kann natürlich trotzdem alles eine große Verschwörung sein…
In Antennapod hatte ich auch das Problem. In Pocket Casts nicht mehr.
Bei BeyondPod ist mir das noch nicht aufgefallen.
Mir auch nicht.
Dem schließe ich mich mal an.
Ich konnte sowohl hier bei Wrint, als auch bei NSFW oder anderen Podcasts noch nie die gemeldeten Probleme nachvollziehen. Mit BeyondPod auf Nexus 7 (Stock 4.2.2) und HTC Desire (Android 4.04 ROM) funktioniert alles immer problemlos.
Habe mit Pocket Casts (http://www.shiftyjelly.com/android/pocketcasts) auch ein paar mal das Problem gehabt. Schob es aber auf das neue Release. Ich habe während der Downloads von wrint.de deutlich öfter Abbrüche und Fehler, als bei anderen Podcasts. Vllt. ist der HTTP-Server anders konfiguriert (Timeouts, Reconnects o.ä.), als z.B. in der Metaebene?
Wie gewünscht, mit Übersetzung Tech -> Holgi 😉
Ein kurzer Test, ob dein Server Range-Requests (Nerd-Sprech für “Downloads in Stückchen” ) unterstützt, zeigte keine Probleme.
Wenn, wie Frank schon sagte, wget (Kommandozeilen-Download-Tool) immer funktioniert, kann es durchaus sein, dass es Fehler bei den Clients sind.
Es wäre interessant, mit welchen Clients das Problem auftritt und ob es auch andere Podcasts betrifft.
Mit “podkicker” (Android) kann ich’s derzeit nicht reproduzieren.
Wenns der Fehlersuche hilft: Ich hole meine WRINT-Folgen so lange ich den Podcast kenne ausschließlich mit wget und hatte noch nicht ein einziges Mal irgendwelche Probleme.
Zu Podcatchern kann ich nichts sagen – ich bin ein alter Mensch und nutze so modernen Schnickschnack nicht 😉
chrysophylax.de
Ich benutze oefters mal diese “Stueckchendownload-Tools” aria2c und axel und lad die mir auf meinen iriver X20, einen guten alten MP3-Plaerrer. Mit beiden konnte ich bisher nie Probleme feststellen. Die Podcastfolgen konnten immer prima abgespielt werden.
Weiters benutze ich auch gpodder auf dem Desktop mit Linux und auf einem Nokia N9 mit MeeGo. Auch hier funktionierte bisher immer alles prima.
Muss wohl wirklich ein Problem bei einzelnen Clients sein… Tummerleid, dass ich nicht mehr helfen kann.
Also hier mein Problemfall:
Gerät: iPhone 5, iOS 6.1
App: Pocket Casts 3.x
Ich lasse mehrere Folgen laden (zuhause im Wlan) und verlasse die App. kann die App aus irgendwelchen Gründen das nicht machen, teilt sie es mir mit, ich stoße den Download nochmal an und dann klappt es auch und die Folge ist vollständig da.
Das trifft auf alle Podcasts zu, bis auf eben Wrint. Da scheint es so dass er beim Laden im Hintergrund die folge nicht richtig lädt, es aber als vollständig anzeigt und beim hören dann mittendrin abbricht. Nochmaliges Laden (und die ganze Zeit auf die App starren) hilft.
Jetzt heute wieder das selbe, nur diesmal kann ich nichtmal die aktuelle folge laden, er fängt kurz an und bricht ab und zeigt sie als vollständig an.
(
Frag beim nächsten mal die User welchen Client sie benutzen. Ich tippe auch sehr stark darauf dass einzelne Clients beim Download bzw. beim fortsetzen von Downloads patzen.
Aufm IPhone mit Instacast sowie der offiziellen Podcastapp nie ein Problem gehabt.
Die da oben machen doch eh was sie wollen!
Leider kann ich nicht helfen aber das Problem hab ich unter Windows, Linux sowie Android, Ob ich nun Chrome, Firefox oder Opera benutze ist egal bricht immer ca. 5 min. ab.
Mit der App Byondpodcast hab ich hingegen kein Problem unter Android.
Ich erinnere mich, dass hier auch lange Zeit Probleme mit den Website-Downloads bestanden. Da brach der Download einfach zwischendurch ab. Mein Browser hat den Download dann auch einfach als “vollständig” angezeigt, nur halt mit 12 MB statt mit 60. Das fiel mir dann auch irgendwann auf, als die Folgen einfach mittendrin abbrachen. Als ich den Download dann in den Download-Manager warf, brach es dort auch öfter ab, aber da konnte ich den weiteren Download immer wieder anstoßen. Das ist zwar alles kalter Kaffee, weil die Desktop-Downloads in den letzten Monaten eigentlich anstandslos funktioniert haben, klingt aber nach demselben Problem, nämlich zwischendurch beendeten Downloadverbindungen. Sowas können Programme wie wget, die ja nur für Downloads konzipiert sind, wesentlich besser abfangen. Natürlich hängt es dann auch mit den Clients zusammen, da diese ggf. einfach einen http-Slot öffnen und den solange befüllen, bis das Abbruch-Signal kommt. Hochwertigere Clients machen da ggf. mehrere Slots auf, überprüfen das Ergebnis, solche Spielereien.
Ich werf das allerdings nur für mögliches Troubleshooting hilfsbereiter Leute ein. Wie man solchen Problemen serverseitig begegnen kann, weiß ich nämlich nicht. Aber: Was hast du denn getan, um die normalen Downloads problemloser durchzuschleusen? Vielleicht kann man da ja nochmal was drehen. 🙂
LG
esureL
hatte ich mit chrome schon öfters…meist in intenetcafes
Yep, hatte ich genau so auch mehrfach (Download mit Firefox, sowohl unter Win XP als auch Win Vista). Ist jetzt aber schon seit einigen Wochen nicht mehr passiert.
Hallo,
ich dachte schon ich wäre ein Einzelfall. 🙂
Meine Specs:
– iPhone 4S
– iOS 6.1.3 (der Bug trat allerdings in vergangenen iOS-Versionen ebenfalls auf)
– App: Pocket Casts, Version 3.6.1 (trat hier aber ebenfalls in vergangenen Versionen auf)
– ausschließlich Wrint-Podcasts
– WLAN sowie UMTS (Fehler tritt bei beiden auf)
Problem:
Wie bereits von Holgi beschrieben werden mir die Folgen als komplett heruntergeladen angezeigt, sind sogar abspielbar, hören dann allerdings mittendrin auf. Konnte es auch schon live beobachten: auf herunterladen getippt, dann lud er 1-2 MB runter und dann wird die Folge als fertig angezeigt.
Das Problem beschränkt sich bei mir nicht auf wenige MB’s, er lädt auch mal 50 von 90 MB usw…
Meine bisherige Not-Lösung:
Wenn eine Episode von diesem Bug betroffen war, löschte ich ihn einfach aus dem Catcher und holte ihn danach wieder rein (bei “Pocket Casts” geht das über einen Button der sich “Browse old episodes” nennt), sodass er mir anschließend wieder als ungelesene Episode angezeigt wird, dann lud ich ihn mit Erfolg erneut herunter. Falls das beim ersten Mal nicht funktioniert, wiederhole ich den Schritt einfach bis es klappt.
Das ist keine Lösung des Problems, allerdings verpass ich so erstmal keine Podcasts die ich hören möchte.
Wenn das Problem wirklich beim Server liegt, könnte das auch die Abbrüche im Podlove Web Player erklären. Da konnten wir bisher ja auch keinen Fehler feststellen.
Bevor ich auf Android umgestiegen bin hatte ich das Problem auf meinen iPhone mit der APP “podcaster” auch.
Was mir damals aufgefallen ist: scheinbar war es so, dass die Downloads, auch mehrfach hintereinander (!), besonders dann mittendrin abgebrochen haben, wenn die Episode noch recht neu war.
Mit beyondpot auf Android habe ich übrigens keine Probleme mehr.
Das Problem hatte ich bis vor einiger Zeit auch, meistens wenn ich die Folge zeitnah nach dem Release runtergeladen habe. Es trat immer nur bei Wrint-Downloads auf, alle anderen Podcasts waren immer problemfrei. Seit einiger Zeit funktionieren alle Downloads allerdings vollständig und problemfrei. Ich Benutze Android mit Podkicker bzw. Podkicker Pro.
Ich konsumiere schon wirklich extrem viel (IMHO), und ca 200 Feeds liegen im Podcatcher (ich nutze BeyondPod).
Der beschriebene Fehler trat hier exakt NIE auf 😉
Ha, und ich dachte, das liegt nur bei mir, da ich Linux (meist Ubuntu) nutze und irgendwas bei mir im Argen liegt.
Aber es stimmt. Das passiert mir nur beim Holgi. Sonst nirgends. Und ich bin wahrlich ein Podcastjunky.
Also Ubuntu+Chromium ist meine häufigste Kombination.
Falls das jemanden weiter hilft.
Gruß
BrEin
Ich hatte das Problem vor einer Weile beim Laden mit langsamen Verbindungen, allerdings nicht unter Android, sondern unter Linux. Mit langsamer Verbindung meine ich 56k, da über eine Mobilverbindung, die aufgrund ausgeschöpften Inklusivvolumens gedrosselt war. Fortsetzen des unvollständigen Downloads war jedoch möglich (als Browser verwendete ich Opera). Ich dachte zuerst, dass es an der Mobilverbindung selbst liegen würde, kann mich jetzt allerdings nicht daran erinnern, das Verhalten damals auch beim Download größerer Dateien und entsprechend langer Downloaddauer von anderen Webseiten erlebt zu haben. Wenn sich jetzt hier viele Androidnutzer melden, kann das vielleicht auch mit langsamen Verbindungen zusammenhängen, falls die Downloads im Hintergund auf Mobilgeräten liefen und es ein Problem mit langsamen Verbindungen gibt.
Ich habe auch das Gefühl, dass es nur bei frischen Podcasts passiert. Wie ist denn der Releaseprozess? Kann es sein, dass eine Folge schon announced wird, bevor sie vollständig hochgeladen wurde?
Kann man in den Serverlogfiles etwas zu den unvollständigen Downloads finden? Der Server muss ja mitkriegen, dass nicht vollständig heruntergeladen wurde. Zum Beispiel würde ich mal eine oder zwei Folgen nehmen und die entsprechenden Zeilen rausgreppen. Vielleicht sieht man da was.
Auf die Ursache würde ich auch tippen, jedenfalls hatte ich das Problem mit “Verstümmelungen” immer nur bei ganz frischen Folgen.
Könnte sein. Bisher war es bei mir nur wenn der Download im Hintergrund lief, wenn ich noch in der App war konnte ich sehen wie die App (Pocket Casts auf iOS6) die Folge geladen hat und alles war schick.
Heute ist es sogar so dass ich die aktuelle Folge gar nicht laden kann, weder via Wlan noch 3G.
Bei mir passiert es übrigends mit PocketCasts unter Android ständig. Es passierte mit der 3.x-Version und nun mit der 4.x-Version.
Hab das Problem auch:
macbook, Chrome und Firefox
Ich hab ein vergleichbares Problem:
Download bricht nach einiger Zeit einfach ab und es wird “Fehler” angezeigt. Jetzt als Test gerade WRINT 167 bei 2,3MB. Also passiert es nicht nur bei neuen Folgen. Nach einem Download-Neustart läuft es dann meist problemlos durch.
Mein System:
Opera 12.14 64Bit unter Windows 7.
Momentan gleichzeit WRINT 166-169. Die anderen Downloads gehen ohne Probleme weiter.
Mir passiert es mit ziemlicher Regelmäßigkeit, dass deine Podcasts abbrechen, wenn ich sie in Amarok (unter Linux) streame. Ich behelfe mir immer damit die Folge explizit herunterzuladen und offline anzuhören (ebenfalls mit Amarok). Das geht eigentlich immer problemlos.
Ja, genau das konnte ich auch beobachten als ich letztens eine URL zur einer Folge in den Music Player Daemon gepackt habe, das ging dann 2 minuten gut, und dann war Ende.
Habe das dann noch mit mpg123 und gst123 probiert, gleiches Problem.
Ich könnte mir vorstellen, dass es ein Timeoutproblem ist, der Client macht sich den Puffer voll spielt ab, und bis der Puffer kritisch leer wird hat der Server die Verbindung geschlossen oder so.
Naja, ich kann auch mal nen TCP-Dump mitlaufen lassen.
Bei mir kommt es häufig vor, dass die WRINT-Folgen bei der Wiedergabe auf dem iPod (3. und 7. Generation) noch einmal von vorne starten, meistens nach den ersten drei bis sechs Minuten. Angezeigt wird mir aber, dass die Zeit durchläuft.
Das Problem tritt definitiv nicht nur unter Android auf sondern auch unter Linux/Windows Firefox/Chrome (alle 4 Kombinationen, jeweils manueller Download im Browser). Tippe auf ein Lastproblem des Servers. Was hst du denn hier? Root-Server? V-Server? Managed? Was ganz anderes? Kommst du an die Log-Dateien deines Web-Servers heran? Ich vermute da wirst du am ehesten fündig.
Bei mir (Windows 7/Chrome) tritt das Problem auf, wenn ich über den Player auf der Seite höre. Es bricht dann nach wenigen Minuten ab. Downloads über den Browser funktionieren stets reibungslos.
Gleiches Problem, jedoch bei:
– Direktdownload der mp3-Datei über Mozilla von der Seite
– Copy/Paste ins Android-System
– Abspielen mit dem Standard-Androidplayer
Problemlösung liegt mir fern. da fehlt mir leider der mögliche Hintergrund.
Vermutlich liegt es an deinem Server.
Auf deiner website bricht der stream momentan auch immer ab.
Im podlover player (der hat für mich auf wrint.de allerdings noch nie funktioniert – auf anderen websiten einschalfenpodcast, kuechenradio funktioniert er tadelos) sowohl als auch wenn man das mp3 im browser stream.
Hier auch, Chrome Version 26.0.1410.65 am Mac.
Das Problem kann ich unter Win7 mit FF bestätigen, wirklich Hilfestellung zur Lösung kann ich leider nicht bieten, aber die Datei wird als korrekt runtergeladen angezeigt, auch im abspielen steht da bspw. “3h 50m”, bricht dann aber irgendwann ab. Beim erneuten herunterladen ist alles i.d.R. in Ordnung
Tritt bei mir auch auf. Windows 7 Home mit Firefox und Chrome. Hab das Gefühl dass das Problem meistens auftritt wenn ich mehrere Dateien gleichzeitig herunterlade. Ich kann die Dateien zwar abspielen, aber sie brechen dann auch irgendwann ab.
Dachte zuert, dass würde an meiner Internetverbindung liegen…
Leider hier gerade das gleiche Sympthome beim spulen/springen und dann beim weiterhören abbrüche. technische Daten: Ubuntu 12.4 und als abspielprogramm habe ich bis eben totem genutzt. Allerdings hab ich auch ein DSL2000-Krepel-Internet, *kann* daran liegen, aber um diese Uhrzeit wirds nicht der TRaffic sein. Ich probier nun mal VLC, vielleicht ist der robuster und morgen dann auch andere Folgen außer der 172. Nun geh ich schlafen, lohnt sich sonst nicht mehr :>
Ok, kannste knicken. VLC hat auch abbrüche, wenn man pausiert, läuft durch, wenn man nichts daran macht. Also Pausieren des Downloads oder des Streams scheint bei mir der Knackpunkt zu sein.
das problem habe ich schon seit etwa einem jahr bei dir beobachtet. auschnitt aus dem aktuellen “downloadversuch” von WR170… (mittels wget)
2013-04-25 11:07:21 (80.1 KB/s) – Connection closed at byte 13049070. Retrying.
dein server ist ueberlastet und fast alle clients denken, ohh der server hat die connection geschlossen, na dann wird die datei schon da sein, selbst chrome und firefox verhalten sich so (der podlove player hat das gleiche problem)
wget fragt den server vorher, wie gross die datei ist und kriegt dann raus, dass da noch was fehlt und versucht es noch mal ab der stelle, wo es abbrach (ohne die ganze datei neu zu laden…)
was kannst du machen? nicht viel ausser dickeren server zu kaufen, oder einfach nicht unendlich viele download requests gleichzeitig annehmen, ich habe aber keine ahnung, was normale podcast clients dann machen, vielleicht kann das ja jemand anderes hinzufuegen
Seit Anfang immer mit BeyondPod unter Android – gab nie irgendein Problem (auch nicht nach Download Unterbrechungen).
Falls es hilft, habe das Problem sporadisch (zuletzt mit WR172) und nur bei WRINT Podcasts unter folgendem Setup
Android 2.3.x
Podkicker
Android 4.2.2
Podkicker und PodkickerPro
Bisher habe ich eine 100% Downloadmeldung nach wenigen MB nicht feststellen können, da die Poscasts automatisiert runtergeladen werden, wenn Strom un WLAN da sind, werde aber in Zukunft mal drauf achten.
Ich lade die Podcasts immer manuell (Rechtsklick speichern) im Safari (OS X). Dabei
habehatte ich wie cnagon das Gefühl als würde das Problem besonders dann auftreten, wenn ich mehrere deiner Podcasts gleichzeitig lade. Kommt leider ab und an vor, dass ich so wie heute auch mal drei vier Folgen (wurden gerade geladen) im Rückstand bin. Allerdings trat das Problem zum letzten mal vor einigen Monaten auf. Auch heute stimmen die Dateigrößen im Finder recht genau mit den Angaben im Blog überein.Bei mir wurde die Gregor-Gysi-Folge nicht vollständig geladen, obwohl der Downloader es dachte.
Habe nicht alle Kommentare gelesen, daher kann ich nicht sagen ob das hier schon Thema war:
Microsoft Equipment, manuelles Downloaden (rechtsklick, speichern unter)
Wenn ich mehrere Podcast gleichzeitig downloade, passiert es regelmäßig, dass einer nur teilweise geladen wird. Daher immer nur einen nach dem anderen absaugen. Oder FeedReader benutzen, der nimmt die sich einer nach dem anderen vor.
Soviel zu meinen “Problemen”
bei mir (win7) brechen die mp3 seid ein paar Wochen immer weg. und das mehrmals währen des hörens. Das erste mal ist immer bei min. 2:52 . Das nächste mal bei ca. 32 min. Und dann noch ein paar mal wo ich die Zeiten jetzt nicht parat habe. Dies passiert immer an den gleichen Zeit Marken.
Trotzdem weiter so, Holgi 😉
Mir ist vorhin etwas aufgefallen. Im Feed wird die Folge WR170 mit der Länge fileSize=”33647759″ angegeben. Die heruntergeladene Datei dagegen ist 33693317 Bytes lang. Sowas sollte doch eigentlich nicht vorkommen.
Hmm… vielleicht weil ich das Audiofile zwischenzeitlich mal ausgetauscht habe?
Passiert das öfter? Wenn ein Client nur das herunterlädt, was im Feed angegeben ist, könnte er zu wenig herunterladen?
Hier wurden mehrere relativ konkrete Fälle angegeben. Ich würde empfehlen mit einer Person deines Vertrauens mal die Logfiles durchzugehen und sich die Einträge zu den entsprechenden Folgen anzuschauen. Da Wrint der einzige Podcast ist, der das Problem bei mir hat, tippe ich sehr stark auf ein serverseitiges Problem, auch wenn es nur mit bestimmten Clients wie dem Android-Downloader auftritt.
Falls es hilft, ich habe das Problem auch:
ich höre immer über die website.
Win7 64x mit Chrome (Version 26.0.1410.43 m)
Hab das Problem, das der Podcast mittendrin abbricht oder von vorne anfängt, bei fast jeder folge von Holgi selten bei Hoaxilla.
Wie wäre es einen Testfeed zu starten?
Dort wird vorher angekündigt wann “neue” Dateien veröffentlicht werden, wobei egal ist was das für Dateien sind, das können alte WRINTfolgen sein oder auch nur eine Stunde Stille.
Wenn ein Tester feststellt das sein Download fehlschlägt, dann schreibt er seinen Client, IP, ISP und die Uhrzeit des Downloads in die Kommentare der jeweiligen Testfolge.
So müsste man anhand der Logs und Kommentare, mit ein wenig Programmier- oder Excelmagic, erkennen mit welchen Konfigurationen Probleme auftreten.
Z.b. ob die Downloadabbrüche zu bestimmten Zeiten geschehen. Entweder weil der Server überlastet ist wegen der vielen gleichzeitgen Downloads oder ein anderes Hintergrundprogramm (Backup/Update?) zu viel Ressourcen benötigt.
Andere Möglichkeiten wären, das nur bestimmte Folgen Probleme bereiten, das Nutzer mit Problemen den gleichen ISP haben der an ihren Paketen schraubt, bestimmte Downloadprogramme fehlerhaft sind, …
Wenn sich sich daraus keine Fehlerquelle ableiten lässt, wäre es eine gute Zeit den Server mit allem neu aufzusetzen (wie es, glaube ich, in NSFW schonmal angesprochen wurde), oder neue Folgen nur noch per Schallplatten und MCs zu vertreiben 🙂
Hallo Holgi,
wenn es so viele verschiedene Clients betrifft, wird es wohl eher kein Client-Problem sein.
Der Server beendet die Verbindung sporadisch. lanthan vermutet weiter oben ein Lastproblem. Das kann durchaus sein. Die Ursache dafür wirst Du wahrscheinlich im Webserverlog oder im Syslog finden. Wenn Du nicht weißt, wo Du gucken mußt, frag Tim! 😉 l
Mein wget unter Linux hat die Datei gerade in sensationellen 6 Teilstücken herunterladen können. (Immerhin unterstützt der Webserver Partial Content. Sonst hätte das im Moment gar nicht geklappt.)
Um den Fehler mit Hilfe der Logfiles einzugrenzen, können übrigens genaue Uhrzeiten helfen. wget hat sie bei meinem Download dazugeschrieben, siehe unten.
Viel Erfolg! 🙂
MfG
Schlaftablette
Twitter: @fernsehchat
--2013-04-29 19:01:18-- http://wrint.de/download/WR174_Im_arabischen_Raum_ist_die_Kniegeburt_anders_konnotiert.mp3
Auflösen des Hostnamen »wrint.de«... 178.77.85.90, 2a01:488:42:1000:b24d:555a:43:9054
Verbindungsaufbau zu wrint.de|178.77.85.90|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 302 Found
Platz: http://www.wrint.de/Files/WR174_Im_arabischen_Raum_ist_die_Kniegeburt_anders_konnotiert.mp3[folge]
--2013-04-29 19:01:19-- http://www.wrint.de/Files/WR174_Im_arabischen_Raum_ist_die_Kniegeburt_anders_konnotiert.mp3
Auflösen des Hostnamen »www.wrint.de«... 178.77.85.90, 2a01:488:42:1000:b24d:555a:43:9054
Wiederverwendung der bestehenden Verbindung zu wrint.de:80.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 61553960 (59M) [audio/mpeg]
In »»WR174_Im_arabischen_Raum_ist_die_Kniegeburt_anders_konnotiert.mp3«« speichern.
10% [===> ] 6.448.038 17,8KB/s in 68s
2013-04-29 19:02:27 (92,8 KB/s) - Verbindung bei Byte 6448038 geschlossen. Erneuter Versuch.
--2013-04-29 19:02:28-- (Versuch: 2) http://www.wrint.de/Files/WR174_Im_arabischen_Raum_ist_die_Kniegeburt_anders_konnotiert.mp3
Verbindungsaufbau zu www.wrint.de|178.77.85.90|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 206 Partial Content
Länge: 61553960 (59M), 55105922 (53M) sind noch übrig [audio/mpeg]
In »»WR174_Im_arabischen_Raum_ist_die_Kniegeburt_anders_konnotiert.mp3«« speichern.
36% [++++=========> ] 22.582.894 23,6KB/s in 2m 2s
2013-04-29 19:04:30 (129 KB/s) - Verbindung bei Byte 22582894 geschlossen. Erneuter Versuch.
--2013-04-29 19:04:32-- (Versuch: 3) http://www.wrint.de/Files/WR174_Im_arabischen_Raum_ist_die_Kniegeburt_anders_konnotiert.mp3
Verbindungsaufbau zu www.wrint.de|178.77.85.90|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 206 Partial Content
Länge: 61553960 (59M), 38971066 (37M) sind noch übrig [audio/mpeg]
In »»WR174_Im_arabischen_Raum_ist_die_Kniegeburt_anders_konnotiert.mp3«« speichern.
41% [++++++++++++++=> ] 25.779.349 20,8KB/s in 62s
2013-04-29 19:05:34 (50,4 KB/s) - Verbindung bei Byte 25779349 geschlossen. Erneuter Versuch.
--2013-04-29 19:05:37-- (Versuch: 4) http://www.wrint.de/Files/WR174_Im_arabischen_Raum_ist_die_Kniegeburt_anders_konnotiert.mp3
Verbindungsaufbau zu www.wrint.de|178.77.85.90|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 206 Partial Content
Länge: 61553960 (59M), 35774611 (34M) sind noch übrig [audio/mpeg]
In »»WR174_Im_arabischen_Raum_ist_die_Kniegeburt_anders_konnotiert.mp3«« speichern.
74% [++++++++++++++++============> ] 46.139.164 25,3KB/s in 2m 32s
2013-04-29 19:08:09 (131 KB/s) - Verbindung bei Byte 46139164 geschlossen. Erneuter Versuch.
--2013-04-29 19:08:13-- (Versuch: 5) http://www.wrint.de/Files/WR174_Im_arabischen_Raum_ist_die_Kniegeburt_anders_konnotiert.mp3
Verbindungsaufbau zu www.wrint.de|178.77.85.90|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 206 Partial Content
Länge: 61553960 (59M), 15414796 (15M) sind noch übrig [audio/mpeg]
In »»WR174_Im_arabischen_Raum_ist_die_Kniegeburt_anders_konnotiert.mp3«« speichern.
99% [+++++++++++++++++++++++++++++=========> ] 61.473.379 24,4KB/s in 2m 0s
2013-04-29 19:10:13 (125 KB/s) - Verbindung bei Byte 61473379 geschlossen. Erneuter Versuch.
--2013-04-29 19:10:18-- (Versuch: 6) http://www.wrint.de/Files/WR174_Im_arabischen_Raum_ist_die_Kniegeburt_anders_konnotiert.mp3
Verbindungsaufbau zu www.wrint.de|178.77.85.90|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 206 Partial Content
Länge: 61553960 (59M), 80581 (79K) sind noch übrig [audio/mpeg]
In »»WR174_Im_arabischen_Raum_ist_die_Kniegeburt_anders_konnotiert.mp3«« speichern.
100%[+++++++++++++++++++++++++++++++++++++++>] 61.553.960 163KB/s in 0,5s
2013-04-29 19:10:18 (163 KB/s) - »»WR174_Im_arabischen_Raum_ist_die_Kniegeburt_anders_konnotiert.mp3«« gespeichert [61553960/61553960]
BEENDET --2013-04-29 19:10:18--
Verstrichene Zeit: 9m 0s
Geholt: 1 Dateien, 79K in 8m 44s (154 B/s)
Reine Verbindungsabbrüche können es ja auch nicht sein. Jeder Podcastclient kann eigentlich damit umgehen. Es gibt auch keine Probleme, wenn man das WLAN verlässt, während noch heruntergeladen wird. Verbindungdsabbrüche sind Teil des Internets. Trotzdem ist das ein guter Anhaltspunkt.
Hi Christoph! Naja. Gleich fünf Verbindungsabbrüche beim Download einer 80-MB-(oder so)-Datei sind ja nun wirklich nicht normal. Offenbar kommen manche Podcast-Player unter gewissen Umständen ja gerade nicht mit diesen Abbrüchen zurecht, denn sonst würden sie ja keine solchen Probleme mit dem Abspielen haben. Wenn Holgi irgendwo suchen (lassen) muß, dann bei diesen Abbrüchen. Die Podcast-Player-Programmierer könnten sich dann zusätzlich noch hinter die Ohren schreiben, ihre Clients etwas robuster zu gestalten, denn da ist bestimmt auch noch irgendwo der Wurm drin, da Holgis Webserver Partial Content ja unterstützt, wie auch wget zeigt. Oder anders formuliert: Ja, es liegt nicht nur an den Abbrüchen, sondern auch an den Playern. IMHO.
Ich habe diverse Podcast in der Podcast-Funktion eines Squeezebox Radio. Funktioniert mit allen einwandfrei ausser bei WRINT, die Folgen werden gestreamt und brechen dann meist nach ca. 20min einfach ab bzw. fangen von vorne an.
Moin,
mich verwirren die ganzen Erklärungsmodelle da oben arg. Bin aber auch echt nicht vom Fach, dazu nicht mal sonderlich interessiert.
Bei meinen Downlods scheint es noch eine weitere Variante des Problems zu geben:
Der Abspielvorgang verschiedener Podcasts beginnt ganz normal, jedoch fängt nach einigen Minuten der Podcast wieder von vorne an, obwohl er in der Zeitleiste (Anzeige) ganz normal weiterläuft.
Zuerst hatte ich den iPod als Fehlerquelle im Verdacht, der scheidet aber aus.
Ich nutze itunes zum Herunterladen von Podcasts und Firefox als Browser.
So weit, so gut. Mein Problem ist eine unglaublich langsame Internetverbindung (unter 1000), ich wohne auf´m Land…Und genau da vermute ich das Problem.
Gerade dann würde ich aber doch immer erst die Audios runterladen! (wobei das ja auch nicht immer gut zu funktionieren scheint)
Moin,
Ich nutze AntennaPod unter Android , und bei mir tritt das Problem auch regelmäßig auf. Fehlerfreies Abspielen ist bei mir allerdings meist möglich, wenn ich die folge lösche und anschließend streame, anstatt sie erneut vollständig herunterlade.
Mit abgebrochenen Downloads scheint AntennaPod kein grundsätzliches Problem zu haben, bei anderen Podcasts wird einfach ein fehlgeschlagener Download angezeigt. Ein Lastproble des Servers würde mich eigentlich auch eher wundern, da bei mir eigentlich _keine_ WRINT Folge mehr fehlerfrei abespielt wird, egal wann ich sie herunterlade.
Hallo Holgi,
ich hab das Problem wenn ich das mit einem Client live hören will, also
mplayer
oder
mpg123
Ich vermute irgendwelche komischen Timeouts am Server, zumal mir der TCP-Dump gezeigt hat, dass der Server die Verbindung aktiv trennt. (Da kommt ein FIN-Paket vom Server).
Ohne die Konfiguration vom Server zu kennen, kann ich da leider auch nicht mehr dazu sagen.
Viele Grüße,
Danijel
Zefix, es braucht ne Vorschau funktion für Kommentare:
mplayer <url-zum-mp3>
mpg123 <url-zum-mp3>
So vielleicht?
Mit “komische Timeouts” kann ich leider wenig anfangen. Was ein TCP-Dump ist, weiss ich leider auch nicht. Erklär mir das mal so, dass ich es verstehe und den Leuten an der Hotline erklären kann.
Ein TCP-Dump ist ein Mitschnitt der Netzwerkkommunikation, also das was über das Kabel geht. Und da sieht man eben, dass der Server die Verbindung trennt. (In dem er ein Paket mit gesetztem FIN-Bit schickt). Besser geht’s nicht ohne jetzt ne Vorlesung über TCP/IP zu machen.
Timeouts sind halt so Einstellungen wie: Wenn der Client seit X Sekunden kein Paket mehr angenommen hat, dann trenne die Verbindung.
X wäre in diesem Fall zu klein. Aber das kann halt alles mögliche sein, eine Einstellung am Webserver, oder einer Firewall davor…