FHEM Forum

FHEM - Anwendungen => Multimedia => Thema gestartet von: Beta-User am 25 September 2021, 20:48:56

Titel: [reloaded] TvHeadend-Modul
Beitrag von: Beta-User am 25 September 2021, 20:48:56
Hallo zusammen,

unter Codeschnipsel hatte @Quantum mal einen ersten Entwurf für ein Tvheadend-Modul veröffentlicht, das dann aber anscheinend nicht mehr weiterverfolgt. Bin irgendwie neulich mal da drüber gestolpert, und dachte, TvHeadend - das habe ich doch auch, mal sehen, was man damit anstellen kann....?

Hier mal seine Ankündigung - das paßt erst mal auf "meine" Version:
Hallo FHEM-Gemeinde,

schon seit Jahren verwendet ich als TV den Tvheadend Server in Verbindung mit Kodi -> https://github.com/tvheadend/tvheadend (https://github.com/tvheadend/tvheadend)
Tvheadend bietet eine wenig bekannte und eher mager dokumentierte JSON Schnittstelle, über die so ziemlich alles manipuliert werden kann.
Das habe ich zum Anlass genommen hierfür ein Modul zu schreiben, das ich nun als ersten Wurf veröffentliche.

Siehe hierzu: [alter link] und die commandref.

Was kann das Modul zu diesem Zeitpunkt ?

Intelligente Abfrage des EPGs. Was läuft gerade und als nächstes im TV?. Hierfür werden verschiedene readings angelegt. Titel,Beschreibung,Sendername,Start,Stop ...
Erneute Abfrage des EPG bei Ende einer Sendung.

Abfragen des EPGs mithilfe einer get Methode.

Anlegen eines DVR(Digital Video Recorder) Eintrags mithilfe einer EventId.

Mögliches Anwendungszenario: Abfrage von EPG Informationen aus der Ferne mithilfe eines Endgeräts bspw. Smartphone (Messenger), Email etc..
Daraufhin setzen enes DVR Eintrags mithilfe dieser Information aus der Ferne. Ohne zuhause zu sein, bzw. Kodi starten zu müssen.

Frühe Entwicklerversion. Fehlverhalten nicht ausgeschlossen !

Freundliche Grüße
Quantum

Es gab ein paar (m.E. teils sehr berechtigte) Anmerkungen von CoolTux zum Coding, daher habe ich das jetzt erst mal in der Funktionalität mehr oder weniger nur 1:1 versucht, auf "json_de/encode"-sichere Mechanismen und auf package umzustellen.

Weitere Änderungen:
- das UTF-8-encoding schien gelegentlich "kaputt" zu sein - teilweise ist es repariert
- User/Passwort kann zwar noch über die DEF eingegeben werden, gespeichert wird dann aber in Attribut bzw. im "Passwortspeicher", dazu gäbe es dann auch neue Setter
- Der Modulname ist jetzt TvHeadend (mit großem "H"). So kann man auch beide Fassungen parallel verwenden;
- intern ist auch sonst einiges umgestellt.

Diese Version hier kann also (hoffentlich) in Ergebnis noch dasselbe wie die letzte Fassung von Quantum, intensiv getestet habe ich aber auch noch nicht ::) , und eine "größere Idee", warum man sowas überhaupt braucht, ebenfalls nicht...

Bin daher mal auf mutige Tester gespannt - mal schauen, was am Ende daraus wird.

Vieles am Code ist mir auch noch unklar und kann ggf. noch verbessert werden.

Viel Spaß beim Testen,

Beta-User

EDIT: Update vom 11.10.2021 - die gesamt-Channel-Liste wird nicht mehr als userAttr bereitgestellt, sondern per Instanz.
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: alanblack am 07 Oktober 2021, 20:28:01
Hi, ich habe es mal runtergeladen,

Hier mal seine Ankündigung - das paßt erst mal auf "meine" Version:

