Kein FIS/On-Board Displays nach Wine-Update (ZD 3.5.21)

[Iarnród]

Mein Zusi3 lief auf Linux ohne Probleme, bis mir Ubuntu ein Wine-Update aufspielte. Seitdem funktioniert FIS nicht mehr (Tastendrücke reagieren, aber Endlossuche "Anfrage läuft! Bitte warten!" und die meisten Führerstand-MFDs/EBuLas bleiben schwarz; separat gestartet funktioniert es aber (bis auf FIS).

Wie sucht man hier am besten nach dem Fehler? Oder gibt es bereits ähnliche Erfahrungen mit eventueller Abhilfe?

Tschüss

[Christian Gründler]

Welche Version von Wine ist das denn?

[Trojaner]

Guten Tag,

seit dem neusten Zusi-Update (auf Steam) habe ich ähnliche Probleme:

Nach Installieren des Zusi-Updates blieben alle On-Board-Displays bis auf genau eins schwarz und ich konnte auch nur ein funktionierendes externes ZusiDisplay starten. Dieses Problem hat sich bei mir seltsamerweise gelöst, indem ich via winetricks versucht habe, Dotnet 3.5 und Dotnet 3.5 SP 1(?) zu installieren und bei beiden Installern auf Fehler gestoßen bin. Ich weiß nicht, ob das nur ein Zufall war, aber nach diesen Installationsversuchen habe ich Zusi gestartet - beim Laden einer Timetable beschwert es sich zwar über fehlendes Dotnet 3.5 - aber alle integrierten Displays gehen wieder und die externen Displays brauchen jetzt etwas länger, die Verbindung zum TCP-Server aufzubauen, aber es gehen immerhin wieder mehrere.

Trotzdem habe ich nach dem Update das Problem, dass die integrierten ZusiDisplays bei einigen Bauarten (bisher beobachtet bei ICE 127) und irgendeiner Fahrt in Frankreich) mehrere Sekunden, bis hin zu Minuten hinterherhängen (also veraltete Infos anzeigen), bei der BR 147 sämtliche Zustände von der PZB nicht anzeigen können und daher komplett stehen bleiben, bis sie wieder auf dem „Default“ sind (85 leuchtet durchgehend, keine Beeinflussung etc.) und ähnliche Probleme habe ich beim Display für BR 146.X

Aufnahmen dazu:
* ICE: https://youtu.be/7_aj-mk4XAs
* BR 147 (mit eingeblendetem Display für BR 146): https://youtu.be/eY-gAlTcpnw

Edit: Die Wine-Version bei mir ist wine-9.2 und ich nutze Proton 8.0-5.

[Iarnród]

Welche Version von Wine ist das denn?

wine-staging 9.3~jammy-1

Tschüss
Iarnród

[Iarnród]

Guten Tag,

seit dem neusten Zusi-Update (auf Steam) habe ich ähnliche Probleme:

Nach Installieren des Zusi-Updates blieben alle On-Board-Displays bis auf genau eins schwarz und ich konnte auch nur ein funktionierendes externes ZusiDisplay starten. Dieses Problem hat sich bei mir seltsamerweise gelöst, indem ich via winetricks versucht habe, Dotnet 3.5 und Dotnet 3.5 SP 1(?) zu installieren und bei beiden Installern auf Fehler gestoßen bin. Ich weiß nicht, ob das nur ein Zufall war, aber nach diesen Installationsversuchen habe ich Zusi gestartet - beim Laden einer Timetable beschwert es sich zwar über fehlendes Dotnet 3.5 - aber alle integrierten Displays gehen wieder und die externen Displays brauchen jetzt etwas länger, die Verbindung zum TCP-Server aufzubauen, aber es gehen immerhin wieder mehrere.

Ich hatte bei mir bereits dotnetcoredesktop3 installiert. Was genau von .NET hast Du mit winetricks installiert?

Tschüss
Iarnród

[Trojaner]

Hi, dotnetcoredesktop3 hatte ich komplett übersehen - ich redete von dotnet30sp1 und dotnet30. Ich habe dotnetcoredesktop3 jetzt auch nachinstalliert, aber der Stand hat sich absolut nicht geändert; die Probleme sind immer noch da :/

[F. Schn.]

Also auf dem Papier sollte kein dotnet über winetricks mehr nötig sein, sofern man den Gleisplaneditor nicht braucht. Über winetricks sollte noch gdiplus und corefonts nötig sein, und für .Net 6 sollten die zwei Installer-Exe-Dateien auf dem Stick ausreichen (und mit wine funktionieren).

[Flo Zille]

