Das mit den beiden Api's ist mir bewusst.
Möchte aber vermeiden, dass ich zwei Instanzen gleichzeitig pflegen muss.
Mein Internet ist an der Stelle nicht das schnellste und mir reicht beim Kodi-Client 1 Tag locker aus.
Zudem ist der Kodi-Startup deutlich schneller als wenn 14 Tage verarbeitet werden müssen.
Für meinen zweiten Anwendungsfall hätte ich allerdings gerne Zugriff auf das EPG von 14 Tagen.
Daher die Frage.
Ich würde gerne 2x täglich grabben, z. B. 1x in der Früh das EPG für 14 Tage und einmal Abends für 1 Tag (falls es kurzfristige Programmänderungen gab).
Gibts dazu irgendwie eine Möglichkeit über einen Terminal-Befehl an die Api, der den Grab-Vorgang dann für 14 Tage bzw. nur für 1 Tag startet?
Mein Fehler. Ich hatte nicht latest sondern beta im Einsatz.
Sorry für die Verwirrung. Habe in den letzten Tagen die Api standalone auf einem anderen Server installiert und meinen Docker-Server aufgeräumt.
Habe soeben in meinen Backups nachgesehen, welches Image ich hinterlegt hatte > qoopido/easyepg.minimal:beta
Mit dem latest-Tag.
Allerdings weiß ich nicht mehr genau, von wann das Image war. Du baust ja täglich neu, habe aber nicht jedes mal neu gepullt.
Übersehe ich etwas oder gibt's für den Sender 7+ kein Epg?
Jab - meine Vermutung hat sich bestätigt. Mit Container von @DeBaschdi läufts. Mit Container von @dlueth kommt die Meldung trotz update = yes und Info im Log, dass Branch up to date ist.
@easy4me Dein Script läuft.
@Boogie2005
Verwendest du evtl den Container von @dlueth?
In der grabber_error_log.txt steht nur folgendes:
--- ERROR LOG: 2023-01-05 11:52:19 ---
Traceback (most recent call last):
File "/easyepg/resources/lib/epg.py", line 196, in grabber_process
if data.get("errorCode"):
AttributeError: 'list' object has no attribute 'get'
--- ERROR LOG END ---
Ich poste das [definition='1','0']log[/definition] sobald ich am PC bin.
@Boogie2005
Bei mir auch. Ich poste später das [definition='1','0']log[/definition] file.
Habe gleiche Erfahrungen gemacht.
Problem an der Sache ist auch, dass z. B. mein Philips 4K TV nativ mit 1080p60 auflöst (und das wohl auch so ziemlich alle anderen AndroidTV-Geräte).
Optionen zur Änderung der Bildfrequenz gibts nicht. Auch bietet Android TV nativ in den vorliegenden Android-Versionen wohl keine Schnittstelle für Frame-Rate-Matching. Das kommt erst ab Android 12 oder 13.
Interessant ist auch:
Die M3U IPTV App von @M3U IPTV hat in den ersten Versionen ein Vollbild erzeugt aber entsprechend rucklig durch die nativen 60fps im AndroidTV.
In späteren Versionen hat sich etwas am Codec oder ähnlichem geändert. Seitdem läuft zwar die Wiedergabe smooth, allerdings habe ich kein Vollbild mehr. Erst nach kurzem switch in den PIP-Modus und wieder zurück in die App erzeugt Vollbild. Ähnliches zeigt sich auch mit Youtube-App. Android TV ist nativ also mehr oder weniger brauchbar.
Nutze aktuell den Android TV nativ und hab meinen FireTV Cube abgebaut, da komischerweise meine jetzige TV-FIrmware aus 2021 trotz 60fps nahezu (99%) flüssiges Bild liefert i. V. m. Kodi.
Hatte vor einiger Zeit mal ein Upgrade auf die neuere Firmware gemacht und da hat sich einiges scheinbar geändert und hatte dann nur noch rucklen.
Hab dann versucht über Umwege wieder zurück auf die alte FIrmware zu kommen - Ergebnis: Brick... Hab ziemlich geschwitzt. Der TV war wenige Wochen alt und war ziemlich teuer. Habs dann aber nach einigen Stunden wieder hinbekommen. Seitdem in der Fritzbox die Update-URLs geblockt und kein Upgrade mehr laufen lassen. Trau mich nicht mehr 
Würde eigentlich gerne den Cube gegen einen 4k Stick tauschen. Allerdings gefällt mir der Amazon-Launcher nicht und 3rd Party Launcher lässt Amazon in neueren Firmwares nicht mehr zu.
Also irgendwie alles nicht das gelbe vom Ei.... Leider.
Um mal zum eigentlichen Thread zurückzukommen. 
Könnte man ggf neben hls auch dash als Auswahl in die api einbauen?
Vllt jemand einen tipp wo ich eine saubere apk herbekomme?
Apkp. Und die Homepage gehen irgendwie nicht
Auf der Homepage gibts ja extra ein firetv ordner
@Adromir
Hatte ich auch. Lag letztlich an einer "falschen" installation. Evtl war auch bei dir im Ordner schon easyepg vorhanden und du hast im docker den Ordner dann als volume eingebunden. Dann passiert exakt das, was du beschrieben hast.
Und hier noch die Beschreibung der Ursache bei mir:
[docker] NEW easyepg
Stand jetzt sehe ich nur Docker als Alternative.
Damit wäre es isoliert vom Betriebssystem.
@easy4me
Es gibt mittlerweile die Server "zh2-10" bis "zh2-17" im Portfolio.
Vielleicht könnte man diese in einer der nächsten Versionen berücksichtigen
@dlueth
Danke für das Docker-Image Ich habe es soeben mal installiert und läuft. Sogar meinen Healthcheck konnte ich auf wget umbiegen (normalerweise nutze ich curl ^^)
Eine Frage.
Im Log steht bei mir "WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead."
Kann man ignorieren, oder?
@toab90 ich muss mir das in Ruhe anschauen, aber was mich irritiert ist, dass normalerweise /proc/**/* immer auf der Rootebene liegt, also nicht in einem Unterordner. Bist Du sicher, dass da nichts mit der Volume-Angabe schief gelaufen ist?
Konnte das Verhalten nachstellen. Hatte damals übersehen, dass sich die ENV REPO zwischen deinem und dem Container von DeBaschdi unterscheidet.
Hatte daher ursprünglich REPO=script.service.easyepg-lite i. V. m. deinem Image angegeben. In diesem Falle extrahiert sich scheinbar der ganze Container und die Dateien bleiben solange bestehen, bis man den ganzen Container löscht und unter Angabe der richtigen REPO neu erstellen lässt. Korrigiert man nur den REPO-Parameter, bleiben die Daten auf dem Server vorhanden.
Ja das hat mich auch gewundert.
Ich werde morgen den Container nochmal neu aufzusetzen und dann nochmal berichten
Vielleicht kann man ja irgendwie verhindern, dass diese Daten in den Ordner "EASYEPG_STORAGE" geschrieben werden?
"Gepackt" im Docker-Image ist sie ja nur einen Bruchteil so groß.
Die lag im "EASYEPG_STORAGE" unter \proc\1\task\1\