Auf jeden Fall mal: Danke für die Arbeit!
aber da passt noch nicht alles:
Internals:
   CFGFN     
   DEF        baseUrl=<IP>
   EPGQuery_state 0
   FUUID      <ID>
   NAME       TVHeadendServer
   NR         52646
   STATE      ???
   TYPE       TvHeadend
   READINGS:
   helper:
     epg:
       count      43
       update     1633630260
       channels:
         HASH(0x660acc8)
         HASH(0x61bc4b8)
         HASH(0x5af7478)
         HASH(0x6588b28)
         HASH(0x646feb0)
         HASH(0x660a9f8)
         HASH(0x6410280)
         HASH(0x62ccc88)
         HASH(0x6022e78)
         HASH(0x669b4c8)
         HASH(0x61b1c78)
         HASH(0x57f2318)
         HASH(0x66a1c28)
         HASH(0x66db5e0)
         HASH(0x5da5a58)
         HASH(0x643a290)
         HASH(0x647dfd8)
         HASH(0x5ae6d10)
         HASH(0x66da200)
         HASH(0x5db8530)
         HASH(0x58809d8)
         HASH(0x642f2e0)
         HASH(0x62339f8)
         HASH(0x5ea4668)
         HASH(0x633d728)
         HASH(0x5e3f620)
         HASH(0x60eb6f8)
         HASH(0x5a6b898)
         HASH(0x635caa8)
         HASH(0x6471058)
         HASH(0x61b2898)
         HASH(0x647d9d8)
         HASH(0x5cd8310)
         HASH(0x5ed1600)
         HASH(0x57dbd30)
         HASH(0x62ef3a0)
         HASH(0x5d9d7f0)
         HASH(0x66ea040)
         HASH(0x65cfb40)
         HASH(0x6380410)
         HASH(0x64aedf8)
         HASH(0x65f7a38)
         HASH(0x5f12b90)
         HASH(0x66d5e48)
         HASH(0x5d8ef28)
         HASH(0x60d2be8)
         HASH(0x58056a0)
         HASH(0x5a66100)
         HASH(0x5f125f0)
         HASH(0x667f990)
       next:
         HASH(0x5dc8718)
         HASH(0x641f628)
         HASH(0x66919b8)
         HASH(0x6233788)
         HASH(0x652e148)
         HASH(0x66c6308)
         HASH(0x431b948)
         HASH(0x5a46940)
         HASH(0x64eb3f0)
         HASH(0x6329500)
         HASH(0x5fc29f8)
         HASH(0x3d179c0)
         HASH(0x595a688)
         HASH(0x637fac8)
         HASH(0x61da740)
         HASH(0x64388d8)
         HASH(0x64c2fe0)
         HASH(0x630cb48)
         HASH(0x6306dd8)
         HASH(0x6370118)
         HASH(0x5aefc98)
         HASH(0x57d7120)
         HASH(0x6588138)
         HASH(0x5ae7f98)
         HASH(0x66d2770)
         HASH(0x57ce170)
         HASH(0x5de03f8)
         HASH(0x6403848)
         HASH(0x64ea140)
         HASH(0x5d19100)
         HASH(0x6517f68)
         HASH(0x6563e28)
         HASH(0x62e20f0)
         HASH(0x668f120)
         HASH(0x6112d78)
         HASH(0x66cb4d0)
         HASH(0x61f3920)
         HASH(0x58b8348)
         HASH(0x5da5d40)
         HASH(0x58ceaa8)
         HASH(0x6381e60)
         HASH(0x6568c08)
         HASH(0x67200a0)
       now:
         HASH(0x5a75cf0)
         HASH(0x60ebdd0)
         HASH(0x6381208)
         HASH(0x6022ab8)
         HASH(0x64adb88)
         HASH(0x6347210)
         HASH(0x63a4220)
         HASH(0x66a9790)
         HASH(0x5814b70)
         HASH(0x5d9cf38)
         HASH(0x63a1fe8)
         HASH(0x665b990)
         HASH(0x57d4a88)
         HASH(0x5ed3ec8)
         HASH(0x6415af0)
         HASH(0x5db29c8)
         HASH(0x5c4f900)
         HASH(0x66800f8)
         HASH(0x665d558)
         HASH(0x5d9ed48)
         HASH(0x67af710)
         HASH(0x632b408)
         HASH(0x6391958)
         HASH(0x5dab630)
         HASH(0x65c2078)
         HASH(0x5f876f8)
         HASH(0x6347ac8)
         HASH(0x6505168)
         HASH(0x64764f0)
         HASH(0x6029548)
         HASH(0x5ea04f8)
         HASH(0x61e3118)
         HASH(0x64f97f0)
         HASH(0x5d9ece8)
         HASH(0x6680158)
         HASH(0x662b460)
         HASH(0x6475b60)
         HASH(0x6692c20)
         HASH(0x612c518)
         HASH(0x60c2388)
         HASH(0x6678b80)
         HASH(0x62cd210)
         HASH(0x64150a8)
     http:
       id         11
       ip         <IP>
       port       9981
       url        <url>
