Recording Service hängt beim beenden

[t5b6_de]

Hi,

 

Folgendes Problem:

der Recording Service 1.31.0.0 hängt sporadisch. Interne Tasks, Timer etc. laufen weitehrin ab. das ist kein Problem. In seltenen Fällen funktioniert auch das Webinterface noch (nur über Localhost, jedoch nicht aus dem Netz)

mit der vorherigen Version (1.29.0 letzte die funktioniert, 1.30.1 hat dieses bereits) trat das Problem nicht auf, ist auch reproduzierbar.

 

Beim Beenden des Recording-Service hängt dieser ausnahmslos immer. Teilweise 5-10 Minuten muss man warten ehe der Prozess beendet wird.

 

Plugins habe ich alle entfernt, Problem besteht weiterhin. Es ist ein tierisches Problem.

Sehr leicht reproduzieren lässt es sich auch wenn man mehrere Aufnahmen startet und diese innerhalb weniger Sekunden beendet.

 

Ein anderes Problem ist noch, wenn alle Tuner, oder sagen wir mal mehr als 2 in Benutzung sind, kommt es zu einem Bluescreen, wenn man den Recording-Service im Taskmanager abschießt.
Dieses beschleunigt den Prozess des beendens allerdings nicht, der Prozess bleibt, es hängt ein einzelner Thread, nach ein paar Minuten ist dieser jedoch weg.

 

Es gibt mit dem 1.31.0.0 noch ein weiteres Problem, was die Nutzung und Freigabe der Plugins angeht, jedoch ist das eher zweitrangig und durchaus vernachlässigbar.

 

Ich möchte ungern auf den Recording-Service 1.31. und die neue Hardware-Verwaltung verzichten, jedoch werde ich da gerade zu genötigt.

 

Das Problem besteht definitiv seit dem Update auf 1.31, ist aber derzeit so nervtötend, dass ich es hier posten muss. Obwohl ich bei solchen Sachen durchaus tolerant bin. Supportfile anbei.

 

 

Noch einen schönen Abend. und Gute Nacht

 

t5b6_de

 

 

Nachtrag, das Problem besteht auch mit 1.30.1, nachdem ich nun alles gelöscht und neu instaliert habe:

 

 

Das ist der letzte Thread der offen bleibt, wenn man den Recording-Service über den Taskmanager abschießt.

Edited November 5, 2015 by t5b6_de

[dbraner]

Naja, dass das Abschiessen eines Prozesses zu unvorhergesehenem Verhalten von Windows führt und/oder ggf. einzelne Threads hängen bleiben ist jetzt nicht so verwunderlich. Schließlich wird die Anwendung nicht korrekt beendet. Auch ein Bluescreen kann beim "killen" von Hardware nahen Anwendungen vorkommen, schließlich läuft der TV-Kartentreiber vermutlich im Kernel-Mode.

Edited October 21, 2015 by dbraner

[t5b6_de]

Trotzdem sollte beim beenden der Recordingservice keine 5-10min hängenbleiben, oder teilweise absolut gar nicht mehr reagieren.
Das macht Änderungen an der Konfiguration extrem mühsehlig und langwierig. Zudem scheinen interne Threads auch nicht beendet zu werden oder zu hängen, was die Problematik erklären könne weshalb der Recording-Service manchmal gar nicht mehr reagiert. Er nimmt zwar noch TCP-Verbindungen entgegen, aber es gehen keine Daten durch.

Das ist ein Fehlverhalten. In der Regel kann ich den Recording-Service abschießen ohne das was passiert, sollte es nötig sein.

Bei der 1.30.1 gibt es diese Problematik dass er nichtmal mehr normal über das Tray-Programm oder die Dienste-Steuerung von Windows beendet werden kann.

 

Ich kann gerne ein komplettes RAM-Abbild vom Recording-Service zukommen lassen wenn dieser das nächste mal hängt.

Gerne auch eine Auflistung aller Threads mit Stack, sollte es beim debuggen helfen.

Edited October 21, 2015 by t5b6_de

[t5b6_de]

Da es wohl einen Fehler beim Upload der Support-Daten gab, anbei nochmal.

 

Habe nun Dumps angefertigt,

Situation:
Beenden des Recording-Service über die tray app:
http://mail.t5b6.de/dl/dumps.zip

 

Dort zum Download.

würde diese her gern anhängen, ist aber zu groß. sind 2 dumps
die Datei mit (2) ist direkt nach dem starten wieder beendet worden, bei der anderen Datei waren vorher alle 4 Sat-Tuner in gebrauch. Nachdem alle tuner wieder geschlossen wurde wurde der DVBViewer Recording-Service über die Dienste-Anwendung von WIndows fachgerecht beendet, dabei hing sich der Recording-Service wie fast immer auf.

support.zip

Edited October 22, 2015 by t5b6_de

[t5b6_de]

Nachtrag:

Ich habe nun "Direktes Tunen" bei der Tunerhardware für jeden Tuner deaktiviert. Bisher scheint das Problem, dass der Recording Service sporadisch hängt gelöst zu sein.
Das ewig lange beenden des Dienstes mit der Meldung "Fehler 1053; Der DIenst antwortete nicht rechtzeitig auf die Start- oder Steuerungsanforderung" (beim Beenden über den Dienste-Manager) besteht jedoch weiterhin.

 

mfg

Edited October 29, 2015 by t5b6_de

[t5b6_de]

Entschuldigt, dass ich mir die ganze Zeit selbst antworte....

 

Langsam nervt es leider sehr, folgendes Problem immer noch:
Beim Beenden hängt sich der Recording Service auf. Mittlerweile laufen da über 66 Threads, ich warte seit etwa einer Viertelstunde, keine Ahnung warum das teil hängt. Schaue ich mir das genauer an, laufen dort massig Threads in folgender Funktion

