| | | Karsten_Strupp | | 9 Posts |  |
| | wrote on 20.10.17 at 02:35 | | Hallo,
seit einiger Zeit, ich vermute eins der letzten Updates, habe ich alle paar Minuten beim Abhören eines Radiostreams eine Verbindungsunterbrechung. streamwriter meldet: "Keine Daten für mehr als 20 Sekunden empfangen/gesendet" und verbindet sich neu.
Ich habe dann beobachtet, dass die CPU-Auslastung einige Sekunden auf 100% ansteigt. Auch der Arbeitsspeicherbedarf verdoppelt sich kurzzeitig. streamwriter zieht alle CPU-Resourcen an sich und kann dann natürlich keine Daten verarbeiten.
Nach 100 Versuchen verbindet er sich nicht mehr neu "100 mal wiederholt, beende" (Wie wäre es, den Zähler bei einer erfolgreichen Verbindung mal auf Null zu setzen?).
screnn2 zeigt ein solches Ereignis, bei dem ich das Abspielen nach einigen Sekunden neu gestartet habe. screen0 zeigt automatische neu Verbinden.
Leider missbraucht SWR3 die Tag-Funktion etwas. Es passiert aber bei allen Sendern, evtl. nicht ganz so oft. Am Betriebssystem scheint es nicht zu liegen. Ich habe auf dem PC je eine Windows 2000 - und WinXP-Installation. Auf beiden verhält sich streamwriter gleich. Der PC ist ein EPIA-PD mit Via C3-Prozessor, 1 GHz und 512 MB RAM. Mit dem Dekodieren von MP3 sollte der sich eigentlich langweilen.
Ich vermute eine missratene garbage collection. Kann man den streamwriter dazu bringen, Traces zu schreiben?
Danke und Gruß | | |
|
|
|
| | | alex | | 2538 Posts |  |
| | wrote on 20.10.17 at 11:42 | | Moin!
Danke für den detaillierten Post, das sieht sehr interessant aus. Mit etwas Glück ist es das selbe Problem wie hier: https://streamwriter.org/de/forum/faden/1095/ .
Hattest du auf den selben Rechnern/Betriebssystem-Installationen eine ältere sW-Version im Einsatz, bei der es nie zu diesem Problem gekommen ist?
Ich vermute eine missratene garbage collection. Kann man den streamwriter dazu bringen, Traces zu schreiben?
Eine Garbage Collection gibt es bei streamWriter nicht, das ist eine native Win32 Anwendung (mit Delphi entwickelt). Mehr Protokollierung ist so leider nicht möglich, das muss ich mir mal im Debugger anschauen.
Diese Sache hat auf jeden Fall Priorität für mich, ich schaue in nächster Zeit mal danach und hoffe, dass ich das reproduzieren kann. |
| | | | LG/Best regards, Alex
"Journalism is printing what someone else does not want printed. Everything else is public relations."
- George Orwell
D1734FA178BF7D5AE50CB1AD54442494 |
|
|
| | | Karsten_Strupp | | 9 Posts | |
| | wrote on 20.10.17 at 19:26 | | Hallo,
ich hatte immer schon, auch auf einem anderen Rechner, der ein bisschen schneller ist, Athlon XP 2200, 1 GB RAM, das Problem, dass es kurze Aussetzer gab. Ich habe es immer darauf geschoben, dass wohl Internetradio noch nicht so zuverlässig ist, bis ich die CPU-Peaks vom sW bemerkt habe.
Ein Bild vom Taskmanager dort habe ich auch angehängt. Der CPU-Peak ist zu sehen, der Verlauf vom Speicher hat an der Stelle nur eine kleine Delle.
Den Rechner benutze ich seit geraumer Zeit aber nicht mehr für sW, zum Radiohören einfach zu viel Stromverbrauch. Auf beiden Rechnern ist sW jeweils die einzige App, die da läuft.
Wiegesagt, es muss eine der letzten Versionen gewesen sein. Die kurzen Aussetzer (nur als Pause beim Abspielen, es ging Nichts verloren) hatte ich immer schon, aber so krass, dass alle paar Minuten die Verbindung zum Server geschlossen und neu aufgebaut wird, geschätzt erst ein paar Wochen.
Gruß,
Karsten
PS: Vielleicht kannst du ja eine virtuelle Maschine, entsprechend meiner Hardware konfiguriert, zum Nachstellen einsetzen. | | |
|
|
|
| | | alex | | 2538 Posts | |
| | wrote on 22.10.17 at 18:54 | | Danke für die Infos. Ich habe einen Plan, wie wir hier weiter kommen können… und auch eine Vermutung was das Problem sein könnte. Ich melde mich im Laufe der nächsten Woche wieder in diesem Thread |
| | | | LG/Best regards, Alex
"Journalism is printing what someone else does not want printed. Everything else is public relations."
- George Orwell
D1734FA178BF7D5AE50CB1AD54442494 |
|
|
| | | Karsten_Strupp | | 9 Posts | |
| | wrote on 27.10.17 at 23:42 | | Noch ein Hinweis: Man muss gar keinen Stream abspielen oder aufzeichen. Auch wenn streamWriter Nichts tut, gibt es diese Peaks. Mir fiel es auf, da SW mal wieder nach 100 Verbindungsversuchen aufgegeben hat und eine Weile so rumstand, bevor ich den Klick auf Play machen konnte. Da gab es genau dieses Bild im Taskmanager.
Und ich weiß nicht, ob es Zufall ist, aber mir fällt auf, dass z.B. immer, wenn die Nachrichten zur vollen Stunde begonnen haben, erstmal Funkstille ist. Es passiert zwar alle paar Minuten, aber es könnte darauf hindeuten, dass diese Minuten nicht zufällig sind. Ist aber nur so ein Verdacht.
Der Peak beim Memory führt jedenfalls dazu, dass der Rechner erstmal übelst am Swappen ist (HDD-Aktivität). Und dann ist natürlich Warten angesagt.
Der andere Rechner hat mehr Speicher und swappt nicht. Daher sind die Aussetzer dort nur Sekundenbruchteile lang.
Gruß,
Karsten | | |
|
|
|
| | | alex | | 2538 Posts | |
| | wrote on 30.10.17 at 23:56 | | Moin,
hier mal eine Möglichkeit, dem Problem auf die Spur zu kommen.
Zuerst eine spezielle Debug-Version von streamWriter hier herunterladen:
https://nextcloud.mistake.ws/index.php/s/wNtNzWAUrjMt0rn
Einfach ein Backup von der aktuellen streamwriter.exe machen, diese dann durch streamwriter.exe aus dem Archiv aus dem Link ersetzen.
Danach procdump herunterladen und entpacken:
https://docs.microsoft.com/en-us/sysinternals/downloads/procdump
Jetzt muss streamWriter gestartet werden, nach dem Start gehst du mit der Eingabeaufforderung in das Verzeichnis, wohin procdump entpackt wurde. Dann an der Eingabeaufforderung "procdump.exe -h streamwriter" ausführen.
Wenn streamWriters Hauptfenster jetzt für 5 Sekunden nicht mehr reagiert, schreibt procdump eine Datei, die den aktuellen Zustand von streamWriter beschreibt, z.B. streamwriter.exe_171030_170307.dmp. Diese Datei solltest du mir dann per Mail senden, die Adresse findet sich hier auf der Seite unter "Impressum".
Danach kann ich diese Datei analysieren und wir wissen eventuell, wo streamWriter ab und an hängt. |
| | | | LG/Best regards, Alex
"Journalism is printing what someone else does not want printed. Everything else is public relations."
- George Orwell
D1734FA178BF7D5AE50CB1AD54442494 |
|
|
| | | Karsten_Strupp | | 9 Posts | |
| | wrote on 06.11.17 at 00:16 | | Das Procdump 9.0 scheint für XP nicht geeignet. Auf dem einen Rechner wird der Prozedur-Einsprungpunkt nicht gefunden, auf dem anderen stürzt es direkt ab und Windows will einen Problembericht senden. Auf der Seite steht auch: Client: Vista or higher.
Um einen älteren zu suchen, habe ich mir jetzt nicht die Zeit genommen.
Mein Verdacht, dass die Störung regelmäßig kommt, hat sich aber bestätigt: Exakt alle 10 Minuten ab Start vom streamWriter und eben auch ohne dass SW irgend etwas tut.
Ich denke, du kannst selbst den CPU spike abfangen. Auf einem aktuellen Rechner wird der Wert vielleicht nicht an die 100 % gehen, aber vermutlich trotzdem auffällig sein. Und den procdump kann man ja auf CPU scharf machen.
Gruß,
Karsten |
|
|
|
| | | alex | | 2538 Posts | |
| | | | | LG/Best regards, Alex
"Journalism is printing what someone else does not want printed. Everything else is public relations."
- George Orwell
D1734FA178BF7D5AE50CB1AD54442494 |
|
|
| | | iro | | 2 Posts |  |
| | wrote on 21.11.18 at 00:04 last edited by iro on 21.11.18 at 00:06 | | Den text aus dem Eingangsposting kann ich fast unverändert hier hineinkopieren, aber es gibt doch Variationen…
Ich habe alle 10 Minuten beim Abhören eines Radiostreams eine Verbindungsunterbrechung. streamwriter meldet: "Keine Daten für mehr als 20 Sekunden empfangen/gesendet" und verbindet sich neu.
Ich habe dann beobachtet, dass die Festplatten-Auslastung dann etwa 30 Sekunden auf 100% ansteigt. Manchmal steigt sie im gleichen 10 min Rythmus auch nur kürzer auf 100% an, dann laufen die Streams weiter. Bei den 30s reißen sie mit Sicherheit ab.
Auffällig: ziemlich genau alle 10 ODER 20 min, jeweils um hh:m7:ss
So sieht das in Form geschriebener Dateien dann aus.
17 EvoFULL - 181120 – 03.57.53.mp3
18 StreamWriter - 674FM - 181120 – 03.57.57.mp3
19 StreamWriter - 674FM - 181120 – 04.07.40.mp3
20 EvoFULL - 181120 – 04.07.34.mp3
21 EvoFULL - 181120 – 04.18.19.mp3
22 StreamWriter - 674FM - 181120 – 04.18.26.mp3
23 StreamWriter - 674FM - 181120 – 04.28.39.mp3
24 EvoFULL - 181120 – 04.28.33.mp3
25 EvoFULL - 181120 – 04.37.50.mp3
26 StreamWriter - 674FM - 181120 – 04.37.56.mp3
27 StreamWriter - 674FM - 181120 – 04.47.40.mp3
28 EvoFULL - 181120 – 04.47.34.mp3
29 EvoFULL - 181120 – 04.57.27.mp3
30 StreamWriter - 674FM - 181120 – 04.57.33.mp3
31 StreamWriter - 674FM - 181120 – 05.07.34.mp3
32 EvoFULL - 181120 – 05.07.28.mp3
33 StreamWriter - 674FM - 181120 – 05.17.30.mp3
34 EvoFULL - 181120 – 05.17.24.mp3
35 EvoFULL - 181120 – 05.27.34.mp3
36 StreamWriter - 674FM - 181120 – 05.27.40.mp3
37 StreamWriter - 674FM - 181120 – 05.37.36.mp3
38 EvoFULL - 181120 – 05.37.30.mp3
39 EvoFULL - 181120 – 05.47.34.mp3
40 StreamWriter - 674FM - 181120 – 05.47.40.mp3
41 StreamWriter - 674FM - 181120 – 05.57.42.mp3
42 EvoFULL - 181120 – 05.57.36.mp3
43 EvoFULL - 181120 – 06.07.37.mp3
44 StreamWriter - 674FM - 181120 – 06.07.42.mp3
Um 06.07 Uhr war der Spuk vorbei und ging am gleichen Tag um 17.47-18.37 Uhr weiter. Und dann wieder ab 20.17 Uhr.
50 StreamWriter - 674FM - 181121 – 17.47.42.mp3
51 EvoFULL - 181121 – 17.47.36.mp3
52 EvoFULL - 181121 – 17.57.25.mp3
53 StreamWriter - 674FM - 181121 – 17.57.31.mp3
54 StreamWriter - 674FM - 181121 – 18.07.33.mp3
55 EvoFULL - 181121 – 18.07.27.mp3
56 EvoFULL - 181121 – 18.27.27.mp3
57 StreamWriter - 674FM - 181121 – 18.27.32.mp3
58 StreamWriter - 674FM - 181121 – 18.37.37.mp3
59 EvoFULL - 181121 – 18.37.30.mp3
60 EvoFULL - 181121 – 20.17.36.mp3
61 StreamWriter - 674FM - 181121 – 20.17.43.mp3
62 StreamWriter - 674FM - 181121 – 20.27.31.mp3
63 EvoFULL - 181121 – 20.27.26.mp3
64 StreamWriter - 674FM - 181121 – 20.47.43.mp3
65 EvoFULL - 181121 – 20.47.39.mp3
66 Radio Hannover - 181121 – 20.58.01.mp3
Ich habe den Player um 21.21 Uhr neu gestartet, der Zeitpunkt verschiebt sich jetzt und findet alle 10 min ODER 20 min um hh:m1:ss
67 EvoFULL - 181121 – 21.21.32.mp3
68 StreamWriter - 674FM - 181121 – 21.21.17.mp3
69 StreamWriter - 674FM - 181121 – 21.31.30.mp3
70 EvoFULL - 181121 – 21.31.25.mp3
72 StreamWriter - 674FM - 181121 – 21.51.32.mp3
73 EvoFULL - 181121 – 21.51.26.mp3
Die Dateien sind alle um etwa 13,0-13,3 MB oder 26,8 MB groß entsprechend etwa 9:30 bzw. 19:30 min Länge des geschriebenen mp3.
Obiges ist alles soweit heute passiert, aber in der Vergangenheit hatte ich schonmal ähnliche Beobachtungen gemacht, für die ich noch keine Erklärung hatte. Ein Muster war dabei bereits erkennbar. Dann war eine weile Ruhe, bis heute. Und heute konnte ich das endlich mal live mitbeobachten. Das alles war mit Version 5.4.1.0.
Ich habe gegen 22 Uhr auf Version 5.4.2.1 geupdatet, die läuft seit 50 min. problemfrei unter Windows 10 Home 1607(!).
Leider musste ich alle Einstellungen neu machen und Sender wieder hinzufügen.
(Lässt sich das irgendwie vermeiden?)
Falls das wieder auftritt, werde ich berichten.
Ich habe zwar keine Ahnung, aber irgendwie werde ich das dumme Gefühl nicht los, daß die bass.dll etwas damit zu tun hat.
Und da fällt mir auch grad eine weitere Beobachtung auf. Ich höre nur sehr selten per StreamWriter, aber einige Male habe ich doch reingehört und dabei fiel machmal auf: der Ton hängt in einer Art sich wiederholendem "Loop". Man hört zwar was, aber das ist nicht das, was tatsächlich Live läuft. Die Aufnahme jedoch läuft ganz normal und ist hinterher auch fehlerfrei.
Dieses "Loop"-Verhalten kenne ich von einer Amok-Laufenden bass.dll einer niedrigeren Versionsnummer (8?) (bei TapinRadio verwendet). Die verträgt sich anscheinend nicht auf Dauer mit Win10 (seit einem Patch Anfang 04/2017). Das Problem konnte ich bis heute nicht lösen, unter XP läuft Tapin zuverlässig und jahrelang, unter Win10 wenn, dann maximal 4 Tage bis die bass.dll Fehlermeldung alles zum Absturz bringt.
Irgendwelche Systemmeldungen zu möglichem, was zu den Zeitpunkten der StreamWriter-Unterbrechungen passiert sein könnte, finde ich keine. Routerprotokoll ist sauber, eventvwr.msc ebenfalls. |
|
|
|
| | | reutershagen | | 192 Posts |  |
| | wrote on 29.11.18 at 14:20 | | Moin,
iro meinte:
problemfrei unter Windows 10 Home 1607 Keine Sorge, das wird schon noch.
Bei so vielen Problemen unter Windows 10 in den letzten Wochen (durch automatische Updates, welche sich auch kaum beeinflussen lassen) ist zu erwarten, demnächst die eine oder andere Schwierigkeit auch mit streamWriter zu bekommen.
alle Einstellungen neu machen Wie bereits mehrfach in diesem Forum von mir beschrieben, lassen sich Einstellungen exportieren bzw. importieren. |
|
|
|
| | | iro | | 2 Posts | |
| | wrote on 11.12.18 at 20:32 | | Danke für Deine Antwort, reutershagen.
Bzgl. "Daten weg nach Absturz". Nach dem letzten Absturz und schließendem Programmneustart wurden mir 2 Profile zur Wahl angeboten. Nachdem ich beim vorletzten Mal das obere wählte, dann aber nichts mehr da war und ich alles neu einstellen musste, wählte ich diesmal das "untere" angebotene und löschte das obere. Diesmal waren dann alle Einstellungen wieder da.
Zum jeweiligen Absturz:
das passierte jedesmal beim Kopieren des gesamten Protokolls eines Senders, nicht einer Einzelzeile.
Vermutlich (100%ig kann ich es nicht sagen) passiert das, wenn man bei einem Sender versehentlich 2x auf den Kopieren-Button klickt.
Zum Windows 10 Home 1607:
der bekommt keine automatischen Updates. Die letzte Version, wo sich das noch verhindern ließ (per "WLAN als getaktete Verbindung").
wenn ich den Zustand behalten will, darf ich allerdings nie wieder ein Windows-Update machen….
Zum eigentlichen 10/20 min.-Problem:
Es trat am 8.12.2018 wieder auf. Nach einem Rechnerneustart lief der StreamWriter dann 3 Tage wieder ohne Probleme, heute am 11.12.2018 trat das Problem erneut auf. Ich habe den Rechner jetzt wieder neu gestartet und beobachte weiter. Das erneute Auftreten nach 3 Tagen bestärkt mich in dem Verdacht, daß die Ursache in der bass.dll liegen könnte. (bei Tapin Radio mit älterer bass.dll war das etwa der gleiche Rythmus - 3-4 Tage, dann aber mit Komplettabsturz der bass.dll inkl. entsprechender Meldungen im eventmgr. - die es allerdings beim aktuellen Problem NICHT gibt.) |
|
|
|
| | | reutershagen | | 192 Posts | |
| | wrote on 16.12.18 at 16:51 | | Moin,
iro meinte:
Nach dem letzten Absturz … wurden mir 2 Profile zur Wahl angeboten
Glück gehabt, wenn damit der bisherige Zustand gerettet werden konnte.
Die sichere Variante ist jedoch, das Profil regelmäßig zu exportieren.
So kann man streamWriter übrigens auch auf einem anderen PC installieren und mit den alten Einstellungen laufen lassen.
Zum jeweiligen Absturz:
das passierte jedesmal beim Kopieren des gesamten Protokolls eines Senders,
…
wenn man bei einem Sender versehentlich 2x auf den Kopieren-Button klickt.
Habe mal versucht das auf meinen Systemen zu provozieren, konnte (trotz mehrfacher Klicks auf kopieren) damit jedoch keinen Absturz erzeugen (obwohl deutlich über 500 Zeilen übertragen wurden).
Zum Windows 10 Home 1607: … Sofern es keinen zwingenden Grund (Anwendungen / Prozessor) gibt, empfehle ich jedem die Nutzung von Window 7 Professional (KEIN Home), da dieses verhältnismäßig gut läuft und inzwischen für (sehr) wenige Euro erhältlich ist (die Lizenzen werden fast verschenkt und können vermutlich für längere Zeit auch zur späteren Umstellung auf Windows 10 genutzt werden).
Die Probleme damit dürften derzeit deutlich geringer sein als mit irgendeiner Windows 10 Variante. |
|
|