Attributes:
   Username   <user>
   userattr   EPGChannelList:multiple-strict,all,R[...]

Die Attribute werden nicht korrekt aufgebaut. Ich habe zwar kurz in den Code geschaut, aber noch nicht den Grund gesehen.

Zitat
[...], und eine "größere Idee", warum man sowas überhaupt braucht, ebenfalls nicht...
Warum ich diesen Thread gefunden habe: ich habe mehrere DVB-Adapter an einem 1-Platinen-Computer hängen, von denen sich beliebige völlig unerwartet und scheinbar zufällig weghängen. Einen Grund habe ich auf OS- und Treiber-Ebene noch nicht gefunden, auch weil es schwierig ist, den Zeitpunkt halbwegs genau einzugrenzen. Daher war der Gedanke, dass ich über die JSON-Schnittstelle das mal genauer mitbekomme.

Zitat
Bin daher mal auf mutige Tester gespannt - mal schauen, was am Ende daraus wird.

"Hier!" (Tester++)

Grüße
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: MadMax-FHEM am 07 Oktober 2021, 20:34:50
Ich häng mich auch hier mal mit dran :)

Aktuell aber unterwegs, daher wird erst später getestet...

@alanblack: was für ein 1-Platinencomputer? USB zu "schwach"? Habe ich bei einem meiner PI auch. 2x USB-Adapter und USB-SSD und ab und an "verschwindet" einer... Hab da jetzt (aktuell) nur einen laufen...

An einem weiteren PI einen Dual-Stick und ebenfalls USB-SSD aber mit aktivem USB-Hub (zuvor ohne auch mit Problemen) keine Probleme...

Gruß, Joachim
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: alanblack am 07 Oktober 2021, 21:40:14
Hallo Joachim,

[Offtopic]
@alanblack: was für ein 1-Platinencomputer? USB zu "schwach"? Habe ich bei einem meiner PI auch. 2x USB-Adapter und USB-SSD und ab und an "verschwindet" einer... Hab da jetzt (aktuell) nur einen laufen...
Der Computer ist ein Odroid XU4. Daran hängen bis auf eine USB-HDD an zwei passiven USB-Hubs jeweils zwei USB-DVB-Adapter - aktuell jeder mit eigenem Netzteil. Das war mal aus Verbrauchsgründen anders, aber wegen der Probleme hatte ich schon alles mir erdenkliche getan, um derartige Ursachen auszuschließen.
Die Kombi so läuft auch mit bis zu vier Streams bei zwei mit Transcoding ohne Mucken. Nur mehr als ein SD- und ein HD-Stream im Timeshift bringen die HDD an die Grenzen - da müsste dann eine SSD hin.
Ein Problem unter Last habe ich nicht verzeichnen können - eher im Idle. Da ich dann aber i.d.R. nicht zuhause bin, bekomme ich aktuell den Ausfall nur mit, wenn ich über fehlgeschlagene Aufnahmen stolpere oder die Meldung "Kein freier Adapter verfügbar" mich anspringt.
[/Offtopic]

Die Stromversorgung wird aber sehr sicher nicht für das nicht korrekte Initialisieren der Attribute dieses Moduls verantwortlich sein.

Grüße
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: Beta-User am 07 Oktober 2021, 22:26:32
Leider fehlt mir noch eine Idee, was genau mit "Attribute werden nicht korrekt aufgebaut" gemeint ist - vermutlich fehlt mir der "vorher/nachher"-Aha-Effekt.

