It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
avatar
ChFra: um Umkodieren möchte ich sehr allgemein anmerken, daß das nur dann klappen kann,
Die Dateien sind in VC-1 kodiert, deshalb hab ich es auch mit wmp9 probiert.
Ich hab es vielleicht oben missverständlich ausgedrückt:
Die Videos konnten kurzzeitig als "Daumenkino" abgespielt werden, nachdem diese neu kodiert wurden.

Es scheint also irgendwie zu klappen.

Wie von mir schon erwähnt, hatte ich dieses Problem in ähnlicher Form auch schon bei anderen Spielen.

avatar
ChFra: was „Selbstgestricktes“
Proprietärer Microsoft-Kram eben.

avatar
ChFra: Ach so: unter Uralt-Windows war es zeitweise üblich, irgendwelche Codec-Pakete nachzuinstallieren, damit endlich „alles“ abspielbar war.
Das kenne ich auch noch von damals. =D

Allerdings schreibt das PCGW dazu:

No cutscenes are playing
Remove any installed codec packs
Uninstall or disable any codec packs installed on your PC. This problem may be caused by the K-Lite Codec Pack.
Allerdings habe ich bisher auch noch nicht probiert ein Codec-Paket zu installieren.
Einen Versuch ist es ja wert.
(Wenn es dann klappt, attackiere ich mich hinterrücks dental.) =D