Arbeitsthread MSDvbNP.ax!CNetworkProvider::ThreadFunctionWrapper() MSDvbNP.ax!CNetworkProvider::ThreadFunction

Ich habe diesbezüglich einen weiteren Dump angefertigt, welcher die vielen laufenden Threads aufzeigen dürfte. Es wäre schön wenn das mal jemand mit besseren Kenntnissen als ich analysiert.

 

der Dump wird in ca 5-10min dort verfügbar sein:

http://mail.t5b6.de/dl/DVBService.exe_66threads.zip

 

Nachtrag:
öffne ich den DVBViewer als client, werden 6 threads gestartet. Schließe ich den, werden 5 beendet, sprich irgendwann schmiert der Service sowieso ab weil viel zu viele Threads laufen.
Stichwort u.A. Memleak/Threadleak.

Edited November 5, 2015 by t5b6_de

[Griga]

Laut Recording Service Log verwendest du noch die alte Unicast-Schiene. Treten die Probleme ebenso auf, wenn du RTSP / Sat>IP verwendest?

 

Dazu in den Recording Service-Optionen den DVB Server deaktivieren und RTSP Server aktivieren, die Unicast-Geräte im DVBViewer-Client -> Optionen -> Hardware auf "nicht verwenden" setzen, entsprechende RTSP-Geräte hinzufügen (vielleicht erst mal nur eines für einen Test), mit dem Einstellungen-Button für den Recording Service konfigurieren - er sollte zu dem Zeitpunkt laufen, damit er in den Einstellungen als Server angeboten wird.

 

Siehe dazu auch hier.

[Derrick]

..vielleicht liegt es ja auch daran, dass ihr alle die HD+ sender sehen wollt Wechseln von unicast auf RTSP lässt das CAM-menü verschwinden, aber das scheint ja dann auch nicht mehr nötig

[t5b6_de]

unicast funktioniert sehr gut, vor allem bei bild in Bild...
das funktioniert mit satip rtsp nicht.

Probleme treten immer auf, Egal ob ein Sender getunt war oder nicht...

[Griga]

unicast funktioniert sehr gut, vor allem bei bild in Bild...

das funktioniert mit satip rtsp nicht.

 

Aber sicher funktioniert das.

 

Probleme treten immer auf, Egal ob ein Sender getunt war oder nicht...

 

Habe ich in deinem Log gesehen. Und zwar beim Beenden des RS, wenn unter anderem der DVB Server (= Unicast Server) abgeräumt wird.

 

Früher gab es ähnliche Hänger bei RTSP. Lars hat sich daraufhin entschlossen, die Netzwerkbibliothek auszutauschen, auf der der RTSP Server basiert. Danach waren die Hänger weg. Bei Unicast hat er sie nicht ausgetauscht, da er bereits zu dem Zeitpunkt die Schiene als Auslaufmodell ansah.

 

Also genug Verdachtsmomente... aber deine Sache, ob du meinem Vorschlag folgen willst oder nicht. Unicast wird ohnehin früher oder später rausfliegen.

[Derrick]

 

Unicast wird ohnehin früher oder später rausfliegen.

..solange noch kein ersatz fürs CAM-menü in sicht ist, wird es wohl eher später

[t5b6_de]

Mit RTSP funktioniert es nicht wenn man mehrere verschlüsselte sender hat... Punkt.
Multi Decryption funktioniert damit nicht. Mit Unicast sehr wohl.

Problem besteht jedoch weiterhin, hab den Server komplett neu installiert. Sogar aktuelleres Server-Betriebssystem genommen, das Problem besteht nach wie vor.
Ganze 6 Stunden arbeit umsonst, weil ich schon so paranoid geworden bin weil ich davon ausgegangen bin, dass es macken im BS sind, weil ja beim Killen auch immer Bluescreen usw. usf.

Aber wieso funtkioniert denn die Version 1.29.1 fehlerfrei? die hängt ja nicht?
Kommt aber nicht mehr in Frage wegen der Hardware-Verwaltung.

Irgendwas anderes scheint da aber dennoch zu hängen. Verwende mehrere Stream-Patch-Plugins (eigene), die Instanzen werden erst beim Transponderwechsel "entladen", allerdings ist das erst seit 1.31 so.

 

Und ja, es ist der Unicast-Server der da hängt... Aber wieso?

[t5b6_de]

Nachtrag:

Auch ohne Unicast DVB-Server hängt der Recording Service beim beenden... das gleiche Spiel.
Ein Satz mit X war wohl nix... erstmal 2-3 mal beenden hat funktioniert, nun wo der mal 5min lief -> nö nicht möglich den zu beenden

[Griga]

Arbeitsthread MSDvbNP.ax!CNetworkProvider::ThreadFunctionWrapper() MSDvbNP.ax!CNetworkProvider::ThreadFunction

 

Das ist eine MS BDA-Komponente (MS Network Provider), die du durch

 

Ich habe nun "Direktes Tunen" bei der Tunerhardware für jeden Tuner deaktiviert.

 

herbeizitiert hast. Vorher war es eine DVBViewer-eigene Komponente. Die Threads werden weder im DVBViewer-Code erzeugt noch beendet. Es geschieht indirekt durch das Laden / die Freigabe der Komponenten. Normalerweise räumt Windows alle Threads zwangsweise ab, wenn ein Prozess terminiert, ohne selbst für das Beenden zu sorgen - sowas wie ein Thread-Leak über das Prozessende hinaus gibt es deshalb eigentlich nicht. Die Threads sind wahrscheinlich so hartnäckig, weil es durch die Tuner-Komponente (= Wrapper für den DVB-Gerätetreiber) Bezüge in den Kernel/Treiberbereich gibt. So widerstandsfähige Festhänger habe ich erlebt, wenn ich beim Debuggen in dem Daten-Zulieferer-Thread der Tuner- oder Receiver-Komponente einen Breakpoint setze. Sowas machen manche Treiber nicht mit.

 