winetricks gdiplus ist evtl. inzwischen auch verzichtbar, ich nutze soweit ich weiß die standardmäßige gdiplus aus Proton 8 bislang ohne Probleme (bis auf die jetzt seit dem Zusi-Update auftretenden dunklen Displays im Führerstand). Die Performance der integrierten ZusiDisplays wird mit der nativen gdiplus aus winetricks aber vermutlich besser sein, und die gdiplus aus Proton oder aus wine-staging hat vermutlich auch zumindest etwas bessere Performance als die wine-gdiplus, falls sich da nicht was geändert hat. Die Verkleinerung der ZusiDisplay-Darstellung auf "richtige Führerstandstexturgröße" ist in der wine-gdiplus nicht wirklich optimiert und frisst viel Zeit, so dass manche Displays je nach CPU-Leistung "hinterherhinken" könnten.

Das mit den corefonts ist jedenfalls keine schlechte Idee, damit die Anzeige überall passt.

dotnet-mäßig habe ich genau wie du sagst einfach den bei Steam automatisch beim ersten Start aufploppenden dotnet-Installer durchlaufen lassen, das hat genügt. Jedenfalls vor einem Jahr oder wann das war. Befindet sich im Zusi-Verzeichnis bei mir wohl unter "_redist/dotNET/6.0/windowsdesktop-runtime-6.0.13-win-x64.exe". Aber Achtung: Das geht nur mit relativ neuen wine-Versionen, oder schon seit längerer Zeit mit wine-staging oder Proton. Zuvor ist der 64bit-Installer immer hängen geblieben oder hat sonstige Fehler gehabt (wegen häufigen Stack Overflows in 64bit-dotnet-Anwendungen) und die Installation war dann kaputt.

Allerdings habe ich seit dem jüngsten Zusi-Update wie gesagt jetzt auch diese Probleme mit den teils dunklen Displays. Ich hatte im "Testbericht unter Linux"-Thread schon Auszüge aus den ZusiDisplay-Logs gepostet (muss man erst in den ZusiDisplay-Settings aktivieren und findet sie dann im eigenen Arbeitsverzeichnis unter _Tools, standardmäßig ist das bei Nutzung von Steam glaube ich im Steam-Bibliothekspfad wie z.B. ~/.steam und dann steamapps/compatdata/1040730/pfx/drive_c/users/Public/Documents/Zusi3Steam/_Tools). Da ist zumindest mal ein Fehler aufgetaucht, allerdings kann es natürlich sein, dass dieser Fehler ganz normal ist. Vielleicht kann das ja jemand mit den Logs unter Windows vergleichen. Falls nicht, werde ich es wohl früher oder später mal selbst tun. Nur mein Windows ist noch auf Magnetfestplatte und hat seit vielen Monaten keine Updates gesehen, das ist dann immer etwas nervig, also versuche ich es noch hinauszuschieben und hoffe, dass jemand anderes in seine Logs schaut.

Eine Strecke mit FIS habe ich seit dem Update noch gar nicht ausprobiert. Oder jedenfalls war ich der Meinung, dass das FIS nicht klappte, weil die neuen Fahrpläne noch nicht dafür konfiguriert waren. Aktivieren konnte ich das FIS über das Display links jedenfalls, nur es wurde dann nichts angesagt (neue Siegstrecke und neue Hameln-Hildesheim-Strecke).

[Flo Zille]

Ich hatte mir die Sache jetzt ein wenig angeschaut, aber so richtig die zündende Idee, was falsch läuft, habe ich noch nicht.

Alle erforderlichen ZusiDisplay-Prozesse scheinen zu starten und dann auch irgendwas zu arbeiten, obwohl keine Displays angezeigt werden. Jedenfalls belasten sie die CPU. Allerdings erheblich weniger als der eine Prozess für das Display ZD_MTD, welches korrekt angezeigt wird. Es sind bei mir 170% CPU-Auslastung für ZD_MTD und jeweils ~5% für den Rest. Vermutlich müsste bei den nicht funktionierenden Displays da eigentlich deutlich mehr passieren.

Vorausgesetzt ich habe bei der Einfügung von Debug-Ausgaben in die named_pipe.c des wineservers keine Fehler gemacht, verbinden sich die ZusiDisplay-Prozesse der nicht funktionierenden Displays zwar mit der \\??\\pipe\\Zusi3ZusiDisplayPipe, es erfolgt dann aber keinerlei Kommunikation darüber. Die gibt es nur über zwei dieser Verbindungen über die Zusi3ZusiDisplayPipe: Über die eine findet nach HELLO und NEEDED_DATA jede Menge Datenaustausch zum Zustand des Zugs statt, hauptsächlich in Richtung Zusi->ZusiDisplay. Über die andere scheint es nur in der Richtung ZusiDisplay->Zusi Kommunikation zu geben, und zwar GRAPHIC-Befehle mit einem 10-20kb großen PNG für ZD_MTD, also dem in diesem Führerstand funktionierenden Display (welches auch der ZusiDisplay-"pipeMaster" ist).

