Test OpenHDF 7.5

    • antrabe schrieb:

      antrabe schrieb:

      Bei manchen Skins stürzt das Bild ab, sobald das Softcam-Panel ausgewählt wird. Beim Fury-Skin funktioniert beispielsweise alles einwandfrei. Weiß jemand, woran das liegen könnte?
      Es erscheint folgende Fehlermeldung: extension/HDF-toolbox ( kein Modul namens „tools.hex2strcolor“ gefunden
      Die Datei haben wir nicht im Repo, ist aber bei z.Bsp OpenPli da.. muss ich mal schauen.
      Aber viel interessanter als "Es funktioniert bei dem", wäre die Frage "Bei welchem denn nicht?"

      Generell (an alle) wenn was nicht funktioniert, dann gerne reporten (macht ihr ja), aber eben auch ein paar nützliche Informationen mitgeben ;)
      Wir können leider nicht jedes Szenario testen.

      (Zumindest setze ich mich nicht hin und teste Skins oder Plugins durch - ich hab auch noch ein Leben und so..)
      MfG henrylicious
      Ich gebe keine Auskünfte über PN, alle Fragen sollen bitte im Forum gestellt werden!!
    • Habe gerade nochmal getestet ob sich bei der Aufnahme von IPTV-Programmen nach dem Update auf #72 etwas geändert hat. Hier das Resultat :
      • Vavoo aus erstellter Playlist lässt sich aufnehmen und mit Billd und Ton wiedegeben.
      • Telerising lässt sich aufnehmen. Beim Versuch dei Aufnahme abzuspielen kommt die Fehlermeldung, daß die Datei nicht gefunden wurde und die Box crasht. Enigma startet dann automatisch neu. Beim 2. Versuch lässt sich die Aufnahme dann abspielen,allerdings nur ohne Ton.


      Crash Log hier:

      Sonst beim Online Update keine Auffälligkeiten Läuft auch sonst alles ohne Probleme.
    • Hallo,
      ich beobachte ein merkwürdiges Phänomen im Zusammenhang mit Oscam Seit einiger Zeit fällt mir auf, dass ich Aussetzer/Hänger beim Anschauen von HD+ Programmen auf meine Box im WZ (Gigablue Quad 4k pro) habe.
      Die Box greift per Oscam auf die Box im Schlafzimmer, in der sich die HD+-01 Karte befindet zu.

      In dieser Client-Oscam gibt es nur einen remote reader:

      [reader]
      label = remote
      protocol = cs357x
      device = xxx.xxx.xxx.xxx,12600
      user = ****
      password = ****
      group = 1,2,3,4,5

      Ich habe das jetzt mal am Wochenende etwas näher untersucht, da ich erst an eventuelle Netzwerkprobleme etc. dachte.
      Hat aber mit dem Netzwerk absolut nicht zu tun. Das ist 100% stabil, beide Boxen arbeiten per Ethernet-Kabel mit 1000 MBit/s, und alle anderen Netzwerktätigkeiten (Updates, Zugriff auf NAS oder andere Boxen) funktionieren tatellos.
      Das Problem tritt mit Oscam, Oscam-smod. Oscam-icam (immer mit gleicher Konfiguration alle paar Minuten auf) Es gibt dann offensichtlich timeouts, ansonsten werden die ecm immer mit 300-310 ms beantwortet. Das Verhalten ist mit HDF 7.5 #68,#70 und#72 identisch.

      Und jetzt kommt das Auffällige:

      Verwende ich auf der box im WZ (Client) oscam-csa (mit identischer Konfiguration) ist alles wunderbar stabil, wie zuvor jahrelang auch.
      Deswegen vermute ich, dass es vielleicht mit der Änderung für oscam-csa im Image zussammenhängt.

      Natürlich kann ich damit leben jetzt Oscam-csa zu nutzen. komisch ist das aber trotzdem. Leider habe ich kein älteres HDF 7.5 mehr auf der Box, eventuell flashe ich nochmal eine alte Version vor der Einführung vpn Oscam-csa um das damit nochmal zu testen.

      Hatt jemand ähnliches beobachtet oder noch Ideen dazu?
      Gigablue UHD QUAD 4K Pro, Gigablue UHD UE 4K, 3 x Octagon SF8008 4K, Zgemma H9 Combo
    • Ähnliches Setup bei mir
      Server openHDF 7.5.68
      Client openHDF 7.5.67

      Keine Probleme.
      _________________________________________________________________
      GB ue 4k mit ST3000LM024-2AN1 und Synology über Denon X1700H an LG OLED OLED65C17LB
      AX 4K HD51 mit Synology an OLED55C8LLA
      Anadol Multibox SE an Samsung c
      ET10000 an Pioneer PDP-436RXE
      Unicable mit IG-IDLU-UST110-CUO4O-32P
    • Gibt es eine Möglichkeit bei meinen Receivern farbige Untertitel angezeigt zu bekommen , so wie das mit VLC Player unter Windows & Android möglich ist ?



      Wiedergabe mit EMC = Untertitel immer nur einfarbig

      kein Support per PN (Fragen bitte ins Forum)
      Und keine Hilfe von mir zu HDF-Versionen : 7.4 / 7.3 /6.5 und älter !
    • antrabe schrieb:

      henrylicious schrieb:

      antrabe schrieb:

      Here is the log failure with fury skin.
      Wo hast du den Skin denn her?Find da nix auf dem Feed
      Es ist nicht im Feed enthalten, daher hier der Link zur Installation via Telnet. Es stammt von Meister Islam Salama.wget -q "--no-check-certificate" raw.githubusercontent.com/isla…ds/main/fury/installer.sh -O - | /bin/sh
      Aber du hattest schon gelesen, dass OpenHDF da nicht als supported gelisted war, oder?
      zum Beispiel hier
      MfG henrylicious
      Ich gebe keine Auskünfte über PN, alle Fragen sollen bitte im Forum gestellt werden!!
    • henrylicious schrieb:

      Ähnlich bei mir, nur ich ab ne 02
      Quad4k mit HD02 im Wohnzimmer
      Quad4kpro bekommt vom Wohnzimmer.

      Hast du auch die prio in der oscam.dvbapi auf die CAID der 01 eingestellt? (glaub 1830)
      Die Prio war zwar nicht gesetzt, das hat aber auch nichts geändert, da die 1830 sowieso die einzige CAID ist für die ein Reader vorhanden ist. Ich hatte den Fehler gestern jetzt auch mit oscam-csa auf dem Client.
      Es ist also egal, welche oscam Variante, da lag ich mit meiner Vermutung falsch. Bei Hängern hatte ich auf derr Client Seite im Log immer Fehlermeldungen sinngemäß "CAID 1830.... - no matching Reader found", was ja tatsächlich nicht stimmt und nach ca. 30-60 Sekunden geht es dann ja auch wieder weiter.
      Ich habe dann nochmal komplett neue oscam-csa Settings heruntergeladen und angepasst. Danach lief dann auch erstmal stabil, es war allerdings schon spät und kein besonders langer Test mehr. Mal schauen, wie es sich heute verhält. So richtige Unterschiede habe ich da aber nicht gefunden, außer dass ich bisher keine oscam.services Datei hatte.
      Gigablue UHD QUAD 4K Pro, Gigablue UHD UE 4K, 3 x Octagon SF8008 4K, Zgemma H9 Combo
    • Neu

      siggi_r schrieb:

      Falsches Keymapping in OpenWebif-main/plugin/controllers/views/main.tmpl

      Wie in meinen anderen Beitrag unter
      vollständige Fernbedienung in openwebif startet mit "timer" timeshift anstatt die anzeige der programierten timer

      beschrieben (wurde nach "Allgemeines zum OpenHDF image" verschoben) habe ich nun weitere Erkenntnisse, welche auf einen leicht korrigierbaren Fehler hinweisen


      Ein Key remapping via RED key funktioniert leider nicht korrekt.
      Denn es wird immer auch noch zusätzlich time_shift gestartet.

      Mit debug-log habe ich dann mit original fernbedienung herausgefunden, daß der Key für den timer Eintrag
      362 sein muß, anstatt der 359 wie es die vollständige Fernbedienung im OpenWebIf sendet.

      Habe ein bisschen unter github in der source gestöbert dabei bin ich auf folgendes gestoßen

      in enigma2/keyids.py steht
      "KEY_TIME": 359,"

      schaue ich mir im firefox den Seitenquelltext an dann sehe ich daß bei Timer der datacode 359 ist
      <table class="remotesmall" style="height:20px;">
      <tr>
      <td data-code="141" class="tdf"><button class="_12">Setup</button></td>
      <td data-code="156" class="tdf"><button class="_11">Portal</button></td>
      <td data-code="142" class="tdf"><button class="_12">Sleep</button></td>
      <td data-code="359" class="tdf"><button class="_12">Timer</button></td>
      <tr>
      </table>

      was mit meiner Beobachtung übereinstimmt.

      Dieser sollte aber ein KEY_PROGRAM also 362 lauten wie in enigma2/keyids.py
      "KEY_PROGRAM": 362"
      eingetragen ist.

      Wenn ich noch ein wenig weiterforsche dann finde ich daß dieser Fehler schon im File
      OpenWebif-main/plugin/controllers/views/main.tmpl

      <table class="remotesmall" style="height:20px;">
      <tr>
      <td data-code="141" class="tdf"><button class="_12">Setup</button></td>
      <td data-code="156" class="tdf"><button class="_11">Portal</button></td>
      <td data-code="142" class="tdf"><button class="_12">Sleep</button></td>
      <td data-code="359" class="tdf"><button class="_12">Timer</button></td>
      <tr>
      </table>

      beinhaltet ist.

      Wie ich das sehe könnte man das also ganz easy korrigieren.
      @zeini : könntest Du das veranlassen ?
      OpenHDF 7.5.67 (2026-02-28)
      Nachdem im github keinerlei reaktion auf meinen gemeldeten Bug erfolgte, habe ich nun ein bisschen weitergeforscht.

      Wenn also jemand dieses Verhalten im 7.5 release auf einer gbquad4k und vielleicht auch auf anderen gigablue boxen stört, der kann das file
      /usr/lib/enigma2/python/Plugins/Extensions/OpenWebif/controllers/views/main.pyc
      patchen.
      Am besten legt man eine Kopie an z. Bsp. main.backup
      Man sucht mit binäreditor oder unter windows mit notepad++ nach
      <td data-code="362"
      Man sollte dann folgende Zeile finden
      <td data-code="359" class="tdf"><button class="_12">Timer</button></td>
      man ersetzt die 359 durch 362
      und voila beim nächsten start des Openwebif funktioniert der Aufruf der timer in der vollständigen Fernbedienung wie erwartet.
      GigaBlue UHD QUAD 4K
      OpenHDF 7.5.67 (2026-02-28)
      Tuner A-H = 8 * DVB-S2X NIM(45308X FBC) (DVB-S2X)
      Tuner I - J = 2 * GIGA DVB-T2/C NIM (TT3L10) (DVB-T2)
      Disk = 4TB

    Flag Counter