Die Hardware-Freigabe klappt also nicht oder nicht vollständig. Offen ist, ob es sich dabei um eine Folgeerscheinung oder die Ursache handelt. In deinem Log wird der RS nach dem ersten Start sauber beendet - du hattest ihn vorher offenbar ohne vorhandenes Setup neu installiert, weil es keine svchardware.xml gab und sie deshalb neu erzeugt wurde. Nach dem zweiten Start wird DVB-Hardware verwendet. Die Freigabe läuft zwar sauber durch, soweit ich das dem Log entnehmen kann, aber danach (auch bei nachfolgenden Starts) funktioniert das Beenden des RS nicht mehr.

 

Ist es reproduzierbar so, dass nach einem PC-Neustart das Beenden nicht mehr klappt, sobald einmal DVB-Hardware verwendet wurde?

 

Es fragt sich, wie man das Problem weiter einkreisen kann. Es ist jedenfalls nicht allgemeiner Art, sondern muss mit bestimmten Bedingungen bei dir zusammenhängen. Den Code für die Hardware-Freigabe in der 1.29 und in der aktuellen Version habe ich verglichen. Dort hat sich nichts geändert. Wie sieht es aus, wenn du in den RS-Optionen alles deaktivierst außer dem DVB- bzw. Unicast Server? Um den Webserver (für das Web Interface) aus dem Verkehr zu ziehen, musst du bei gestopptem RS die RSTweaker.bat aufrufen und danach im RS Tweaker den Haken bei "Webserver aktivieren" rausnehmen.

[t5b6_de]

Hi, ich versuche es jetzt nochmal, alles deaktivieren, einschließllich webinterface. Lösche nun erstmal alle logs, damit das sauber ist.

 

Der Threadleak entsteht tatsächlich durch das Microsoft-Tuning (deaktiviertes direktes Tuning), ist zwar immer noch vorhanden aber nach einigen Minuten fällt die Zahl der Threads wieder, scheint wohl irgdwas zu klemmen, irgendwas in der dvbservice.exe. mit offset 0x46a8. Leider fehlen mir die debugging-Symbol um zu schauen wo es hängt.

 

Direktes Tunen ist auch wieder drin, weil es ja erstmal keine wirkliche Lösung war, es hat sich nicht wirklich was geändert. Hat jemand anders noch irgendwie
einen I7 3.gen rechner mit server2012r2 laufen und Digital-Devices Hardware?

 

Mit allen Netzwerkkomponenten Deaktiviert scheint es zu funktionieren. Ich werde das gefühl nicht los, dass es irgendwas mit den Netzwerkschnittstellen zu tun hat.

 

Nicht wundern wenn der Text etwas wirr ist, ich schreibe ihn, während ich das alles nach und nach Teste, jetzt aktiviere ich einmal nur das Webinterface.

 

Mit aktiviertem Webinterface ohne RTSP-Server läuft alles fluffig, auch streaming über das Webinterface läuft sauber.

Aktiviere ich nun dann noch den RTSP-Server fängt der Recording-Service sofort an sich aufzuhängen.

 

 

Ich warte derzeit noch darauf, dass der Recording-Service sich noch beendet. Miene Mittagspause ist in 10min Vorbei. Hoffe das klappt bis dahin

 

Support-Files:
http://dl.t5b6.de/support_alles%20deaktiviert.zip

http://dl.t5b6.de/support_webifundrtspaktiv.zip

 

 

Nach jedem Versuch habe ich die Logfile vom Recording-Service gelöscht. Dieses mal habe ich den Recording-Service nicht gekillt.

 

PS: Sollten die DOwnloads nicht funktionieren, bitte in 2-3 Minuten nochmal versuchen, kommt vom Privatanschluss.

[Griga]

Aktiviere ich nun dann noch den RTSP-Server fängt der Recording-Service sofort an sich aufzuhängen.

 

Er war also bereits vorher aktiv, als du nur Unicast verwendet hast? Und führte zu Festhängern, ohne dass er verwendet wurde? Ungewöhnlich... das muss ich mir noch mal im Code anschauen.

[Griga]

P.S. Also selbst, wenn der aktivierte RTSP Server nicht verwendet wird, gibt er natürlich seine Anwesenheit via UPnP / Multicast im Netzwerk bekannt. Insofern wird er auf jeden Fall tätig.

 

Den Code-Bereich habe ich allerdings bislang noch nicht erforscht, und es ist sehr schwer, die Ursache von Problemen ausfinidg zu machen, die man nicht nachvollziehen kann. Gibt es vielleicht UPnP Clients in deinem Netzwerk, die auf den RTSP Server reagieren und von deren Anwesenheit es abhängig sein könnte, ob es zu den Hängern kommt?

[Griga]

P.P.S: Eine Änderung in der 1.30, die Sat>IP UPnP Announcements betrifft, ist

 

Fix: RTSP Server: Die Multicast TTL wurde fälschlich auf 1 anstatt wie beabsichtigt auf 5 gesetzt, was die Sichtbarkeit des Servers über Subnetz-Grenzen hinaus beeinträchtigte.

 

Ist denkbar, dass das in deinem Netzwerk Folgen hat?

[t5b6_de]

