Beiträge von Lehmden1

Hi.

Zitat von te36

In Windows benutzt jeder brave Benutzer ja auch das Icon in der Taskleiste oder so um Wechselplatten auszuhängen bevor man sie ausschaltet oder abklemmt.

Ist seit mindestens 10 Jahren nicht mehr nötig. Dafür gibt es, seit mindestens Windows 7 (ich meine schon seit Win XP oder noch früher) einen Haken in der Konfiguration, mit dem man das abschalten kann. Dann wird das Icon erst gar nicht mehr angezeigt, weil es nichts mehr bringt. Ich weiß gar nicht, wann ich das Ding zum letzten Mal gesehen habe. Auf jeden Fall mehr als ein Jahrzehnt her. Denn das hat sowieso keiner gemacht sondern die USP Platte einfach abgezogen.

Zitat von te36

Zum Umformattieren brauchst Du bei N (beliebig groß) nur eine Platte die so gross ist, wie die größte der N Platten.

Schenkst du mir mal eben eine 18 TB Platte? Die kostet ungefähr ein Monatseinkommen (zumindest eines von meinen aktuellen). HDD sind aktuell einfach unbezahlbar. Kannste knicken, keine Chance... Mal ganz abgesehen davon, dass das mindestens eine Woche dauern würde, bis ich wieder was mit Kodi anfangen könnte. 45 TB (über 20 Jahre angesammelt) zweimal umkopieren dauert einfach ewig, besonders bei eher lahmen weil leisen 3,5 Zoll HDD... Dazu kommt, ich müsste das Umkopieren auf jeden Fall unter Windows machen, womit wir wieder das ext4 Problem haben oder für ne Woche mein Netzwerk lahmlegen. Nein, das kommt unter gar keinen Umständen in Frage. Viel zu teuer, viel zu aufwändig und viel zu wenig Nutzen. Dazu hat das Problem von oben rein gar nix mit dem Dateisystem zu tun. Das ist ein Hardware Problem (des Gehäuses?). Ich hab spaßeshalber mal ne alte, leere HDD in das Gehäuse gesteckt und in OMV formatiert. Das Ergebnis ist exakt dasselbe wie mit der unter Windows formatierten NTFS Platte...

Zitat von PvD

systemctl

Ist schon installiert gewesen, also kann ich mich durch das Tutorial wühlen. Danke noch mal.

PvD "sudo mount -a" tut es tatsächlich, danke sehr. Nun muss ich mir nur noch was ausdenken, wie ich das automatisiert bekomme. Zur Not als cronjob alle 30 Sekunden laufen lassen, wenn mir nix besseres einfällt.

te36 Ich hab schon mal gesagt, es ist keine Option die Platten alle umzuformatieren. Alleine schon, weil ich dabei alle meine Daten verlieren würde, denn ich habe keinen Platz, um die Daten währenddessen abzusichern. Außerdem weigere ich mich, alle meine gesammelten Daten mir von einer reinen Zusatzkiste abhängig zu machen. An NTFS komme ich immer und überall dran, an ext4 nur von Linux aus. Erst wenn ext4 auch bei Windows, Android und Mac standardmäßig unterstützt wird, kann man darüber nachdenken. Bis das passiert, ist ext4 für meine Daten absolut verboten. Nat nix mit der Qualität des einen oder anderen Systems zu tun, sondern ausschließlich mit der Verfügbarkeit.

Inzwischen denke ich, das es ein Problem mit den Linux Treibern für den im Festplattengehäuse verwendeten USB-SATA Bridge Chip ASMedia ASM1153 gibt. Die "kleine" Platte hat wohl ein Gehäuse erwischt, mit einem besser zu Linux passenden Chip. Unter Windows funktioniert das ASMedia Teil seit Jahren völlig problemlos. Aber unter Linux ist ja leider all zu oft gängige Hardware nicht oder nur eingeschränkt nutzbar, weil es gar keine oder nur fehlerhafte Treiber gibt. Ich dachte ja, das wäre inzwischen weniger problembehaftet, aber offenbar ist das immer noch eine große Sache. Irgendwo müsste ich noch ein anderes externes Gehäuse rum fliegen habe. Allerdings weiß ich natürlich nicht, was da für ein Chip drin ist und ob der vielleicht besser unter Linux läuft. Wenn ich das finde, stecke ich die Platte mal um und probiere dann erneut. Außerdem könnte ich die Platte ja auch mal an meinen LibreElec RasPi anschließen. Da läuft ja auch Linux, in sofern... Aber nicht mehr heute.