Das userattr EPGChannelList wird doch aufgebaut, oder deute ich das [...] falsch? Was  fehlt?
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: alanblack am 08 Oktober 2021, 19:00:43
Leider fehlt mir noch eine Idee, was genau mit "Attribute werden nicht korrekt aufgebaut" gemeint ist - vermutlich fehlt mir der "vorher/nachher"-Aha-Effekt.
[IronieAn]Das sieht man doch aus dem List.[IronieAus] :P

Zitat
Das userattr EPGChannelList wird doch aufgebaut, oder deute ich das [...] falsch? Was  fehlt?
Reicht nicht immer - also Screenshot anbei!
Die kommaseparierte Liste scheint an der falschen Stelle zu landen. Oder wenn das über das Attribut "userattr" gewollt ist, wäre das Leerzeichen statt Kommata als Trennzeichen erforderlich.

Grüße
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: Beta-User am 09 Oktober 2021, 13:40:22
Ironiefrei: Der Inhalt von userAttr sah für mich ok aus. Nach meinem bisherigen Verständnis ist es so, dass man erst das userAttr generieren muss, um dann in einem zweiten Schritt dann die EPGChannelList auswählen zu können.

Das Problem ist eher, dass die letztere dann verlustigt geht, wenn man danach dann set ... EPG ausführt. Da ich aber nicht weiß, wie das im Ausgangsmodul war, und wie das eigentlich alles gedacht war, ist es schwierig zu beurteilen, ob das nun eine Regression ist oder nicht. Aber dass ein set-Befehl ein Attribut löscht, ist eher nicht so intuitiv, sieht mir nach einem Bug aus, mal sehen....
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: alanblack am 10 Oktober 2021, 11:23:37
Nachtrag: ich hatte einmal das Device angelegt, mich gewundert und ein "get ChannelQuery" gemacht. Danach habe ich es gelöscht und noch einmal angelegt. Da war das userattr wie im Screenshot vorhanden.
Jetzt habe ich das Device mal unter einem anderen Namen angelegt:
Internals:
   CFGFN     
   DEF        baseUrl=<IP>
   FUUID      6162af46-f33f-c82a-5839-f5f1b47ef913240e
   NAME       TVHeadendServer_1
   NR         91069
   STATE      ???
   TYPE       TvHeadend
   helper:
     epg:
       count      0
     http:
       ip         <IP>
       port       9981
       url        <URL>
Attributes:
Jetzt weiß ich wieder, warum ich mich gewundert habe: das Device ist "leer".
Darf aber laut Code nicht sein, oder?
$hash->{AttrList} =
"HTTPTimeout " .
"EPGVisibleItems:multiple-strict,Title,Subtitle,Summary,Description,ChannelName,ChannelNumber,StartTime,StopTime " .
"PollingQueries:multiple-strict,ConnectionQuery " .
"PollingIntervall " .
"EPGChannelList:multiple-strict,all " .
          $readingFnAttributes;

Grüße
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: Beta-User am 11 Oktober 2021, 21:41:11
So, update ist im ersten Post. Damit wird EPGChannelList nicht mehr als userattr generiert, sondern entweder als echtes Attribut gelesen oder instanzspezifisch verwaltet.

Heißt aber noch lange nicht, dass das irgendwas bringen würde - im alten Thread war die Rede davon, dass das "unvollendet" sei... So auch hier :o ;D ...
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: alanblack am 13 Oktober 2021, 22:05:02
So, update ist im ersten Post. Damit wird EPGChannelList nicht mehr als userattr generiert, sondern entweder als echtes Attribut gelesen oder instanzspezifisch verwaltet.
Runtergeladen, "alte" Version komplett bereinigt, neue rein => funktioniert jetzt anscheinend stabil
Vielen Dank dafür!

Zitat
Heißt aber noch lange nicht, dass das irgendwas bringen würde - im alten Thread war die Rede davon, dass das "unvollendet" sei... So auch hier :o ;D ...
Ich habe inzwischen die API für die Input-Devices vom TVHeadend-Server gefunden. Ich schaue mal, was ich davon umsetzen kann.