Möglich, aber unwahrscheinlich, habe hier einen Cisco Router der in ein anderes Subnetz routet, der recording service ist dort aber nicht sichtbar, da der Router nicht fur multicast konfiguriert ist... ich kann ja mal alles abstecken. andersherum habe ich aber noch nicht getestet was ist wenn ich upnp und rtsp deaktivieren und nur unicast nutze, man möge mir fur die Rechtschreibung entschuldigen, ich habe am Handy getippt

[Griga]

Auffällig ist in dem RTSP Log folgendes:

 

09.11.15 12:38:34.652 TRecordingEngine StopService start stopping service
09.11.15 12:39:55.155 TUPnPAnnounce Stop

Dort entsteht eine Verzögerung von 01:21 Minuten. In der Zeit versucht der RS, sich bei potentiellen UPnP Clients abzumelden, und zwar über folgende Schnittstellen:

 

InitWsocket 127.0.0.1
InitWsocket 10.0.0.1
InitWsocket 172.24.128.1

 

Ich nehme an, beim Schließen zumindest eines der Sockets ergibt sich eine längere Wartezeit. Der RS versucht nämlich ein "Graceful Close", bei dem zuvor im Sendepuffer abgelegte Daten noch gesendet werden. Und wenn das nicht klappt, zieht sich die Sache hin... Abhilfe brächte ein (kürzeres) Timeout, d.h. er versucht z.B. höchstens eine Sekunde lang, den Inhalt des Sendepuffers lozuwerden, und danach gibt es ein gnadenloses Abort statt Close.

 

Es könnte auch sein, dass sich die Verzögerung eine Ebene tiefer in WinSock ergibt. Soweit bin ich mit meinen Untersuchungen noch nicht vorgedrungen.

 

Soweit ich das im Code erkennen kann, müsste das Problem sich nicht nur bei aktiviertem RTSP Server, sondern auch bei aktiviertem UPnP Server zeigen. Wenn es an einer der drei angegebenen Schnittstellen liegt, könnte man versuchen, die IP über "RS Optionen -> Web/UPnP -> IP(s) nicht nutzen" aus dem Verkehr zu ziehen.

[t5b6_de]

Wenn der Recording-Service läuft, kann dieser nichtmal mehr mit dem Taskmanager abgeschossen werden, es kommt hier zu der gleichen Wartezeit.
Es muss aber irgendwas mit der Netzwerkschnittstelle zu tun haben. Hier sind eine VPN-Verbindung zu meinem Strato-Server nach Berlin, sowie eben die Lokale Netzwerkverbindung, hier Realisiert über einen HyperV-Switch, da der Server mehrere HyperV-VMs bereitstellt (genaugenommen 3 stück, meistens sind aber nur 2 Aktiv, einmal Linux, und einmal weiteres Windows in anderem VLAN, d.h. die sehen sich nicht)

 

 

Es kommt aber irgndwie hin, je länger der Recording-Serivce bereits läuft, desto länger dauert das Beenden, mindestens aber so zwischen anderthalb Minuten und teilweise über eine halbe Stunde. Wobei ich meistens nie länger als 5-10 Minuten warte.

 

 

Das Deaktivieren der VPN-Verbindung sowie des Routings auf dem Server und ausschließen der IP-Adressen localhost und 172.24.128.1 bringt gar nichts.

Wäre es möglich mir dennoch eine Test-Binary zukommen zu lassen in dem Das Timeout auf 0 gesetzt ist? Wobei ich hier keine Hoffnung hab, denn beim killen über den Taskmanager wird ja eh nicht darauf geachtet ob noch was im Sendepuffer ist...

 

Seltsam ist halt nur dass es reicht den RTSP Server raus zu nehmen....

 

Leider habe ich jetzt hier auf der Arbeit nicht die Möglichkeit den Recording-Service ausgiebig zu testen (nur RemoteDesktop Zugang)

[Griga]

Kannst du verifizieren, dass die Aktivierung bzw. Herausnahme des UPnP AV-Servers die gleichen Auswirkungen hat wie die Aktivierung des RTSP Servers? Laut Log ist der UPnP Server bei dir deaktiviert, weil die TUPnPAnnounce-Klasse erst mit RTSP ins Spiel kommt. Also RTSP deaktivieren, UPnP AV Server aktivieren, Problem vorhanden?

 

Für solche Tests ist es vielleicht einfacher, wenn man den RS nicht als Service im Systemkonto, sondern als Anwendung im lokalen Benutzerkonto laufen lässt. Dazu den RS als Service stoppen und DVBVservice.exe manuell starten. Auf dem Desktop erscheint dann ein kleines Fenster ohne Inhalt. Wenn man es schließt, wird der RS beendet. Allerdings funktioniert das Tray-Tool damit nicht.

 

Das Stoppen des UPnP Multicast ist mit das Erste, was beim Beenden des RS passiert. Wenn jemand dabei ungeduldig wird und den RS abschießt, unterbleibt die ordnungsgemäße Freigabe von Hardware und einigem anderen. Es ist durchaus möglich, dass das auf nachfolgende Vorgänge Auswirkungen hat. Oder nimmt die Verzögerung beim Beenden auch zu, wenn du den RS nicht abschießt?

 

Für eine Test-Binary muss ich erst älteren Code heraussuchen, da der aktuelle mit diversen Änderungen in den Dateien für das Web Interface Hand in Hand geht. Ich schaue mal...

[trudeh]

Hallo zusammen, bei mir klemmt es auch beim Beenden des RS seit ein paar Versionen.
Ich hab den RS mal wie von Griga beschrieben im Benutzerkonto gestartet und nach ca. 30 Sekunden wieder beendet.

LOG1 ohne UPnP und RTSP:

