Tut mir leid, wenn es unklar war, was mein Problem ist ...
Dachte, "automatische HDMI Umschaltung" deaktivieren reicht als Erklärung.
Egal ...
Die config.txt musste nicht bearbeitet werden.
Die ist noch immer die gleiche, die ich seit 17.x verwende.
Das update auf 18.x und nun auf 19.x hat nicht dazu geführt, dass die config.txt verändert wurde.
Jedenfalls steht der Eintrag da drin und wird ignoriert.
Ändert ja auch nix daran, dass meine Einstellungen in Kodi 19.4 nicht übernommen werden.
Nein, ausgeschaltet habe ich noch nix ...
Macht ja auch wenig Sinn, wenn ich die Fernbedienung des TV zur Steuerung nutzen will 
Oder gibt es da eine neue Lösung, die ich nicht gefunden habe ?
EDIT : habe es gerade mal des Spaßes halber probiert ... genau das gleiche Phänomen. Nach einem Reboot ist das CEC Adapter wieder aktiv und die Einstellungen stehen auf default.
Moin zusammen ...
... nachdem ich nun endlich mal Zeit hatte habe ich meine RaspPi 3 nun auf die 10.0.2 geschoben.
Mein einziges Problem - mit dem ich so nicht gerechnet hatte - : Die automatische HDMI-Umschaltung beim Start des RaspPi
Bis zur 9.2.8 hatte es noch gereicht, in der config.txt den Parameter
hdmi_ignore_cec_init=1zu setzen, bzw. auszukommentieren.
Das scheint nicht mehr zu klappen, wie es ja auch in den changes steht:
hdmi_mode, hdmi_group, hdmi_edid_file etc settings in config.txt can no longer be used to work around display issues.
Also dachte ich, es reicht, wenn man es in den settings einstellt und "Kodi beim Starten als aktive Quelle melden" deaktiviert.
Mein Problem: Ich kann diese Option nicht deaktivieren! Nachdem ich eine Änderung an den Einstellungen mache und mit "OK" bestätige, wird der Dienst wohl neu gestartet und es dauert ein wenig, bis das Signal wieder da ist.
Ein erneuter Blick in die Optionen zeigt, alles deaktiviert ...
Dann schalte ich den RaspPi aus, wechsle am TV wieder auf eine andere Quelle und starte den RaspPi wieder.
Es erfolgt wieder beim Booten der Wechsel auf den RaspPi Port und in den CEC Settings steht wieder alles auf default "aktiviert".
Ist hier irgendwas "readonly" ?!
Moin zusammen ...
... nachdem ich nun endlich den Wechsel auf die aktuelle 9.0.x gemacht habe, bereue ich es auch schon wieder an einem meiner RaspPi, der aktuell nur via WiFi/WLAN verbunden werden kann.
Bei nahezu jedem Start wird keine Verbindung aufgebaut.
Im LE AddOn kann ich die Verbindung sehen, wird allerdings als "failure" angezeigt.
Ich kann mich zwar sofort mit dem Netzwerk verbinden, muss aber warten, bis LE sich selber "abschießt" und neu startet. Sonst bekomme ich keine Verbindung zu meinem NAS.
Starte ich selber neu hängt sich das System beim Abspielen einer Datei nach spät. 2 Minuten auf.
Der Gugel sagt, es soll was mit dem aktuellen Kernel und dem RaspPi 3 zu tun haben.
Aber mehr habe ich nicht rausgefunden.
Gibt es für das Problem vielleicht einen workaround, den ich noch nicht gefunden habe?
Falls jemand eine Idee hat ... ich bin für alles zu haben
greetz
Der Rico
Moinsen ...
... ich bin auf der Suche nach einer Lösung für Kodi & DVB-S2 im Wohnmobil.
Also laufen muss das ganze somit mit 12V und einer bereits vorhandenen SAT-Anlage.
Mir fielen dann gerade die alten WETEK-Kisten ein. Wäre das vielleicht eine Lösung, um evtl. mal TV anzuwerfen und den einen oder anderen Film via USB-HDD anzusehen? Günsitger werde ich's doch wohl nicht bekommen!?
Läuft auf einer alten WETEK PLAY DVB-S2 noch ein aktuelles KODI mit TVH?! Das würde mir völlig reichen ...
Falls damit jemand Erfahrung hat oder selber was in der Richtung gebastelt hat, bin ich für alle Ideen dankbar ...
Greetz
Der Rico
Kann ich eine MCE nehmen die kompatible mit Kodi ist und nen IR Empfänger hat.
Die konfig auf die 350 übertragen ( lernfunktion ).
Läuft die 350 dann über den mitgeliefertem IR Empfänger?
Sollte klappen.
Der 350 ist der Empfänger ziemlich egal. Und so lange er RC6-kompatibel ist, läuft er auch unter KODI.
Die Standard-MCE remotes mit USB-Receiver funktionieren auch alle ab Werk unter KODI.
Als Alternative zur Harmony 350 kannst Du Dich auch bei OneForAll umschauen.
Die gute alte URC 7962 gibt's ja leider kaum noch irgendwo
Die URC 7980 ist glaube ich die einzige mit Beleuchtung und mit rund EUR 50,- ziemlich happig im Preis. Wird aber wohl meine nächste, wenn die 7962 mal den Geist aufgibt.
Alternativ mit 4 Geräten die URC 7145, dann aber ohne Beleuchtung.
Aber ich bin froh dass überhaupt jemand sich die zeit nahm rbuehlmas Patches reinzufummeln. Da ist Kodi Leia das kleinere übel welches ich mit Kusshand nehm.
So sehe ich das natürlich auch.
Mir geht's ja aktuell auch vor allem um den bevorstehenden Urlaub in DK. Dafür langt's auch so
Im estouary mod kann ich leider den VPN-Manager nicht mehr konfigurieren.
Aber das sit nicht so tragisch. Im normalen Estouary klappts ja ...
Da ich keine eigene SAT-Schüssel mitnehmen will, ist diese Variante mit Leia -> Zattoo und einem VPN in die Schweiz schon klasse
Denn wenn die Kids da bei sch**-Wetter nicht auch mal KiKa sehe@'indri' und @rbuehlma für die Arbeit
Also als ich zuletzt vor etwas über einem Monat mal auf meinem RPi2 mit dem offiziellen LE 8.x dieses tar update von @indri durchgeführt hatte, konnte ich mit seiner pvr.zattoo-0.2.6.1.zip und ich glaube mit dem inputstream.mpd-1.2.6.0.zip normal mit schnellen zapping-zeiten die DASH streams schauen. Ich vermute das müsste noch immer gehen.
Ja, das geht ja auch ...
Aber dann ist es nicht Krypton, sondern Leia ... is 'ne 18'er Alpha-Version ...
Damit funktionieren die Krypton-Skins nicht mehr ...
@infinity
sorry ... ich vergaß ... RaspPi 3 mit LE 8.0.2
Aloha zusammen ...
... nach zwei Tagen lesen und testen bin ich noch immer nicht wirklich schlauer geworden 
Kann man eigentlich irgendeine Variante unter auf einem RaspPi 3 mit LE 8.0.2 zum Laufen bekommen?
Ich habe viele inputstream und zattoo-pvr Kombinationen getestet und bei jeder endet es in "PVR Manager wird gestartet" ...
Einzig funktionierende Variante bislang ist @indri 's ALPHA von 18.x wobei ich auch noch nicht weiß, welchen Zweck die TEST-Versionen im binary-repo erfüllen ...
Und @rbuehlma 's files bringen mich ja wohl nicht weiter, da sie ja nur für ubuntu gebaut sind, wenn ich das richtig gelesen habe ...
Vielleicht kann mir ja jemand einen kleinen Wink mit der Raketenstütze geben.
Tja ... autoshutdown entsorgen und wieder neu hinzufügen scheint es gelöst zu haben ...
Jedenfalls bleibt das NAS jetzt an
Aufgenommen wurde trotzdem nix ...
In lfd. Aufnahmen steht zwar was drin, aber die Dateigröße änderte sich nicht ...
Dann habe ich nochmals eine Aufnahme via KODI erzeugt ...
Und siehe da: Klappt!
Strange: Aufnahmen, die via TVH-WebGUI erzeugt werden, laufen nicht ...
Werden zwar als laufend angezeigt, aber es passiert nichts.
Ja, das dachte ich auch, @Grabber66 ...
Aber die einzige Änderung war ja das hier, wenn ich mich nicht irre:
tmp_start=`cat $i | grep '"start":' | head -1 | cut -f 2 -d " " | cut -f 1 -d ","`
tmp_stop=`cat $i | grep '"stop":' | head -1 | cut -f 2 -d " " | cut -f 1 -d ","`Also quasi ja nur das "head -1" mit rein ...
War der Grund, warum der RTCwake nicht korrekt gesetzt wurde ...
Aufwachen tut er ja schon wieder ... nur geht er gleich wieder aus beim RTCwake ...
Und zwar nicht in den StandBy sondern Off!
Das Autoshutdown scheint auf einmal zu spinnen.
Moin ...
... ich habe nach geraumer Zeit mal wieder was via TVheadend aufnehmen wollen.
am nächsten Tag stand die Aufnahme allerdings unter "Fehlgeschlagene Aufnahmen" mit dem Kommentar "time missed".
Hatte ich so noch nicht ...
Wenn ich das richtig verstanden habe, tritt dieser Fehler z.B. auf, wenn der Tuner kein Signal hat. Würde ich ausschließen wollen, da Live TV unter Kodi sofort nach dem Start zur Verfügung steht.
Aktuell läuft TVheadend unter OMV 2.x in der Version 4.1.
OMV lauft nicht 24/7, sondern geht via autoshutdown in den StandBy.
Beim Suspend wird der die nächste Aufnahme via script als rtcwake gespeichert, TVHeadend und OSCAM beendet und die Treiber der Karte entladen.
Beim Resume werden die Treiber wieder eingebunden und TVheadend samt OSCAM gestartet.
Das klappt soweit bei manuellen WakeOnLan des NAS einwandfrei. Die Privaten in HD sind immer vorhanden.
Nur beim rtcwake habe ich festgestellt, dass OMV aus dem StandBy aufwacht und kurz danach wieder herunerfährt! Also nix StandBy ... AUS!
Ich würde also irgendwo in den configs ein "shutdown" oder "init0" vermuten, kann es aber nicht finden.
Bei der ursprünglichen Einrichtung hat das ganze reibungslos geklappt.
Und da an den Scripten seit Monden nichts geändert wurde, stehe ich gerade vor einem Rätsel, woran das liegen könnte.
Die scripte unter /etc/pm/sleep.d würde ich ausschließen, da es bei manuellen WOL funktioniert.
Vielleicht hat ja einer der TVH-Nutzer eine Idee ... @C0mmanda ? @Grabber66 ? @CvH ?
Bin für jede Idee dankbar ...
greetz
Der Rico
Also solange alles ohne WLAN läuft, funktioniert es mit der FB6490 und TVHeadend einwandfrei.
Einbrüche mit Artefakten gab's bei mir erst, sobald während einer laufenden Aufnahme ein weiterer Client via WLAN direkt an der FB hing.
Unproblematisch war es wiederum, wenn der Client (Android-Tablet) via App "TVHclient" zum TV-Schauen verwendet wird.
Die TV-Streams direkt von der FB bremsen das WLAN anscheinend stark aus.
Ich mache das für den DK-Urlaub auch immer ...
Da zu Hause ja alles schon fertig gescraped ist, ziehe ich einfach die kompletten Infos mit auf die Platte.
Die HDD wird dann als lokale Quelle mit Informationsquelle "local information only" eingebunden.
Da ist die DB ratzfatz neu aufgebaut.
Falls Filme entfernt wurden, einfach einmal die DB bereinigen lassen und gut is.
Auf den watchedstate verzichte ich dann für die paar files.
Für ein paar Aufnahmen der Kids aus anderen Perspektiven habe ich mir so kurz vorm Urlaub auch noch mal was gegönnt ...
Parrot Bebop2 inkl. FlyPad und XIAOMI nanoYouth Repeater.
Passender GoPro-Filteradapter mit UV- und Polfilter ist noch im Zulauf ...
Falls der RaspPi am TV hängt, sollte sich KODI schon mittels CEC steuern lassen.
Ansonsten vielleicht mal hier schauen.
Letzten Endes ist es so, dass dein OS für WOL zuständig ist, der Emby Server wird da wohl nie etwas eigenständiges haben!
Das fürchte ich auch ...
Ich habe Emby ursprünglich ins Auge gefasst, weil z.B. Samsung in seinem SmartHUB ein Emby AddOn hat.
Aber auch da gibt es keine Option, den Emby-Server via WOL zu wecken.
Deswegen musste ich zwangsweise bei den Kids am TV nun doch einen RaspPi mit LE dran hängen, da mein EmbyServer nicht 24/7 läuft.
fehlende Schreibrechte?
Und die üblichen Verdächtigen wie minitool partition wizard und easeus partition manager zeigen das gleiche an ? PartedMagic unter Linux auch?
Ich würd's mal über Linux weiter probieren.
Ich kenne das problem allerdings auch nur von Sticks und SDs, auf denen mal der OpenElec Installer drauf war ...