Grüße
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: Beta-User am 13 Oktober 2021, 22:37:41
...einen habe ich noch gefunden: Die Attribute in .AttrList scheinen sich zu vervielfachen...

Fix (hoffentlich) - Zeile 511 so ändern:
my $devattrs = $defs{$name}{'.AttrList'} // getAllAttr($name);
Ich habe inzwischen die API für die Input-Devices vom TVHeadend-Server gefunden. Ich schaue mal, was ich davon umsetzen kann.
Bitte gib Bescheid, wenn du Hilfe brauchst.

Vielleicht noch was für den Hinterkopf: Wenn man einen nicht administrativen Nutzer hat, gibt es auch entsprechende Rückmeldungen, wenn man was versucht, was nicht erlaubt ist (war eine der Absturzursachen aus dem anderen Thread, weil dann kein JSON zurückkommt). Vielleicht muss/sollte man das irgendwo sichtbar machen, dass bzw. mit welchem Ergebnis das gecheckt wurde.
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: alanblack am 14 Oktober 2021, 19:54:20
...einen habe ich noch gefunden: Die Attribute in .AttrList scheinen sich zu vervielfachen...

Fix (hoffentlich) - Zeile 511 so ändern:
my $devattrs = $defs{$name}{'.AttrList'} // getAllAttr($name);
Bisher habe ich auch ohne diesen Fix keine Vervielfachung erkennen können. Ich habe ein Auge darauf.
Zitat
[Input-Devices]
Bitte gib Bescheid, wenn du Hilfe brauchst.
OK! Danke für das Angebot! Werde aber frühestens nächste Woche Zeit finden.
Zitat
Vielleicht noch was für den Hinterkopf: Wenn man einen nicht administrativen Nutzer hat, gibt es auch entsprechende Rückmeldungen, wenn man was versucht, was nicht erlaubt ist (war eine der Absturzursachen aus dem anderen Thread, weil dann kein JSON zurückkommt). Vielleicht muss/sollte man das irgendwo sichtbar machen, dass bzw. mit welchem Ergebnis das gecheckt wurde.
Wäre vielleicht etwas, das den STATE beeinflussen könnte, so in der Art: Server liefert reguläre Antworten => STATE = "connected" (oder so) - irgendein Input geht nicht => STATE = "warning" - User macht Unsinn => STATE = "alert". Auch nur für den Hinterkopf; eigentlich aber, weil mich die "? ? ?" im STATE irritieren. 

Grüße
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: Beta-User am 14 Oktober 2021, 20:51:58
Das mit "sehr vielen comment-Einträgen" ist bei mir halt vorgekommen, warum auch immer. Jetzt mit dem fix erst mal auch nicht mehr ;D .

Was STATE angeht => stateFormat würde helfen. Mit dem "verfrühten" Füllen des Readings "state" habe ich so meine Erfahrungen gemacht, seither reserviere ich das für den "Hauptschalter" ;D ...

Aber sowas wie ein "connection"-Reading würde Sinn machen, etwa in die Richtung: unreachable, unauthorized, ok, priviledged. Tendenziell würde man sowieso sowas wie eine "ping"-Routine brauchen (Rudi hat da was im Repertoire, man braucht kein qx...).

Das Logging von den nächsten Verbindungsversuchs-Zeiten auf Level 3 erscheint mir auch nicht optimal, sollte eigentlich auch eher ein Reading sein.

(Vielleicht bei Gelegenheit mal).
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: alanblack am 17 Oktober 2021, 16:24:25
[InputDevices]
Bitte gib Bescheid, wenn du Hilfe brauchst.
Die Abfrage habe ich eingebaut. Ich bin mir nicht klar, ob ich die Devices in Attribute, ein Internal (aktuell) oder Readings ablegen sollte. Die "activeInputDevices" habe ich auf jeden Fall als Reading angelegt. Nur hatte ich irgendetwas mit dem InternalTimer darauf falsch gemacht. Damit war FHEM eingefroren. Das ist hier komplett wieder draußen. Kannst Du mir da mal bitte zumindest einen Ansatz geben. Danke!