12.11.15 13:58:31.956 Start App ------------------------------------------------------------
12.11.15 13:58:31.956 DVBViewer Recording Service 1.31.0.0 (beta)
12.11.15 13:58:31.972 TRecordingEngine Execute Start
12.11.15 13:58:31.974 TRecordingEngine StartService start timer
12.11.15 13:58:31.974 TRecordingEngine StartService Create plugin list
12.11.15 13:58:31.988 TRecordingEngine StartService loadchannellist
12.11.15 13:58:31.991 TDVBDevice InitDevice Digital Devices DVB-S/S2 Tuner 1 (1)
12.11.15 13:58:31.991 TDVBDevice InitDevice Pinnacle PCTV 4XXe Tuner (5)
12.11.15 13:58:31.991 TDVBDevice InitDevice KNC BDA DVB-C (3)
12.11.15 13:58:31.991 TDVBDevice InitDevice Digital Devices DVB-S/S2 Tuner 2 (2)
12.11.15 13:58:31.991 TDVBDevice InitDevice KNC BDA DVB-C (4)
12.11.15 13:58:31.992 TDVBDevice InitDevice IPTV Network Device
12.11.15 13:58:31.992 TDVBDevice InitDevice RTSP Network Device
12.11.15 13:58:31.993 TDVBDevice InitDevice RTSP Network Device 2
12.11.15 13:58:31.993 TDVBDevice InitDevice RTSP Network Device 3
12.11.15 13:58:31.993 TDVBDevice InitDevice RTSP Network Device 4
12.11.15 13:58:32.000 TRecordingEngine Start Searches load
12.11.15 13:58:32.001 TRecordingEngine Start Tasks load
12.11.15 13:58:32.004 TRecordingEngine Start VCR load
12.11.15 13:58:32.126 TRecordingEngine Start EPG load
12.11.15 13:58:32.127 TRecordingEngine loadsetup load vcr
12.11.15 13:58:32.151 TRecordingEngine StartService load setup
12.11.15 13:58:32.151 TRecordingEngine Recorderservice Enabled
12.11.15 13:59:02.858 TRecordingEngine StopService start stopping service
12.11.15 13:59:02.957 TUniCastServer Stop
12.11.15 13:59:03.097 TRecordingEngine savesetup save vcr
12.11.15 13:59:03.098 TRecordingEngine Stop ClearDeviceList
12.11.15 13:59:03.098 TRecordingEngine Stop Done ClearDeviceList
12.11.15 13:59:03.150 TRecordingEngine Stop Unload settings
12.11.15 13:59:03.159 TRecordingEngine Stop Couninitialize
12.11.15 13:59:03.161 TRecordingEngine Recorderservice Disabled
12.11.15 13:59:03.161 TRecordingEngine StopService stop service
12.11.15 13:59:03.161 TRecordingEngine Execute setrunning false
12.11.15 13:59:03.161 TRecordingEngine Execute release shared
12.11.15 13:59:03.161 TRecordingEngine Execute Couninitialize
12.11.15 13:59:03.161 TRecordingEngine Execute Stop
12.11.15 13:59:03.161 TUniCastServer Stop
12.11.15 13:59:03.162 End App ------------------------------------------------------------

LOG2 nur mit UPnP

12.11.15 13:59:59.829 Start App ------------------------------------------------------------
12.11.15 13:59:59.829 DVBViewer Recording Service 1.31.0.0 (beta)
12.11.15 13:59:59.836 TRecordingEngine Execute Start
12.11.15 13:59:59.839 TRecordingEngine StartService start timer
12.11.15 13:59:59.839 TRecordingEngine StartService Create plugin list
12.11.15 13:59:59.853 TRecordingEngine StartService loadchannellist
12.11.15 13:59:59.855 TDVBDevice InitDevice Digital Devices DVB-S/S2 Tuner 1 (1)
12.11.15 13:59:59.855 TDVBDevice InitDevice Pinnacle PCTV 4XXe Tuner (5)
12.11.15 13:59:59.856 TDVBDevice InitDevice KNC BDA DVB-C (3)
12.11.15 13:59:59.856 TDVBDevice InitDevice Digital Devices DVB-S/S2 Tuner 2 (2)
12.11.15 13:59:59.856 TDVBDevice InitDevice KNC BDA DVB-C (4)
12.11.15 13:59:59.856 TDVBDevice InitDevice IPTV Network Device
12.11.15 13:59:59.857 TDVBDevice InitDevice RTSP Network Device
12.11.15 13:59:59.857 TDVBDevice InitDevice RTSP Network Device 2
12.11.15 13:59:59.857 TDVBDevice InitDevice RTSP Network Device 3
12.11.15 13:59:59.858 TDVBDevice InitDevice RTSP Network Device 4
12.11.15 13:59:59.865 TRecordingEngine Start Searches load
12.11.15 13:59:59.866 TRecordingEngine Start Tasks load
12.11.15 13:59:59.869 TRecordingEngine Start VCR load
12.11.15 13:59:59.992 TRecordingEngine Start EPG load
12.11.15 13:59:59.992 TRecordingEngine loadsetup load vcr
12.11.15 14:00:00.016 TDevice Start
12.11.15 14:00:00.017 TUPnPAnnounce Start
12.11.15 14:00:00.017 TUPnPAnnounce InitWsocket 127.0.0.1
12.11.15 14:00:00.017 TUPnPAnnounce InitWsocket 192.168.0.199
12.11.15 14:00:00.017 TUPnPAnnounce InitWsocket 192.168.0.65
12.11.15 14:00:00.019 TRecordingEngine StartService load setup
12.11.15 14:00:00.019 TRecordingEngine Recorderservice Enabled
12.11.15 14:00:31.948 TRecordingEngine StopService start stopping service
12.11.15 14:02:59.587 TUPnPAnnounce Stop
12.11.15 14:02:59.587 TUPnPAnnounce Stop
12.11.15 14:02:59.600 TDevice Stop
12.11.15 14:02:59.601 TDevice Stop
12.11.15 14:02:59.630 TUniCastServer Stop
12.11.15 14:02:59.787 TRecordingEngine savesetup save vcr
12.11.15 14:02:59.787 TRecordingEngine Stop ClearDeviceList
12.11.15 14:02:59.787 TRecordingEngine Stop Done ClearDeviceList
12.11.15 14:02:59.840 TRecordingEngine Stop Unload settings
12.11.15 14:02:59.848 TRecordingEngine Stop Couninitialize
12.11.15 14:02:59.850 TRecordingEngine Recorderservice Disabled
12.11.15 14:02:59.850 TRecordingEngine StopService stop service
12.11.15 14:02:59.850 TRecordingEngine Execute setrunning false
12.11.15 14:02:59.850 TRecordingEngine Execute release shared
12.11.15 14:02:59.850 TRecordingEngine Execute Couninitialize
12.11.15 14:02:59.850 TRecordingEngine Execute Stop
12.11.15 14:02:59.851 TUniCastServer Stop
12.11.15 14:02:59.851 End App ------------------------------------------------------------

 

 