Ich habe inzwischen probiert, nur das USB Kabel abzuziehen, was bei der "kleinen" Platte ohne eigenes Netzteil noch einwandfrei funktioniert hat. Dann passiert mit der 3,5 Zoll Platte leider exakt dasselbe wie oben wenn ich den Strom ausschalte. Danach ist die Platte vermurkst eingehängt und absolut unbrauchbar. Das hat also nichts damit zu tun, das ich den Strom ausschalte. Die Platte lässt sich nicht erneut mounten, wenn sie schon mal gemountet war.

Ich kann also nur noch auf einen "Linux Zauberer" hoffen, der weiß, wie man das Problem abstellt. Sonst wird das nichts mehr.

Hi.

Nachdem ich mein OMV System aufgesetzt habe, hatte ich ja probiert, ob es problemlos möglich ist, ein USB Laufwerk einzubinden und es bei Nichtgebrauch wieder abziehen zu können. Das hat funktioniert. Leider hatte ich nicht getestet, was z.B. bei externen 3,5 Zoll HDD passiert, wenn man dort die Platte ausschaltet, die ja eine eigene Stromversorgung hat. Das haut nämlich nicht hin.

OMV bemerkt die Platte zwar als "Missing", wenn der Strom aus ist.

So sah es auch bei der 2,5 Zoll Platte aus, wenn ich den USB Stecker abgezogen habe. In soweit alles "normal".

Wenn ich den Strom wieder einschalte, wird die Platte aber nicht wiederhergestellt. Die Platte ist dann zwar wieder "Online", hat aber keinen Speicherplatz mehr. Das wäre aber für meinen Zweck ein essentielles Feature und absolut unverzichtbar, auch wenn das vielleicht kein typisches Szenario ist. Ich kann und will keine Platte, die vielleicht 2 Stunden pro Woche gebraucht wird, 24/7 laufen lassen. Denn auch wenn die Platte nicht dreht, braucht sie genau so viel (eher sogar mehr) Strom wie mein ganzer Server. Wenn sie den Strom verbraucht, während sie benötigt wird, ist alles gut. Aber wenn sie nicht benötigt wird, muss man sie ausschalten können, und das völlig unproblematisch. In der Endausbaustufe hätte ich dann 5 oder 6 solcher Platten am Server hängen. Unbezahlbar und ein absolutes NoGo.

Unter Windows (und sogar Android) funktioniert das übrigens seit vielen, vielen Jahren völlig problemlos. Also nicht ankommen mit "darf man nicht machen", "geht gar nicht" oder so was. Es geht nämlich ganz sicher, nur vielleicht unter Linux nicht, was ich aber nicht hoffen will. Ich hoffe ja auf meine Unkenntnis von Linux, nicht darauf, das es gar nicht geht.

In OMV habe ich keine Einstellung gefunden, um die Platte wieder "vernünftig" einzubinden. Ich müsste erst die SMB Freigabe löschen, den freigegebenen Ordner entfernen und die Platte aushängen. Und dann alles wieder von vorne einrichten. Geht gar nicht...