EDIT: Hab es in der Zwischenzeit mal mit allcodecs und K-Lite probiert.
Klappt nicht. Bei ersterem passiert gar nichts, sprich, es verändert sich nichts und bei letzterem werden die Zwischensequenzen einfach nicht abgespielt, sprich, das "Testbild", welches wahrscheinlich die Videos sind, wird einfach übersprungen.
Post edited June 24, 2026 by TheHexer_pcg
Habe jetzt auch länger herumprobiert und es nicht hinbekommen.
Das Video wird immer übersprungen, egal was ich tue.
avatar
Patsche85: Das Video wird immer übersprungen, egal was ich tue.
Probier mal UMU-Proton-10.0-4.
Damit kam bei mir das "Testbild".
avatar
Patsche85: Habe jetzt auch länger herumprobiert und es nicht hinbekommen.
Das Video wird immer übersprungen, egal was ich tue.
Das finde ich als "Two Worlds"-Besitzer, der auch erst vor kurzem Windoof von seinem Gamingrechner verbannt hat jetzt doch auch a bissl doooof :-((
Ich kann selbst nichts ausprobieren, eil ich das Spiel nicht besitze, aber aus Neugierde habe ich mal gesucht und das hier gefunden:

two_worlds_1_on_windows_10_pro_64_bit/post39

Zunächst hört sich das nicht nach einem (reinen) Linuxproblem an. Und die Spielerei mit den Codecs scheinen schon einigen eine Lösung gebracht zu haben. Außerdem habe ich irgendwo gelesen, das in dr "Linux"-Version eine Lösung dafür verbaut sein soll - man müsste diese nur mit dem systemeigenen WINE starten. Habt ihr das schon probiert?
Post edited June 24, 2026 by rostfreyh
avatar
rostfreyh: […] aus Neugierde habe ich mal gesucht und das hier gefunden:
Das ist genau das, was ich in #672 schon erwähnt habe.

avatar
rostfreyh: Zunächst hört sich das nicht nach einem (reinen) Linuxproblem an.
Ist es auch nicht. Das liegt an dem proprietären Scheiß von MS, den die Entwickler da verwendet haben.

avatar
rostfreyh: "Linux"-Version eine Lösung dafür verbaut sein soll - man müsste diese nur mit dem systemeigenen WINE starten. Habt ihr das schon probiert?
Ja, ist noch fehleranfälliger. Da kann ich wirklich gleich die Win-Version selbst in Wine installieren.
EDIT:
Ich habe gerade nochmal geschaut, was hier der Fehler ist. Das Spiel kommt in der "Linux-Version" in einem 32 bit-Prefix.
Das kann so nicht mit dem Skript unten ausgeführt werden:

wine: '/home/Hexer/Spiele/GOG Games/Two Worlds Epic Edition German/game/Wine/prefix/.config' is a 32-bit installation, it cannot support 64-bit applications.
Wenn ich nun das Prefix ändere (vorher das alte umbenennen oder löschen):

WINEARCH=win64 WINEPREFIX="/home/Hexer/Spiele/GOG Games/Two Worlds Epic Edition German/game/Wine/prefix/.config" winecfg
Moniert das Spiel, dass es gerne neu installiert werden will:

Game isn't properly installed.
Please reinstall programm.
Jetzt kann ich natürlich schauen, dass ich eventuell das Spiel nochmal in das neue Prefix installiere oder die Reg-Keys aus dem alten Prefix übernehme.
Ich schau mir auch noch mal das RunGame-Skript genauer an.
/EDIT
EDIT2:
So, erster Versuch war der schnellste: Spiel in dem neuen Prefix installieren.

WINEARCH=win64 WINEPREFIX="/home/Hexer/Spiele/GOG Games/Two Worlds Epic Edition German/game/Wine/prefix/.config" wine start /unix "/Pfad/Zum/Setup/setup_two_worlds_epic_edition_german_2.2.0.23.exe"
Keine Videos.
Mal schauen, vielleicht vergleiche ich mal die Reg-Einträge.
/EDIT2
EDIT3
Hab auch nochmal probiert die Videos der "Linux-Version" umzukodieren. Bringt auch nichts.
Die Videos werden weiterhin übersprungen.
/EDIT3

Gibt es auch im PCGW ein Skript für.
https://www.pcgamingwiki.com/wiki/Two_Worlds#Crash_on_linux_due_to_incompatible_bundled_wine
Post edited June 25, 2026 by TheHexer_pcg
Hab mal ein bisschen mit fastfetch rumgespielt.

Nicht besonders "fancy" aber ich mags. (siehe Anhang)

Das Fenster ist leicht transparent, durch picom.
Attachments:
ffetch.jpg (177 Kb)
Post edited June 30, 2026 by TheHexer_pcg
Moin,

ich möchte kurz meine aktuellen Erfahrungen mit dem Online-Shop Linux-Sticker.de (betrieben von Chris Unger Online-Handel) teilen, um andere vor dem dortigen Geschäftsgebaren zu warnen.

Hier ist der exakte, über E-Mails belegbare Ablauf:

23.05.2026:
Ich habe im Shop Sticker bestellt und den Betrag (8,79 Euro) sofort per Echtzeitüberweisung bezahlt.

26.05.2026:
Das Geld wurde laut meinem Bankbeleg erfolgreich verbucht.

02.06.2026:
Nach anderthalb Wochen Funkstille habe ich nachgefragt, wo die Sticker bleiben. Erst daraufhin meldete sich der Shop mit einer automatischen Mail und der Behauptung, es sei kein Geld da. Ich habe noch am selben Tag den Nachweis meiner Volksbank hingeschickt.


05.06.2026 (10:44 Uhr):
Ich habe die Bestellung offiziell per E-Mail widerrufen und den Händler explizit aufgefordert, die Ware nicht mehr zu versenden.

06.06.2026 (10:33 Uhr):
Erst einen Tag nach meinem Widerruf reagierte der Händler und behauptete plötzlich, die Ware sei jetzt versendet worden.

20.06.2026:
Da nach zwei weiteren Wochen immer noch nichts im Briefkasten lag, habe ich offiziell den Widerruf erklärt und eine Frist zur Rückerstattung des Geldes bis zum 01.07.2026 gesetzt.

Stand heute (01.07.2026):
Die Frist ist fruchtlos verstrichen. Es gab weder eine Reaktion auf meinen Widerruf noch mein Geld zurück.

Dass ein normaler Inlandsbrief über einen Monat nach der Bestellung und fast vier Wochen nach der angeblichen Versandbestätigung nicht ankommt, ist unmöglich.
Da der Shop nun auch die gesetzliche Rückzahlung ignoriert, werde ich rechtliche Schritte (Onlinewache/Mahnverfahren) einleiten.

Ich kann nach dieser Erfahrung nur dringend davon abraten, dort per Vorkasse zu bestellen.
Moin Patsche,

das ist ja richtiger Mist.

Ich hoffe, du hast Erfolg damit. So was geht gar nicht.
linux-fanshop.de
linux-shop.info
Scheint alles der/dasselbe zu sein...
avatar
schmoemi: Scheint alles der/dasselbe zu sein...
Das riecht ja schon irgendwie nach Beschiss.

linux-fanshop konnte ich mit dem Browser nicht ansurfen. Server nicht gefunden.
Ja, im Ubuntuforum wurde ich schon darauf hingewiesen, dass es mindestens 3 Shops gibt:

https://www.linux-sticker.de/impressum
https://www.linux-fan-shop.de/impressum
https://www.linux-shop.info/impressum

Nervt nur immer der ganze Aufwand. Ichj hätte ja auch kein Problem damit, dass gesagt wird, dass er verlorengegeangen ist, oder dass der Shop es doch nicht geschafft hat.
Aber dieses konsequente Ignorieren meiner Emails ist das, was mich stört.
Z.Zt. habe ich ein Problem mit GOG über Heroic. Das äußert sich darin, daß die Webseite nicht lädt, weder die Shopseite noch die Anmeldeseite. Erst erscheint eine Zeit lang das "Lade Seite" Rotierteil, dann verschwindet das und die Seite bleibt komplett schwarz, in der Adreßleiste steht dann der Link, der in einem normalen Browser auch einwandfrei funktioniert.
Ich konnte das Problem inzwischen auf HTTPS über IPv6 auf Debian eingrenzen (Trixie): benutze ich den Befehl curl -6 -Iv "https://auth.gog.com", bleibt es bei der TLS-Aushandlung hängen, während curl -4 -Iv "https://auth.gog.com" normal durchläuft. Im selben Netz auf einer OpenBSD-Maschine funktionieren beide Befehle einwandfrei. Ich gehe also davon aus, daß sowohl das Netzwerk als auch der ISP OK sind. Da es bis zur TLS-Aushandlung kommt und die Namensauflösung korrekt funktioniert, liegt es wohl auch nicht an DNS. rostfreyh hatte mir netterweise via PN mitgeteilt, daß es auf Mint mit IPv6 im Wesentlichen funktioniert.

Aber woran liegt es dann? Ich könnte zwar IPv6 abschalten, so daß die GOG-Seite funktioniert, aber ich brauche IPv6 für Murmur.
Hat sonst noch jemand IPv6 und Debian Trixie und könnte das mal gegenprüfen? der o.g. Befehl genügt, man braucht weder Heroic noch einen GOG-Account, um das zu testen, und es geht ohne privilegierten Zugriff, es wird einfach nur die Seite geladen und die Handshake-Infos angezeigt.

Wenn es fehlschlägt, sieht das so aus:

$ curl -6 -Iv "https://auth.gog.com"
* Host auth.gog.com:443 was resolved.
* IPv6: 2a04:4e42:8e::497
* IPv4: (none)
* Trying [2a04:4e42:8e::497]:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
(hiernach hängt es)

Wenn es OK ist, sieht es so aus:

$ curl -4 -Iv "https://auth.gog.com"
* Host auth.gog.com:443 was resolved.
* IPv6: (none)
* IPv4: 146.75.121.241
* Trying 146.75.121.241:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / X25519MLKEM768 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
* subject: C=PL; L=WARSZAWA; O=GOG sp. z o.o; CN=gog.com
* start date: Feb 11 00:00:00 2026 GMT
* expire date: Mar 14 23:59:59 2027 GMT
* subjectAltName: host "auth.gog.com" matched cert's "*.gog.com"
* issuer: C=US; O=DigiCert Inc; CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
* SSL certificate verify ok.
* Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* Certificate level 2: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* Connected to auth.gog.com (146.75.121.241) port 443
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://auth.gog.com/
* [HTTP/2] [1] [:method: HEAD]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: auth.gog.com]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.14.1]
* [HTTP/2] [1] [accept: */*]
> HEAD / HTTP/2
> Host: auth.gog.com
> User-Agent: curl/8.14.1
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Request completely sent off
< HTTP/2 404
HTTP/2 404
< server: openresty/1.31.1.1
server: openresty/1.31.1.1
< content-type: application/json
content-type: application/json
< cache-control: no-cache, private
cache-control: no-cache, private
< x-origin-age: 0
x-origin-age: 0
< accept-ranges: bytes
accept-ranges: bytes
< date: Wed, 08 Jul 2026 22:55:46 GMT
date: Wed, 08 Jul 2026 22:55:46 GMT
< via: 1.1 varnish
via: 1.1 varnish
< x-served-by: cache-fra-etou8220135-FRA
x-served-by: cache-fra-etou8220135-FRA
< x-cache: MISS
x-cache: MISS
< x-cache-hits: 0
x-cache-hits: 0
< vary: Accept-Encoding
vary: Accept-Encoding
< content-length: 81
content-length: 81
<

* Connection #0 to host auth.gog.com left intact
Hat Debian Trixie ein Zertifikatsproblem?
OpenBSD sagt:

$ curl -6 -Iv "https://auth.gog.com"
* Host auth.gog.com:443 was resolved.
* IPv6: 2a04:4e42:8e::497
* IPv4: (none)
* Trying [2a04:4e42:8e::497]:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
* CAfile: /etc/ssl/cert.pem
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Unknown (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
* subject: C=PL; L=WARSZAWA; O=GOG sp. z o.o; CN=gog.com
* start date: Feb 11 00:00:00 2026 GMT
* expire date: Mar 14 23:59:59 2027 GMT
* issuer: C=US; O=DigiCert Inc; CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
* Certificate level 0: Public key type ? (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* Certificate level 1: Public key type ? (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* Certificate level 2: Public key type ? (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* subjectAltName: "auth.gog.com" matches cert's "*.gog.com"
* OpenSSL verify result: 0
* SSL certificate verified via OpenSSL.
* Established connection to auth.gog.com (2a04:4e42:8e::497 port 443) from <edited out private IP> port 45246
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://auth.gog.com/
* [HTTP/2] [1] [:method: HEAD]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: auth.gog.com]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.19.0]
* [HTTP/2] [1] [accept: */*]
> HEAD / HTTP/2
> Host: auth.gog.com
> User-Agent: curl/8.19.0
> Accept: */*
>
* Request completely sent off
< HTTP/2 404
HTTP/2 404
< server: openresty/1.31.1.1
server: openresty/1.31.1.1
< content-type: application/json
content-type: application/json
< cache-control: no-cache, private
cache-control: no-cache, private
< x-origin-age: 0
x-origin-age: 0
< accept-ranges: bytes
accept-ranges: bytes
< date: Wed, 08 Jul 2026 23:04:27 GMT
date: Wed, 08 Jul 2026 23:04:27 GMT
< via: 1.1 varnish
via: 1.1 varnish
< x-served-by: cache-fra-etou8220046-FRA
x-served-by: cache-fra-etou8220046-FRA
< x-cache: MISS
x-cache: MISS
< x-cache-hits: 0
x-cache-hits: 0
< vary: Accept-Encoding
vary: Accept-Encoding
< content-length: 81
content-length: 81
<

* Connection #0 to host auth.gog.com:443 left intact
Ohne HTTPS geht es auch mit IPv6 auf Debian Trixie, es scheitert also wirklich nur an der Aushandlung.
Post edited July 09, 2026 by Dawnsinger
OK, Problem gelöst: es lag natürlich doch an meinem Netzwerk. Ich hatte vergessen, MSS Clamping in der Firewall zu aktivieren. Ob jetzt PMTU Discovery bei IPv4 funktioniert und bei IPv6 nicht, oder es einfach daran liegt, daß IPv6 unterwegs nicht fragmentiert, weiß ich nicht und auch nicht, weshalb OpenBSD im Gegensatz zu Debian trotzdem die richtige Paketgröße hinbekommen hat. Ist ja auch egal: wenn das hier jemand findet, steht hier jedenfalls die Lösung. :) Bei PPPoE ist die Basisgröße dafür 1492, andere Zugangsformen und besonders VPNs (sofern nicht clientbasiert) haben natürlich andere, meistens deutlich kleinere, Werte.
Post edited July 10, 2026 by Dawnsinger