LOG3 nur mit RTSP

12.11.15 14:04:33.129 Start App ------------------------------------------------------------
12.11.15 14:04:33.129 DVBViewer Recording Service 1.31.0.0 (beta)
12.11.15 14:04:33.143 TRecordingEngine Execute Start
12.11.15 14:04:33.145 TRecordingEngine StartService start timer
12.11.15 14:04:33.145 TRecordingEngine StartService Create plugin list
12.11.15 14:04:33.160 TRecordingEngine StartService loadchannellist
12.11.15 14:04:33.162 TDVBDevice InitDevice Digital Devices DVB-S/S2 Tuner 1 (1)
12.11.15 14:04:33.163 TDVBDevice InitDevice Pinnacle PCTV 4XXe Tuner (5)
12.11.15 14:04:33.163 TDVBDevice InitDevice KNC BDA DVB-C (3)
12.11.15 14:04:33.163 TDVBDevice InitDevice Digital Devices DVB-S/S2 Tuner 2 (2)
12.11.15 14:04:33.163 TDVBDevice InitDevice KNC BDA DVB-C (4)
12.11.15 14:04:33.164 TDVBDevice InitDevice IPTV Network Device
12.11.15 14:04:33.164 TDVBDevice InitDevice RTSP Network Device
12.11.15 14:04:33.165 TDVBDevice InitDevice RTSP Network Device 2
12.11.15 14:04:33.165 TDVBDevice InitDevice RTSP Network Device 3
12.11.15 14:04:33.166 TDVBDevice InitDevice RTSP Network Device 4
12.11.15 14:04:33.172 TRecordingEngine Start Searches load
12.11.15 14:04:33.172 TRecordingEngine Start Tasks load
12.11.15 14:04:33.175 TRecordingEngine Start VCR load
12.11.15 14:04:33.299 TRecordingEngine Start EPG load
12.11.15 14:04:33.299 TRecordingEngine loadsetup load vcr
12.11.15 14:04:33.323 TUPnPAnnounce Start
12.11.15 14:04:33.323 TUPnPAnnounce InitWsocket 127.0.0.1
12.11.15 14:04:33.323 TUPnPAnnounce InitWsocket 192.168.0.199
12.11.15 14:04:33.323 TUPnPAnnounce InitWsocket 192.168.0.65
12.11.15 14:04:33.325 TRecordingEngine StartService load setup
12.11.15 14:04:33.325 TRecordingEngine Recorderservice Enabled
12.11.15 14:05:03.816 TRecordingEngine StopService start stopping service
12.11.15 14:07:33.087 TUPnPAnnounce Stop
12.11.15 14:07:33.087 TUPnPAnnounce Stop
12.11.15 14:07:33.138 TUniCastServer Stop
12.11.15 14:07:33.295 TRecordingEngine savesetup save vcr
12.11.15 14:07:33.296 TRecordingEngine Stop ClearDeviceList
12.11.15 14:07:33.296 TRecordingEngine Stop Done ClearDeviceList
12.11.15 14:07:33.348 TRecordingEngine Stop Unload settings
12.11.15 14:07:33.357 TRecordingEngine Stop Couninitialize
12.11.15 14:07:33.359 TRecordingEngine Recorderservice Disabled
12.11.15 14:07:33.359 TRecordingEngine StopService stop service
12.11.15 14:07:33.359 TRecordingEngine Execute setrunning false
12.11.15 14:07:33.359 TRecordingEngine Execute release shared
12.11.15 14:07:33.359 TRecordingEngine Execute Couninitialize
12.11.15 14:07:33.359 TRecordingEngine Execute Stop
12.11.15 14:07:33.359 TUniCastServer Stop
12.11.15 14:07:33.360 End App ------------------------------------------------------------

Hoffe das hilft.

Edited November 12, 2015 by Griga
Spoiler Tags ergänzt, wichtige Stellen hervorgehoben

[Griga]

Ich habe mir mal erlaubt, deinen Post nachzubearbeiten. Bitte längliche Logs entweder als Datei anhängen oder in Spoiler Tags setzen!

 

Hoffe das hilft.

 

Ja, Das gleiche Erscheinungsbild wie bei t5b6_de. Drei IPs, Verzögerung an der gleichen Stelle, ca. 2:30 Minuten. Wir müssen dem mit Testversionen auf den Grund gehen. Ich verschicke gleich PMs.

[trudeh]

Die dritte IP ist bei mir ein ISDN Dial in.

 

Die TTL Variante funzt.

 

