Beiträge von dlueth

Starfoxfs und talentfrei GitHub baut gerade nochmal die 0.11. - allerdings muss ich zugeben keinen wirklichen Grund gefunden zu haben für den Fehler mit libz. Da es aber seit dem letzten Release eine neue minor von Nuitka (1.9.x) gegeben hat (was aus dem python Code ein Binary macht) wo im Changelog explizit libz erwähnt wirdhabe ich jetzt mal einfach eine 1.8er Version davon forciert. Ich checke auch nochmal bei mir, wenn der Build durch ist...

talentfrei Nein, hab ich nicht. Aber damit ich lokal bauen kann muss ich leider auch pushen in den Docker-Hub, das ist aktuell auch das "latest" und die darunter auftauchen 0.11.3 (aber ist nicht wirklich 0.11.3, funktioniert allerdings nicht). 0.11.6 konnte zwar gebaut werden, läuft aber aktuell noch nicht. Bin dran, aber es weigert sich hartnäckig...

Die letzte funktionierende Version ist die 0.11.5 aktuell

Achtung: die Version 0.11.6 startet nicht, es tritt folgender Fehler auf

ImportError: libz.so.1: cannot open shared object file: No such file or directory
Traceback (most recent call last):
  File "//telerising.py", line 1, in <module>
  File "//app/main.py", line 1, in <module app.main>
  File "//flask/__init__.py", line 5, in <module flask>
  File "//flask/json/__init__.py", line 6, in <module flask.json>
  File "//flask/globals.py", line 6, in <module flask.globals>
  File "//werkzeug/__init__.py", line 5, in <module werkzeug>
  File "//werkzeug/serving.py", line 27, in <module werkzeug.serving>
  File "//http/server.py", line 92, in <module>
  File "//email/utils.py", line 40, in <module>
  File "//email/charset.py", line 14, in <module>
  File "//email/base64mime.py", line 37, in <module>
  File "//base64.py", line 11, in <module>

easy4me Hast Du evtl. eine Idee? Ich vermute die libz.so.1 ist irgendwie neu als dependency hinzugekommen - aber warum?

Ich schau es mir an so schnell es geht...

0.11.6 wurde automatisch gebaut

Zitat von Starfoxfs

Jep war auch mein Eindruck bei Mpeg-DASH und vor allem ist das Zwischenspeichern unter Kodi dadurch besser geworden bzw. nicht mehr vorhanden.

Das könnte ja aber eigentlich wirklich nur dann sein, wenn es unterschiedliche quellstreams wären, oder?

Bei Zattoo (de) geht bei mir sowohl hls als auch Dash problemlos. Sind das dann eigentlich unterschiedliche quellstreams bei Zattoo? Hintergrund der Frage: ich habe das Gefühl die Bildqualität ist bei Dash etwas besser bzw es wirkt schärfer...

OK, danke!

Auf die Gefahr hin, dass mich jemand steinigt: Ich hab die letzten Wochen irgendwie nicht mitgelesen... Wo kommt denn jetzt Dash her und welches Problem löst bzw. welche Vorteile bietet es?

Hm, also bin ich nicht auf resolved, es geht aber trotzdem im Bridge-Mode?

COMMAND      PID            USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
systemd-r 207095 systemd-resolve   13u  IPv4 889715      0t0  UDP localhost:domain 
systemd-r 207095 systemd-resolve   14u  IPv4 889716      0t0  TCP localhost:domain (LISTEN)

bond0 hat bei mir ne fixe IP über die alle clients mit der Kiste reden.

Wie kann ich checken ob ich auf resolved umgestellt habe?

Zitat von sergio_eristoff

Zum Nachstellen, über DHCP muss alles konfiguriert sein über Netplan. Ich weiß eine statische IP wäre hier besser, jedoch ist das leider notwendig bei dem Server.

Also, mein Host ist tatsächlich ein Ubuntu 22.04.3 LTS, ebenfalls mit netplan inkl. DHCP und bei mir läuft der Docker auch im Bridge-Modus. Netplan-config sieht folgendermaßen aus:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      match:
        macaddress: 00:0d:b9:4e:76:88
      dhcp4: yes
      dhcp6: no
    enp2s0:
      match:
        macaddress: 00:0d:b9:4e:76:89
      dhcp4: no
      dhcp6: no
    enp3s0:
      match:
        macaddress: 00:0d:b9:4e:76:8a
      dhcp4: no
      dhcp6: no
  bonds:
    bond0:
      interfaces:
        - enp2s0
        - enp3s0

sergio_eristoff hm, mein Host ist allerdings auch ein Ubuntu, ich meine auch 22. Ich schau morgen Mal

Zitat von sergio_eristoff

Ok ich denke ich hab die Lösung.

Ich habe hier im Einsatz den Docker Container von dlueth . Dieser ist Defaultmäßig auf Bridge Mode gestellt, heißt Ports werden weitergereicht und gut ists. Tja Docker macht sich ja ein eigenes Ethernet-Interface mit eigenen DNS unter Ubuntu. Da Ubuntu, cool sein will und das Verhalten geändert hat, zieht er über DHCP den falschen DNS.

Daher hat das Docker Interface einen DNS der nicht passt.

Wie ich dann nun eingestellt habe, auf Host und den Hostnamen noch entfernt, meckert auch das TVH nicht mehr und bekommt sauber die Daten.

Die Weisheit dahinter ist, ich werde nicht so schnell Ubuntu Freund mit den neuen Netzwerkspielzeug

Welche Ubuntu Version hast Du denn als Host und was war die Lösung? Weil, die Problematik liegt ja eher da als bei docker, oder?

Zitat von sergio_eristoff

Brauchen nicht, jedoch ist es ein Feature von Telerising.

In der m3u sind ffmpeg links drin, weder telerising noch der docker brauchen es daher. Das Zielsystem braucht es aber.

Wegen 0.11.3: warte das nächste build ab, dann sollte es gehen

Build bei github läuft gerade, und schonmal länger als gestern. In 3-4 Stunden werden wir sehen ob's geklappt hat.

Build bei github läuft gerade, und schonmal länger als gestern. In 3-4 Stunden werden wir sehen ob's geklappt hat.

Bin noch dran, manuelle builds gestern failten aber noch. Es scheint nur die ARM-builds zu betreffen wo das bauen von cffi via pip nicht klappt, weil ffi.h nicht gefunden wird.

Warum sollte denn ffmpeg enthalten sein? telerising braucht kein ffmpeg

Was was den Pull von 0.11.3 angeht: Eigentlich macht der Build nur dann etwas auf dem Docker Hub, wenn der Build geklappt hat. Das scheint hier irgendwie anders zu sein, trotz gefailtem build. Der Build für amd64 lief übrigens sauber durch - und eben dieser ist auch im Docker Hub. Die Arm Builds failen.

Bin noch am schauen woran es genau liegt.

Aktuell failen die Builds von 0.11.3 aus irgendwelchen Gründen - bin dran

Ich meinte mehr an den generellen Dependencies in Sachen Python