Grüße
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: CoolTux am 17 Oktober 2021, 16:35:45
Das mit "sehr vielen comment-Einträgen" ist bei mir halt vorgekommen, warum auch immer. Jetzt mit dem fix erst mal auch nicht mehr ;D .

Was STATE angeht => stateFormat würde helfen. Mit dem "verfrühten" Füllen des Readings "state" habe ich so meine Erfahrungen gemacht, seither reserviere ich das für den "Hauptschalter" ;D ...

Aber sowas wie ein "connection"-Reading würde Sinn machen, etwa in die Richtung: unreachable, unauthorized, ok, priviledged. Tendenziell würde man sowieso sowas wie eine "ping"-Routine brauchen (Rudi hat da was im Repertoire, man braucht kein qx...).

Das Logging von den nächsten Verbindungsversuchs-Zeiten auf Level 3 erscheint mir auch nicht optimal, sollte eigentlich auch eher ein Reading sein.

(Vielleicht bei Gelegenheit mal).

Vielleicht hilft das etwas beim Thema connection

https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV



Grüße
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: Beta-User am 17 Oktober 2021, 16:57:50
Vielleicht hilft das etwas beim Thema connection

https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV (https://wiki.fhem.de/wiki/DevelopmentGuidelinesAV)
Danke für den Hinweis, an diese Stelle/Parallele hätte ich jetzt leider nicht gedacht.

Fyi: im Modul eine eine m.E. einfachere, aber ausreichende Implementierung deines Passwort-Helferleins drinne...

@alanblack:
Ich schau's mir, kann aber etwas dauern.

Als Leitlinie: Attribute bitte dann, wenn man entweder User-Input ermöglichen will, oder irgendeine Info unbedingt verstetigen muss (weil ohne statefile sonst irgendwas gravierend in die Binsen geht). Tendenziell sollte alles, was von Modulseite her kommt, entweder in Readings (wenn  Event-auswertbar gewünscht ist), oder in Internals (wenn sowieso jedes Mal wieder neu aufgebaut und keine Events erforderlich sind).
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: alanblack am 17 Oktober 2021, 19:27:18
Danke für den Hinweis, an diese Stelle/Parallele hätte ich jetzt leider nicht gedacht.
@CoolTux
Ich suche noch nach Parallelen, aber danke für den Hinweis!

Zitat
@alanblack:
Ich schau's mir, kann aber etwas dauern.
@Beta-User
Lad nochmal runter! Einen Bug hatte ich noch gefunden; und einfach noch einmal den Internaltimer nach FHEM-Guidedlines eingebaut. FHEM friert nicht mehr ein - aber TVHeadend ist scheinbar sehr träge im Erkennen von "verschwundenen" Input-Devices. Ich probiere gerade, wie ich dort eine Reaktion provozieren kann.

Grüße
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: Beta-User am 17 Oktober 2021, 19:52:11
"Normale" Connection-States sollte man anzeigen bzw. in Readings packen wie bei "Multimedia-Geräten" üblich. Die "Besonderheit" hier ist, dass es zwei unterschiedliche Zugangslevels gibt, nämlich "normal" und "privelegiert" (oder wie auch immer man das nennen will). Das könnte man aber gesondert abbilden (Internal).

Bzgl. TvHeadend_HttpGetBlocking(): Das gefällt mir grundsätzlich nicht so gut. Meine Vision wäre, zuerst eine Art "ping" zu machen und dann die Abfragen, die in einem Rutsch durchgehen sollten, mit dieser Methode zu machen, und alles anderen nonblocking (einschl. des "ping"). Bezogen auf InputQuery hieße das: zwei Routinen, eine zum Aufruf, eine für den Callback.

Ansonsten suche ich grade nach den Unterschieden. Evtl. ist es einfacher, wenn du (auch) ein "diff -u" anhängst.

Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: alanblack am 17 Oktober 2021, 20:00:25
Ansonsten suche ich grade nach den Unterschieden. Evtl. ist es einfacher, wenn du (auch) ein "diff -u" anhängst.
Bekommst Du gleich. Ich hatte auch die "neue Version" nicht angehängt.
Allerdings habe ich inzwischen auch die "Next Update" vom Log in ein Reading umgebogen. Da bin ich gerade am Testen, ob ich keinen Bug eingebaut habe. Gib mir ein paar Minuten.  ;)