Auch ein physikalisches Abziehen des USB Steckers (was beim Laufwerk ohne eigene Stromversorgung noch problemlos geklappt hat, bringt nichts mehr, sobald die Platte mal so "vermurkst" im System hängt.

Einzig ein Neustart des ganzen Servers bindet die Platte wieder vernünftig ein. Ist die Platte bisher noch nicht bekannt, macht das Anstecken der Platte ja keine Probleme. Sobald die Platte aber im System bekannt ist, funktioniert es nicht mehr.

Gibt es einen Linux Befehl, der das Problem behebt und /oder etwas, das man z.B. per Cron laufen lassen kann, damit das Laufwerk automatisch wieder richtig gemounted wird, wenn es "missing" war, ohne den Server komplett neu zu starten?

Sollte das nicht möglich sein, steht fest, das ich ganz sicher kein Linux- basiertes NAS einsetzen werde sondern (mal wieder) wie bisher bei Windows bleiben muss. Eigentlich hatte ich ja gehofft, den Extra Rechner auf Dauer abschaffen zu können und die Platten meines NAS an den OMV Server anschließen zu können, doch dann muss es möglich seit, aus der ferne die Platten auszuschalten und später wieder einzuschalten, wie sie gebraucht werden ohne jedes Mal den Server neu starten zu müssen. Im Moment geht das Ausschalten bei der einen Platte, mit der ich grade getestet habe, ganz leicht über einen Smart Plug. Windows hat damit absolut keine Probleme. Aber Linux scheint damit einfach nicht klar zu kommen. Zumindest habe ich nicht rausfinden können, wie man das unter Linux hin bekommt.

Sowas ist ein für mich absolut unverzichtbares Feature, grade in Zeiten des Klimawandels. Denn das ist einfach überflüssige Verschwendung von Energie und verkürzt die Lebensdauer der Hardware obendrein deutlich. Es ist nun mal was ganz anderes ob ein Gerät 2 oder 168 Stunden pro Woche läuft.

Hi.

Jetzt habe ich auch den zweiten JDownloader über VPN mit AT IP laufen. Hab das File von telerising und das von meinem "normalen" JDownloader kombiniert, Namen, Pfade und den (externen) Port geändert und... läuft sofort. Langsam habe ich den Dreh scheinbar raus.

Den Firefox Docker hab ich komplett runter geschmissen. Das bringt keine Vorteile gegenüber einem lokal auf dem Desktop installieren Firefox. Hat dafür aber ziemlich viel CPU Load verursacht. Und die zur Zeit nicht benötigten Container habe ich abgestoppt. Z.B. den zweiten JDownloader, da ich aktuell nix aus der ORF Mediathek laden muss. Wenn ich ihn brauche ist der ja ruckzuck wieder gestartet. Spart noch mal CPU Load und somit auch Strom. Jetzt fehlt mir "nur" noch mein Glasfaser, dann kann ich voll durchstarten. Vorbereitet ist schon mal alles, so weit es möglich ist.

Ich weiß nur immer noch nicht, ob ich doch noch mal auf Kodi 21 zurück wechseln soll. Eine Kodi 21.3 Stable ist in absehbarer Zeit wesentlich wahrscheinlicher (4 "open issues" bis zum Milestone) als eine Kodi 22.0 Stable. So langsam wie es mit 22 vorwärts geht (wenn es dieselben Zyklen wie bisher gäbe, müssten wir schon bei Kodi 23 RC sein, haben aber noch nicht mal 22 Beta), kann sich das locker noch bis 2027 hinziehen. Die 21.2 (1 - 0) funktionieren ja leider nicht vernünftig mit Waipu, was ich noch bis Ende September habe, die aktuelle 21 Nightly (aka fast 21.3) hingegen schon. Doch dann hänge ich wieder mit den Nightly rum, was ich eigentlich gar nicht mag. Allerdings muss ich meine Datenbank jetzt sowieso neu machen, da sie ja aktuell noch auf dem Windows 11 Mini PC läuft, aber natürlich auf den OMV Server umziehen muss. Da würde es sich ja anbieten, gleich einen Versionswechsel nach "unten" vorzunehmen. Auf eine neuere "höhere" Version läuft die Migration ja vollautomatisch und bisher zumindest immer problemlos und fehlerfrei.

Hi.

Ich bin ja schon vor längerer Zeit auf Kodi 22 Nightly umgestiegen, um meine Waipu Aufnahmen anschauen zu können, da es in Kodi 21 (0-1-2) einen (bekannten) Bug gibt, der bei allen PVR Addons Probleme verursachen kann, sich aber nirgends so heftig auswirkt wie bei Waipu. Weil es dieses Mal wirklich sehr lange dauert, bis aus der Nightly eine "Beta" oder gar Stable wird und die aktuellen 22 Nightlys noch nicht sonderlich stabil laufen, habe ich auf meinem Windows Desktop System noch mal mit Kodi 21 experimentiert. Die 21.2 Stable hat definitiv diesen Bug, leider. Läuft auch komplett frisch aufgesetzt einfach nicht vernünftig mit Waipu. Damit kann ich einfach keine Aufnahmen im Waipu PVR Addon abspielen. Es hätte mich allerdings sehr überrascht, wenn es jetzt plötzlich doch geklappt hätte. Unter 22 Nightly funktioniert das Ganze weiterhin problemlos.

Nun habe ich aber zufällig gelesen, das es wohl noch eine weitere Kodi 21 Version geben soll, bevor die 22 stable wird, eine 21.3. Laut Github sind noch 4 "issues" offen bis zum "Milestone". Daraufhin habe ich mal die Kodi 21 Nightly von gestern installiert. Im Gegensatz zur Bezeichnung Nightly gibt es nur etwa eine neue Version pro Woche. Die von Gestern ist also ziemlich frisch. Also einfach mal installiert, und was soll ich sagen. Waipu Aufnahmen funktionieren tadellos. Im Gegensatz zu früheren Aussagen ist der Fix offenbar doch aus 22 zurück portiert worden zu Kodi 21. Vielleicht weil es mit 22 einfach nicht vorwärts geht und es nun eben doch eine weitere Kodi 21 Version geben wird um die Wartezeit auf Kodi 22 Final zu überbrücken. Und mal ganz ehrlich, abgesehen von dem Waipu PVR Problem habe ich rein gar nichts bei Kodi 22 entdeckt, das mich zu einem Umstieg von 21 bewegen würde. Ich schätze, mit den (personellen) Möglichkeiten, die das aktuelle Dev Team hat, wird es wohl keine "großen Sprünge" mehr geben können. ich werde das weiter beobachten und ggfs. demnächst doch noch mal zurück auf Kodi 21 wechseln. Da ich meine MySQL Datenbank sowieso bald auf einen anderen Server umziehen muss, ist das der genau richtige Zeitpunkt dafür.

Hi.

Zitat von te36

So werde ich kein Fan von Containern.

Also im Vergleich zu dem Rumgemurkse, das man (ich) sonst unter Linux hat, empfinde ich das hier eher als Selbstläufer... Dafür, das ich mich erst seit ein paar Tagen mit Docker beschäftige, bin ich schon ziemlich weit gekommen. Wenn auch teilweise nur mit Hilfe aus dem Forum. Vielen Dank dafür.

Eigentlich läuft inzwischen alles, was ich wollte. Ich habe die telerising API funktionsfähig über VPN laufen. Auch Pi-Hole habe ich im Docker hin bekommen, was ebenfalls schon etwas komplizierter als "Normal" ist. Das ich mit TVHeadend immer noch auf dem Kriegsfuß stehe, hätte ich sowieso nicht anders erwartet. TVH und ich, das hat noch nie wirklich harmoniert. Und das mein (noch) extrem lahmes Internet seinen Teil dazu beiträgt, alles zu verkomplizieren, ist auch nicht überraschend.

Was ich noch ausprobieren werde, ist es eine zweite Instanz eines Docker Images mit unterschiedlicher Konfiguration ans laufen zu bekommen. Genauer, einen zweiten JDownloader über VPN statt wie der bereits laufende direkt verbunden. Auch beim Download hat man häufiger mit Geoblocking zu tun. Inhalte aus der ÖR Mediathek ist gelegentlich mit Geoblocking versehen. Dazu müsste man also in DE sein. Daneben sind dann die Inhalte aus der ORF Mediathek fast alle mit Geoblocking versehen, wozu man in Österreich sein müsste, usw. Echt traurig innerhalb der EU. Wieso sowas erlaubt ist, obwohl das allen EU Gesetzen widerspricht, wird mir auf Ewig ein Rätzel bleiben. Nicht, warum das gemacht wird (es geht ums Geld), sondern das es legal ist, das erstaunt mich.

Um nicht immer manuell den VPN ein- aus und um- zu schalten, eben separate Docker mit verschiedener Konfiguration. Neu ist für mich hierbei, einen zweiten Container mit demselben Image zu erzeugen, der dann eben durch den VPN läuft. Als Ausgangspunkt kommen die Compose Files von JDownloader und telerising, die ich schon laufen habe, zur Verwendung. Natürlich dann angepasst an die neuen Umstände. Das werde ich nun als nächstes in Angriff nehmen. Andere Ports sind selbstverständlich. Aber wie sieht das mit den Namen der Container aus? Vermuten würde ich, das auch die unterschiedlich sein müssen. Aber sicher wissen tue ich das nicht.

Zitat von easy4me

Wenn Telerising nativ auf meinem VPS mit 100 MBit/s Uplink läuft, dann gibt es kein Buffering hier (VDSL 250 MBit/s). Dürfte wohl an deiner VPN-Verbindung und an der Internetgeschwindigkeit liegen.

Hatte ich befürchtet. Danke dir. Also ist warten auf besseres Internet angesagt. Bis dahin muss es die Windows 11 Geschichte eben tun.

Noch mal ich, diesmal aber wohl hier passend...

Nachdem ich den Docker nun richtig laufen hatte, wollte ich natürlich die Proxy Funktion von telerising testen, die für mein geplantes Szenario essentiell ist. Generell funktioniert es und ich kann den telerising Stream auf einem System abspielen, der nicht dieselbe "Nationalität" hat wie die API selbst. Das ist schon mal super. Allerdings ist der Stream tatsächlich, wie angemerkt heftig am buffern. Was verursacht das eigentlich?

Zumindest von der Celeron N3350 CPU her sollte auf meinem System mehr als genug Leistung zur Verfügung stehen. Durch den Proxy Stream geht die CPU Last grade mal um 1% über die "Basislast" (ca 10%) hinaus. Das (lokale) Netzwerk ist mit 1 GBit sicher auch nicht das Nadelör. Bleibt eigentlich nur noch der Stream selbst, der bei meinem (noch) lahmen Internet ohne Proxy tatsächlich läuft, aber nur so grade. Der ganze IPTV Kram braucht im Vergleich zum "normalen" Streamen offenbar viel mehr Bandbreite. Kann ich beim Streamen (z.B. aus der Mediathek) problemlos 720P Streams anschauen, gelegentlich klappt das sogar mit 1080p, so langt es bei IPTV (ohne Proxy) grade eben für 432p@25. Übrigens trifft das auch auf IPTV Streams zu, die nicht über VPN laufen müssen...

Liegt das Buffern im Proxy Betrieb an meiner Internet Verbindung oder kann man die Leistung sonst irgendwie verbessern? Wenn ersteres zutrifft, brauche ich aktuell nicht weiter probieren und kann das erst im Oktober/November, wenn endlich mein Glasfaser kommt, weiter in Angriff nehmen. Ich habe bis Ende September noch Waipu und kann bis dahin noch alles nötige in der Cloud aufnehmen. Die haben aber heftig die Preise angezogen, weswegen ich das Jahres- Abo gekündigt habe. Und ich möchte nach Möglichkeit auch kein neues Abo abschließen, sondern ganz auf die telerising Lösung umsteigen, sobald ich mein Glasfaser habe. Aktuell nutze ich telerising nur für die Formel 1 (ORF und SRF). Alles andere mache ich über Waipu. Deswegen brauche ich dann auch unterschiedliche IPTV Quellen aus unterschiedlichen Ländern, um, wenn es ganz schlecht läuft, bis zu 4 Streams gleichzeitig aufnehmen zu können. Denn wenn ausnahmsweise mal was läuft, das ich sehen will, läuft das immer zur gleichen Zeit auf verschiedenen Kanälen parallel. Normal käme ich locker mit einem Stream gleichzeig hin. Aber wenn an einem Sonntag zur gleichen Zeit Formel 1, Formel E, DTM und die WEC läuft, dann müssen es halt 4 Streams gleichzeitig sein.

Nicht wirklich, oder? Oh man, wie peinlich... Man ist halt verwöhnt, weil das http normalerweise automatisch davor gesetzt wird.

Das wars in der Tat. Jetzt noch mal versuchen, ob ich die m3u auch auf einem anderen Rechner nutzen kann. Wenn das klappt, ist alles perfekt. Danke vielmals...

Ich zitiere mich mal selber:

Zitat von Lehmden1

Ist das eventuell ein Firewall- Problem?

Nein, ist es nicht. Ich hab temporär zum Testen die Firewall komplett ausgeschaltet. Das Problem besteht aber weiterhin.

Zitat von Publish3r

Ich musste damals beim OpenVPN Container --net="bridge" nehmen und bei Telerising --net=container:vpn wenn ich das noch richtig in Erinnerung habe.

Ja, das ist die "Normaleinstellung", die ich auch verwendet habe. Ich habe es inzwischen auch schon mal mit "host" beim VPN Container probiert, ändert auch gar nichts.

Zitat von fds97AVVS

da kommt dein 192... ip rein

Hab ich inzwischen mehrfach probiert.

Wenn ich das mache, geht gar nichts mehr:

Ich frage mich, wo die "komische" IP Adresse 172.21.0.2 in Telerising her kommt. Ich weiß, das 172.21.x.x ein privates Netzwerk ist, was ich aber noch nie irgendwo hatte und auch nirgends eingerichtet habe. Ich habe immer nur mit 192.168.x.x bei lokalen Netzwerken zu tun gehabt. Wenn ich die mit tracert verfolgen will, kommt nur "Zeitüberschreitung der Anforderung". Auch anpingen lässt sie sich nicht. Sie ist also von meinem Netzwerk aus nicht zu erreichen. Aber das ist die IP, die von Telerising in die m3u geschrieben wird. So kann natürlich kein erfolgreicher Zugriff stattfinden. Gebe ich aber in den Einstellungen von Telerising etwas bei "Custom IP address / domain path" ein, läuft erst Recht nix. Dann wird die Seite mit dem Web Player erst gar nicht geladen und es kommt nur ein Wort, "Error" auf einer sonst leeren Seite.

Ist das eventuell ein Firewall- Problem?

Zitat von fds97AVVS

und schau ob da was rot ist.

Ja, ist.

Zitat

hlsjs: unrecoverable network fatal error.

und in der exceptions.txt steht folgendes:

Zitat

ERROR:root:Expecting value: line 1 column 1 (char 0)
Traceback (most recent call last):
File "/telerising/requests/models.py", line 960, in json
File "/telerising/simplejson/__init__.py", line 514, in loads
File "/telerising/simplejson/decoder.py", line 386, in decode
File "/telerising/simplejson/decoder.py", line 416, in raw_decode
simplejson.errors.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/telerising/app/routes/api.py", line 921, in html_list
File "/telerising/app/providers/yallo.py", line 356, in load_channel_list
File "/telerising/requests/models.py", line 968, in json
requests.exceptions.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

Alles anzeigen

Also scheint etwas mit dem Netzwerk in dem Container nicht zu stimmen. Doch ich denke, das ist hier wirklich fehl am Platz. Lass uns lieber im telerising Docker Strang weiter machen. Dort gehört es meiner Ansicht nach hin. Ich schreibe das da auch noch mal:

Beitrag

RE: [Docker] Telerising API

Hi

Irgendwas stimmt in der Tat mit dem Netzwerk nicht. Wenn ich mir das Ganze mit den Dev Tools (F12) anschaue, taucht dort ein fataler Fehler auf:

[…]

und in der exceptions.txt steht folgendes:

[…]

Aber wo ich da ansetzen kann, keine Ahnung. Als erstes werde ich es mal mit host für das VPN Network versuchen, da es schon als bridge läuft.

Lehmden1

21. August 2025 um 12:10

Danke.

Hi

Irgendwas stimmt in der Tat mit dem Netzwerk nicht. Wenn ich mir das Ganze mit den Dev Tools (F12) anschaue, taucht dort ein fataler Fehler auf:

Zitat

hlsjs: unrecoverable network fatal error.

und in der exceptions.txt steht folgendes:

Zitat

ERROR:root:Expecting value: line 1 column 1 (char 0)
Traceback (most recent call last):
File "/telerising/requests/models.py", line 960, in json
File "/telerising/simplejson/__init__.py", line 514, in loads
File "/telerising/simplejson/decoder.py", line 386, in decode
File "/telerising/simplejson/decoder.py", line 416, in raw_decode
simplejson.errors.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/telerising/app/routes/api.py", line 921, in html_list
File "/telerising/app/providers/yallo.py", line 356, in load_channel_list
File "/telerising/requests/models.py", line 968, in json
requests.exceptions.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

Alles anzeigen

Aber wo ich da ansetzen kann, keine Ahnung. Als erstes werde ich es mal mit host für das VPN Network versuchen, da es schon als bridge läuft.

Zitat von fds97AVVS

hast du die custom host setting angepasst oder nicht?

Hab ich, und damit kommt der Web Player erst gar nicht, sondern nur eine leere Seite auf der "Error" steht. Hatte ich aber schon mal geschrieben, da es sich offensichtlich nicht um ein generelles Telerising Problem, sondern um ein Problem des Telerising Docker Containers, so wie er bei mir eingerichtet ist, handelt. Deswegen geht es auch im Docker Beitrag weiter. Dachte ich zumindest...

Inzwischen habe ich das Windows Setup auf 0.14.8 aktualisiert und es funktioniert trotzdem noch. Liegt also sicher nicht an Telerising.

Hi.

Inzwischen habe ich das Windows Setup auf 0.14.8 aktualisiert und es funktioniert trotzdem noch. Liegt also sicher nicht an Telerising.

Hi.

Leider war es das noch nicht ganz. Wenn ich wirklich versuche, im Web Player einen Sender über Telerising anzuschauen, bekomme ich nur eine Fehlermeldung mit TimeOut. Ich hatte erst die Vermutung, das der VPN vielleicht geblockt wurde, aber auf dem "alten" System (das ich eigentlich durch das Docker System ersetzen wollte) unter Windows 11 mit demselben VPN, allerdings eine Telerising Version älter (0.14.7 statt wie im Docker 0.14.8) funktioniert alles einwandfrei. Es kann also nicht am VPN selbst liegen. Der Zugang des Containers läuft über den VPN, sonst wäre ja nicht alles "Grün" im Web GUI.

Aber beim Abspielen kommt nur eine Fehlermeldung:

Den Proxy habe ich deaktiviert, ändert nichts. Wenn ich unter "Custom IP address / domain path" etwas eingebe, da in der Playlist eine IP mit 172.xxx auftaucht und hier die tatsächliche IP des Systems verwende, erscheint der Web Player erst gar nicht. Da steht dann nur "Error". Dasselbe ist auch, wenn ich , zumindest bei Yallo, auf DASH wechsele.

Beide Fehlermeldungen hängen mit Verbindungsproblemen zusammen. Also dürfte irgendwas in meinem Container. Aufbau noch nicht stimmen. Generell funktioniert das Ganze eben, nur nicht im Docker.

Als erstes werde ich mal auf dem Windows System die telerising Version aktualisieren (ohne dabei die "alte", sicher lauffähige zu löschen, um auszuschließen, das es sich um ein Problem der neuesten Telerising Version handelt. Und dann muss ich mich durch die Untiefen des Docker Aufbaus jonglieren, um vielleicht den Fehler zu finden. Dabei ist mir jede Hilfe willkommen.

Zitat von putzipuh

freili kann die IP vom VPN gebannt sein.

Hi.

Ist er ganz sicher nicht. Ich habe noch mein "altes" Setup unter Windows 11 zur Verfügung, was ich eigentlich ablösen wollte. Derselbe VPN mit demselben (weil einzigen) Schweizer Server und telerising, aber eine Nummer älter (0.14.7) funktioniert problemlos.

Es dürfte also am "neuen" Setup liegen und nicht an telerising selbst. Es sei denn, da gibt es ein Problem in der neuesten Version. Deswegen frage ich im Docker Strang weiter nach. Zum Glück läuft das "Alte" noch, so das ich keine Eile habe und das Problem in Ruhe angehen kann. Dennoch danke für die Hilfe.