12.11.15 15:14:46.889 TRecordingEngine Recorderservice Enabled
12.11.15 15:15:15.931 TRecordingEngine StopService start stopping service
12.11.15 15:15:15.935 TUPnPAnnounce Stop
12.11.15 15:15:15.935 TUPnPAnnounce Stop
12.11.15 15:15:15.948 TDevice Stop
12.11.15 15:15:15.949 TDevice Stop
12.11.15 15:15:16.091 TUniCastServer Stop
12.11.15 15:15:16.262 TRecordingEngine savesetup save vcr

 

Die UPnP Variante nicht.

 

12.11.15 15:16:23.625 TRecordingEngine Recorderservice Enabled
12.11.15 15:16:56.901 TRecordingEngine StopService start stopping service
12.11.15 15:19:23.587 TUPnPAnnounce Stop
12.11.15 15:19:23.587 TUPnPAnnounce Stop
12.11.15 15:19:23.599 TDevice Stop
12.11.15 15:19:23.600 TDevice Stop
12.11.15 15:19:23.636 TUniCastServer Stop
12.11.15 15:19:23.787 TRecordingEngine savesetup save vcr

Edited November 12, 2015 by trudeh

[Griga]

Die TTL Variante funzt.

 

Ok, danke für den Test. Jetzt brauche ich nur noch einen Fachmann, der mir erklärt, warum die Erhöhung der Muticast TTL auf 5 zu dem langen Festhängen führen kann.

 

Hier die Diskussion, die zu der Änderung führte:

 

http://www.DVBViewer.tv/forum/topic/54953-rtsp-client-round-robin-problem/?p=411175

 

Als Lösung fällt mir im Moment nur ein, die Multicast TTL mit dem Default 1 als Tweak konfigurierbar zu machen.

[trudeh]

Mir würde ein Tweak reichen. Erklärungen kannste von mir aber keine erwarten!

[Griga]

Hier gibt es Informationen zu dem Thema:

http://stackoverflow.com/questions/10229226/multicast-socket-close-takes-3-minutes-with-ttl1

Angeblich ist die Ursache ein Windows 7-Problem, das sich durch einen Hotfix beheben lässt:

https://support.microsoft.com/en-us/kb/2555948

Es handelt sich um ein (ungewollt) aktiviertes Multicast-Forwarding (Multicastweiterleitung). Wenn das zutrifft, müsste es sich für den RS 1.31 auch ohne einen Eingriff in den Code beheben lassen. Um festzustellen, ob das Problem vorliegt, muss man in der Eingabeaufforderung

netsh interface ipv4 show global

eingeben. Multicastweiterleitung sollte normalerweise als "disabled" angezeigt werden.

P.S. Ich kann das Problem damit herbeiführen. Nach Eingabe von

netsh interface ipv4 set global multicastforwarding=enabled

mit Adminrechten (!) hängt der RS beim Beenden ebenso wie bei euch. Nach

 

netsh interface ipv4 set global multicastforwarding=disabled

 

ist es wieder ok.

Edited November 13, 2015 by Griga

[trudeh]

Bingo !

Wie von Griga beschrieben funktioniert das Beenden des RS bei deaktiviertem Multicastforwarding.

Dummerweise aktiviert es sich nach eine Neustart ohne Installation des Hotfix wieder neu.

Den Hotfix scheint man jedoch nur nach Anforderung von MS zu bekommen.

[Griga]

Dann läuft bei dir der Routing und RAS-Service? Angeblich soll er beim Start das Multicast Forwarding aktivieren. Bei mir ist er unter Windows 7 deaktiviert (nicht von mir).

 

Wenn dieser Service läuft, wird das vermutlich irgendeinen Grund haben bzw. irgendwas nicht mehr funktionieren, wenn man ihn deaktiviert

[trudeh]

Ja. Der RAS-Service läuft.

Ich hatte ja schon weiter oben geschrieben, dass die dritte IP für ein ISDN Dial IN genutzt wird.

Wird sich bei mir aber bald eh erledigt haben, da ich auf ALL IP Zwangsumgestellt werde.

 

Nachtrag:

Hab den Dienst mal deaktiviert und nach nem Neustart läuft alles wie erwartet.

Edited November 13, 2015 by trudeh

[Griga]

Unabhängig davon wird das nächste Release auf jeden Fall einen Tweak für die Multicast TTL mitbringen, damit es auch im RS eine Möglichkeit gibt, dem Problem auszuweichen.

[t5b6_de]

RAS Service läuft auch bei mir, muss laufen denn ich habe mehrere interfaces und ein Routing. Externer server mit VPN Zugang, von da aus ein Tunnel in mein netzwerk...

Geht leider nicht anders, weil mein Anschluss nicht die benötigte Bandbreite hat.

[nuts]

Für mich klingt das nach einem Netzwerk/Microsoft/Treiber Bug der den RS dann mitzieht.

 

Hat eure Testvariante schon eine Einstellmöglichkeit für TTL? Wäre vielleicht auch mal interessant ob nur 1 funktioniert oder auch ein Wert zwischen 1 und 5.

Für den neuen Default-Wert wäre das ggf. von Bedeutung. 1 ist zu niedrig und 5 zu hoch würde ich sagen.

 

Edit\ Ah ok das Problem tritt schon bei TTL >1 auf. Das ist natürlich etwas blöd ...

Edited November 13, 2015 by nuts

[Griga]

Hat eure Testvariante schon eine Einstellmöglichkeit für TTL?

 

Hat sie nicht. Es ging erst mal nur darum, die Ursache einzukreisen. Es gab eine Testversion mit Multicast TTL = 1 und eine mit Socket.Abort statt Close. Das Problem tritt mit jedem Wert > 1 auf.

[t5b6_de]