Grüße
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: MadMax-FHEM am 17 Oktober 2021, 20:03:07
Bekommst Du gleich. Ich hatte auch die "neue Version" nicht angehängt.
Allerdings habe ich inzwischen auch die "Next Update" vom Log in ein Reading umgebogen. Da bin ich gerade am Testen, ob ich keinen Bug eingebaut habe. Gib mir ein paar Minuten.  ;)

Grüße

Ist das nun getestet? ;)

Weil ich hab grad die Version von vorne runter...
...die jetzt auch schon mal...

EDIT: also mit dieser Version kommt mein fhem nicht mehr auf die Beine nach shutdown restart (habe ich sicherheitshalber mal gemacht) / nach dem Warum im Log muss ich noch suchen... Oder ich warte auf die neue Version ;)
Undefined subroutine &TvHeadend::gettimeofday called at ./FHEM/70_TvHeadend.pm line 118, <$fh> line 426.
und dann wird neu gestartet...

Gruß, Joachim
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: alanblack am 17 Oktober 2021, 20:16:03
Ist das nun getestet? ;)
Naja, ich würde mal sagen: frühe Beta.  ::) Ich habe gerade gesehen, dass da noch ein Doppelpunkt am Readings-Namen hängt. Sonst ist mir noch kein Bug aufgefallen, der nicht schon drin war.

Zitat
EDIT: also mit dieser Version kommt mein fhem nicht mehr auf die Beine nach shutdown restart (habe ich sicherheitshalber mal gemacht) / nach dem Warum im Log muss ich noch suchen... Oder ich warte auf die neue Version ;)
Lagging habe ich bisher nicht verzeichnet - allerdings auch noch einen Neustart gemacht; mache ich gleich mal.

@Beta-User
Das diff zwischen der letzten Version von 20:00:25 und der aus dem OP hängt dran.

Grüße
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: alanblack am 17 Oktober 2021, 20:32:03
Undefined subroutine &TvHeadend::gettimeofday called at ./FHEM/70_TvHeadend.pm line 118, <$fh> line 426.
und dann wird neu gestartet...

Gruß, Joachim
Dann ist diese Doku überarbeitungswürdig: http://www.fhemwiki.de/wiki/DevelopmentGuidelines#Mechanismus_f.C3.BCr_aktive_Readings (http://www.fhemwiki.de/wiki/DevelopmentGuidelines#Mechanismus_f.C3.BCr_aktive_Readings)
Zitat
In der Routine DEVICE_Define wird ein interner Timer gestartet, der die Updatefunktion aufruft. INTERVAL ist die Periode in Sekunden.
sub
DEVICE_Define($$) {
...
InternalTimer(gettimeofday()+$hash->{INTERVAL}, "DEVICE_GetUpdate", $hash, 0);
...
}
Dann weiß ich aber wenigstens, warum es auch beim ersten Mal nicht funktioniert hat.

Grüße
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: Beta-User am 17 Oktober 2021, 21:05:20
Achtung, nicht alles durcheinanderwerfen:
Die FHEM-Doku ist RICHTIG - wenn man davon absieht, dass Prototypes verwendet werden und das nicht gepackaged ist!

Würde zum Verständnis des Fehlers und der Code-Struktur empfehlen, mal das hier zu überfliegen: https://forum.fhem.de/index.php/topic,122708.0.html.

Dann ist vielleicht auch klarer, warum meine InternalTimer-Anweisungen anders aussehen:InternalTimer(time+AttrVal($name,'PollingInterval',60),\&TvHeadend_ConnectionQuery,$hash);Da  wird kein Text übergeben, sondern eine Code-Referenz, und die Zeit wird einfach aus einer Funktion geholt, die zum Perl-Core gehört... (zu letzterem habe ich bisher noch keine Probleme festgestellt und weiß ehrlich gesagt nicht, warum das früher in FHEM anscheinend anders gehandhabt wurde).