Wie beim Fehler aus den ZusiDisplay-Logs kann es natürlich sein, dass das so der korrekte Zustand ist und die übrigen Pipe-Verbindungen tatsächlich in meinem Testszenario (Fahrplan Augsburg-Donauwörth laden, Zugfahrt 57011 fertig laden lassen und dann Zusi direkt wieder beenden) gar nicht genutzt werden sollen, sondern alles über diese beiden genutzten Verbindungen abgewickelt werden soll.

Edit: Was auch noch auffällt – die ZusiDisplays außer ZD_MTD verbinden sich über TCP-Port 41801 wohl mit dem pipeMaster und schicken dann auch einige Daten dort hin, aber sie erhalten über diese TCP-Verbindung keine Antwort. Auch wieder unklar, ob es normal ist. Aber irgendwann werde ich mal unter Windows schauen, wie es da aussieht.

[F. Schn.]

Also: Der Sollablauf wäre folgender:
1 Verbindung vom Master zu Zusi, über das Zusi Zugdaten an den Master übergibt
1 Verbindung von jedem Master und jedem Client zu Zusi, über das ZusiDisplay seine Grafiken an Zusi sendet
1 Verbindung von jedem Client von ZusiDisplay zum Master von ZusiDisplay. Diese wird vermutlich der Knackpunkt sein.

[Flo Zille]

Danke, das ist hilfreich!

Da schließe ich mich deinem Urteil an. Die Pipe-Verbindung 1) aus deiner Liste, zwischen Zusi und Master mit den Zugdaten, scheint zu funktionieren mit reichlich vernünftig aussehenden "Knotenübertragungen". Die Pipe-Verbindungen 2) aus deiner Liste werden zwar aufgebaut, es wird aber über die Verbindungen der ZusiDisplay-Clients nichts geschickt, nur der pipeMaster sendet regelmäßig seine ZD_MTD-Textur über seine Verbindung. Und deine 3) aus der Liste sind TCP-Verbindungen, oder? Da scheint es jedenfalls entsprechende Verbindungen zu geben, über die aber bei mir offenbar nur Daten von den ZusiDisplay-Clients an den Master geschickt werden, ohne dass Antworten kommen – jedenfalls wenn ich wireshark noch richtig bediene/verstehe, ist eine Weile her.

Ich hab auch alte ZusiDisplay-Logs von einer früheren Version (ebenfalls unter Linux ausgeführt) gefunden und verglichen, und im Master-Log fehlen nach dem Update jetzt diese Zeilen, ansonsten keine für mich auffälligen Unterschiede – auch der "Leeres Paket soll intern verteilt werden mit ID '990007'" Fehler ist dort schon enthalten. Könnte vielleicht ein Hinweis sein, dass irgendwas in Wine den ZusiDisplay-Master daran hindert, die Verbindung "richtig" anzunehmen. Im TCP-Sinne ist sie aber korrekt zustandegekommen.

2023-05-11 14:34:55.5605|INFO|MMI.MVB.MVB|Connected to new client: 127.0.0.1:37081
[..]
2023-05-11 14:34:55.5718|INFO|MMI.MVB.MVB|Connected to new client: 127.0.0.1:37753
2023-05-11 14:34:55.5897|INFO|MMI.MVB.MVB|Connected to new client: 127.0.0.1:45409
2023-05-11 14:34:55.5998|INFO|MMI.MVB.MVB|Connected to new client: 127.0.0.1:38227

Da habe ich also bei den named pipes möglicherweise in der falschen Richtung nach einem Wine-Problem gesucht und es ist eher irgendwas mit TCP Listening Sockets oder so.

[Flo Zille]

Tatsächlich ist das Problem wie von dir vermutet bei den TCP-Verbindungen zwischen ZusiDisplay-Clients und dem ZusiDisplay-Master.

ZusiDisplay nutzt setsockopt für diese TCP-Sockets mit den optionsnamen TCP_KEEPALIVE, TCP_KEEPINTVL und TCP_KEEPCNT, was wine mit einem Fehler quittiert. Dadurch steigt ZusiDisplay wohl an der Stelle aus. Eine kleine wine-Änderung, damit diese Aufrufe ohne Fehlerrückgabe ignoriert werden, löst das Problem mit den dunklen Displays dann auch. Ich werde also mal sehen, ob ich das irgendwie vernünftig implementiert bekomme, um es an Wine's gitlab zu schicken.

[Flo Zille]

Meine Patches für das Problem mit den dunklen Displays wurden jetzt in wine akzeptiert. Das sollte also mit Wine 9.4 (erscheint wohl nächsten Freitag) dann wieder funktionieren.