Es gibt noch ei Szenario, wo der Recording Service beim beenden hängt, wenn mehrere Clients verbunden werden und der recording Service gestoppt wird. Hier waren mehrere Clients per Unicast und einer via RTSP verbunden. Gleiches Verhalten.

 

Nachtrag: dann aber lässt er sich per Taskmanager killen, wenn mehr als 1 Tuner jedoch verwendet wird kommt es zum bluescreen.

 

Des weiteren: wenn mehr als 1 Timer auf verschiedenen Tunern gleichzeitig beenden, kommt es auch zum bluescreen...

Edited November 25, 2015 by t5b6_de

[Griga]

Lässt sich das noch weiter eingrenzen? Hängt es bei dir mit Unicast zusammen?

 

Ich habe es mit 2 transkodierten Live Streams (= 4 Clients, weil noch 2 x ffmpeg dabei ist) sowie einem RTSP Client probiert. Insgesamt waren drei DVB-Geräte beschäftigt. Ohne Befund. Der RS ließ sich problemlos beenden. Unicast Clients müsste ich mir erst zurechtkonfigurieren.

 

Letztlich ist mir der RS nach Tests mit zwei transkodierten Live Streams gleichzeitig beim Beenden hängen geblieben. Die Streams waren allerdings zu dem Zeitpunkt bereits gestoppt bzw. die Clients weg. Daraufhin habe ich zusätzliches Logging eingebaut und versucht, den Ablauf zu wiederholen. Ich konnte es jedoch leider nicht reproduzieren.

[t5b6_de]

Leider wie gesagt nicht immer Reproduzierbar, wie du ach schon gemerkt hast.
Es waren insgesamt 3 RTSP-Clients verbunden, und es lief ein Timer.

 

Tuner werden auch nicht freigegeben. Die Streams laufen bei mir weiterhin, zumindest die RTSP-Sachen, der Timer wurde gestoppt...

 

Etwas Offtopic:
Hat jemand auch das Problem mit einer DigitalDevices karte, wenn ich sag jetzt brutalerweise 4 tuner gleichzeitig verwendet werden, das beispielsweise mit 4 Timern, diese gleichzeitig enden, dass es zum Bluescreen kommt?

Ich hatte schonmal Kontakt zu DD diesbezüglich, da wollte man mir aber nicht weiterhelfen, da sich da in dem Bereich, wo es passiert, keine Thread-Synchronisation einbauen lässt um das zu verhindern, ich solle auf meine Softwarewahl achten.
So zwischen den Zeilen gelesen scheint die sache ein bekanntes Problem zu sein. Wenn es 3 USB-Sat-Tuner sind, passiert das nicht. Nur bei der DD-Karte (wurde schonmal getauscht, einschließlich plattformwechsel (AMD/Intel)... überall das gleiche)

 

Nachtrag:

Bin mir mit den 3RTSP Clients nicht mehr so sicher,...
Will das ungern reproduzieren, auf dem Server laufen halbwegs wichtige dienste, sobald es nochmal passiert berichte ich

Edited November 25, 2015 by t5b6_de

[nuts]

Also bei 3 DD Tuner im Betrieb und RS stoppen => alles gut

Bei 4 DD Tuner im Betrieb und RS stoppen => bluescreen?

[Griga]

Hat jemand auch das Problem mit einer DigitalDevices karte, wenn ich sag jetzt brutalerweise 4 tuner gleichzeitig verwendet werden, das beispielsweise mit 4 Timern, diese gleichzeitig enden, dass es zum Bluescreen kommt?

 

Der Recording Service hat hier gerade testweise 4 Digitial Devices Tuner (2 x DVB-S, 2 x DVB-T) mit Aufnahmen beschäftigt. Alle endeten Punkt 6:00 Uhr. Kein Problem.

 

Ich hatte schonmal Kontakt zu DD diesbezüglich, da wollte man mir aber nicht weiterhelfen, da sich da in dem Bereich, wo es passiert, keine Thread-Synchronisation einbauen lässt um das zu verhindern, ich solle auf meine Softwarewahl achten.

 

Die Aussage macht in Bezug auf RS- oder DVBViewer-Aufnahmen keinen Sinn. Alle Aufnahmen werden im selben Thread beendet, also zwangsläufig nacheinander. Es gibt einen Timer, der periodisch die aktiven Aufnahmen in einer Schleife überprüft. Wenn also vier Aufnahmen um 6:00 Uhr enden, wird das in dieser Schleife sequentiell abgearbeitet. Deshalb gibt es da nichts zu synchronisieren.

 

Wie auch immer: Gerade ist mir der RS wieder beim Beenden hängengeblieben. Dabei hatte er gar nichts gemacht - kein RTSP, kein Unicast, kein sonstiges Streaming, keine DVB-Hardware-Zugriffe. Und ist nicht mal 8 Minuten gelaufen. Ich hatte nur etwas im Web Interface überprüft.Das inzwischen erweiterte Logging verrät mir, dass es im UPNP-Bereich passiert ist - nicht bei den Announcements, die haben wir ja bereits hinter uns, sondern im eigentlichen Server.

 

Wie beim letzten Mal war noch ein anderer PC im Netz aktiv, bzw. er war nicht mehr aktiv, sondern mangels Beschäftigung kurz zuvor eingeschlafen. Dort lief auch eine RS-Instanz (die mit den vier Aufnahmen). Ich vermute, die beiden Instanzen haben sich UPnP-mäßig über WLAN ausgetauscht, plötzlich war einer weg, und das hat dem anderen nicht gepasst. Mal sehen, ob ich das reproduziert kriege... falls ja, kann ich mit dem Debugger durch den Code steppen und herausfinden, an welcher Stelle es genau festhängt.