Diff. schaue ich mir an.
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: Beta-User am 17 Oktober 2021, 21:31:49
Habe zwar nicht verstanden, was das jetzt genau macht, und finde auch die gleichzeitig laufenden Timer hinterfragenswürdig, aber so läuft es erst mal wieder, soweit erkennbar...

Anmerkung:
Habe die Timer-Initialisierung nach firstInit verlegt. Hintergedanken:
- Da sind alle Attribute gelesen, man könnte also den Input-Query optional machen und/oder ein eigenes Intervall vorsehen;
- Falls man das Modul bzw. die Instand deaktivieren will, kann man mit "firstInit" alles wieder zum Laufen bekommen...
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: alanblack am 25 Oktober 2021, 20:06:09
Habe zwar nicht verstanden, was das jetzt genau macht, und finde auch die gleichzeitig laufenden Timer hinterfragenswürdig, aber so läuft es erst mal wieder, soweit erkennbar...
Meine Änderung pollt die aktiven DVB-Inputs. Wie ich letzte Nacht feststellen musste, funktioniert das auch,
denn ich bekam durch ein Notify darauf eine Meldung auf's Handy.

Allerdings muss da noch eine Änderung rein: der eine Timer, der durch die EPG-Daten erzeugt wird, reicht so
nicht. Der Odroid schien irgendwie gehangen zu haben. Jedenfalls hatte dieses TVHeadend-Modul keine
(sinnvolle) Antwort bekommen, dadurch gab es keine neue EPG-Abfrage, dadurch keinen neuen Timer...
Bei mir gab es heute morgen ein DVB-Input weniger aber EPG-Daten von quasi Mitternacht.
Aktuell hilft hier nur ein irgendwie geartetes Neuladen des Moduls, sonst passiert bei EPG nix mehr.
Ich überlege, ob es der sinnvollste Weg ist - ein kurzer ist es auf jeden Fall - wenn der zweite Timer auch schaut,
ob "nextUpdate" bereits in der Vergangenheit liegt. Ich habe dafür erstmal die Log-Meldungen in ein Reading
geschoben.
Ab Zeile 477
        readingsEndUpdate($hash, 1);

        Log3($name,3,"$name - Next update: ".  strftime("%H:%M:%S",localtime($update)));
in
        readingsBulkUpdateIfChanged($hash, "nextUpdate", strftime("%H:%M:%S",localtime($update)));
        readingsEndUpdate($hash, 1);
ändern.

Nur will ich nicht im Worst-Case alle 60 Sekunden eine EPG-Abfrage machen, die nur auf einen
Fehler läuft.

Ich denke, ich sollte "mal den Stecker vom TVHeadend ziehen" und schauen, wie ich möglichst ohne Systemlast
seitens FHEM die Zeit bis zum "Stecker einstecken" überbrücke und dieses auch sauber erkenne.

Grüße
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: alanblack am 14 Januar 2022, 19:53:27
Nachdem ich ein paar Mal das Device "neustarten" musste, habe ich endlich mal Zeit gefunden, um nach einer Lösung zu suchen.

Einfügen Zeile 16:
use List::Util qw(max);
Ändern Zeile 435/436:
my $update = $hash->{helper}{epg}{update};in
my $update = max($hash->{helper}{epg}{update}, time+AttrVal($name, 'PollingInterval', 60));
Damit kann ruhig mal die EPG-Abfrage schief laufen.

Dann hatte ich zwei Log-Einträge:
2022.01.13 22:03:07 1: JSON decoding error: invalid character encountered while parsing JSON string, at character offset 662 (before "\x{1a} Haarserum\\n4...") at ./FHEM/70_TvHeadend.pm line 338.

2022.01.13 22:03:07 1: JSON decoding error: invalid character encountered while parsing JSON string, at character offset 657 (before "\x{1a} Haarserum\\n4...") at ./FHEM/70_TvHeadend.pm line 338.
Da habe ich keinen Ansatz, wie ich die Ursache suchen und ggf. beheben kann.

Grüße
Titel: Antw:[reloaded] TvHeadend-Modul
Beitrag von: masterpete23 am 08 Februar 2022, 20:49:33
Hi,

hast du schon eine Lösung gefunden?
Wollte es gerade einsetzen, aber ohne die Umgebung zu crashen :)