Beiträge von Markus23

Super, dass da noch was vor Weihnachten kommt.
Da kann ich an meinen freien Tagen endlich mal alles neu/frisch machen.
Ich freu ich schon

So, habs hinbekommen.
Die Anleitung aus Post #1 und das Repo von Kodi 15.2 hat geklappt.
Bisher auch keine Probleme beim Beenden von Kodi.
Werde weiter testen und noch mal Rückmeldung geben.

Hab jetzt da nicht so die Erfahrung mit Repos mixen / ggf. Pinning.
Funktioniert es, dass ich erst meine XBMC Datn sichere, dann das Kodi Repo einbinde und dann einfach Kodi installiere ?
kodi erkennt das installierte XBMC und macht ein Upgrade.
Muss ich noch irgendwelche Anpassungen an yavdr vornehmen, oder ghet eigentlcih alles weiterhin (Ich nutze XBMC Nicht für TV) ?
Kann ich dann einfach alles rückgangig mache, indem ich das Repo wieder entferne und die yavdr xbmc pakete installiere ?

Kann man eigentlich das neue Kodi auch parallel zum alten XBMC installieren ?
Die Speicherpfade dürften sich ja wegen der unterschiedlichen Namen nicht ins Gehege kommen.
Ich würde gerne mal Kodi testen, aber nicht gleich mein kompletten alten XBMC Daten opfern.

Hallo und auch Dir ein frohes neues Jahr !

Ich habe eben mal klar Tisch gemacht und das selbst hinkopierte Plugin gelöscht, es nochmal neu von deiner HP geladen und per ZIP-Install installiert.

Dann alle speziellen Anpassungen aus deinem letzten Post gemacht und nochmal die visudo Einstellungen neu gemacht.
Als letzes statt "shutdown -h now" einfach "pm-suspend" noch in die shutdown.sh eingetragen, weil das bei mir ja so funktioniert.

Ergebnis:

Nun hat es geklappt mit dem Timer setzen und suspend gehen
Ich werde nochmal alles kontrollieren, aber es scheint wohl so das da wirklich irgendwo eine Kleinigkeit verstellt war die sich gross ausgewirkt hat.

Soweit erstmal VIELEN DANK für deine Hilfe und ich gebe nochmal Rückmeldung ob nun wirklich alles läuft (auch mit Sleep nach er Aufnahme usw..)

Gruß,

Markus

PS:

Ich hab gerade noch eine (für mich) brauchbare Verbesserung eingebaut:

Eigentlich funktioniert die KODI-Eigene Suspend Routine richtig gut, gibt dann beim Wakeup auch keine Grafikfehler usw.
Deswegen habe ich dein Shutdown.sh so abgeändert, dass eben nur das Wakeup gesetzt wird, kein "Shutdown" oder "pm-suspend" mehr.
Als nächstes habe ich folgende Zeile in default.py eingefügt:

def setWakeup(self):


        if self.calcNextSched():
            __task = ['Recording', 'EPG-Update']
            self.writeLog('Wakeup for %s by %s at %s' % (__task[self.__wakeUpReason], self.__wakeup, self.__wakeUp.strftime('%d.%m.%y %H:%M')))
            if self.__nextsched:
                self.notifyOSD(__LS__(30017), __LS__(30018 + self.__wakeUpReason) % (self.__wakeUp.strftime('%d.%m.%Y %H:%M')), __IconSchedule__ )
                xbmc.sleep(5000)


        self.writeLog('Instruct the system to shut down')


        if os.path.isfile(PIDFILE): os.remove(PIDFILE)
        if PLATFORM_OE:
            os.system('%s %s %s' % (SHUTDOWN_CMD, self.__wakeup, self.__wakeUpUT))
        else:
            os.system('sudo %s %s %s' % (SHUTDOWN_CMD, self.__wakeup, self.__wakeUpUT))
            xbmc.executebuiltin('Suspend')


    ####################################### START MAIN SERVICE #####################################

Mittels dieses "xbmc.executebuiltin('Suspend')" wird dann halt der Suspend über KODI ausgelöst -> klappt soweit besser, wie direkt pm-suspend aufrufen !
Man kann wohl auch "xbmc.executebuiltin('Shutdown')" aufrufen, dann gibts halt shutdown.

Hallo !

Zitat von BJ1

Warum hast Du das händisch installiert? Normalerweise funktioniert eine Installation via Zip.

Hatte ich nur der Einfachheit so gemacht, weil ich gerade per SSH auf der Kiste war, hat ja grundsätzlich auch funktioniert.

Zitat von BJ1

Das Skript pollt bei einer Aufnahme die status.xml und wertet diese aus. Sind/ist die Aufnahme(n) abgearbeitet, wird der Rechner per shutdown.sh runtergefahren.

Bedeutet das, wenn eine Aufnahme automatisch abgearbeitet wurde, aber noch einer weitere vorhanden ist, dann bleibt der PC erstmal an ?
Oder ist dein Plugin so schlau, das es den PC wieder schlafen legt, wenn der Timer zu lange in der Zukunft ist ?

Zitat von BJ1

Hier gibt es jetzt 2 Möglichkeiten:
Die Rechte für die shutdown.sh bzw. der Eintrag in visudo stimmt nicht.Kodi ist aufgrund dessen, dass der TV aus war, nicht korrekt gestartet. Macht sich insofern bemerkbar, dass der Bildschirm nach einschalten des TV schwarz ist. In dem Fall brauchst Du eine X11-Konfiguration per edid.bin, damit X auch ohne angeschlossenes Sichtgerät startet.
Ansonsten solltest Du einen Shutdown per F12-Taste (Keyboard) oder Powerbutton der FB auslösen können. Wird alles geloggt.

Das mit dem nicht korrekt starten könnte sein, hatte bisher dafür immer diese HDMI Doctor Kästchen, was ein TV-Gerät emuliert damit auch immer ein (eingeschalteter) TV erkannt wird.
Muss ich dann wohl mal wieder reinbauen

Das mit dem Auslösen des Poweroffs hatte ich mehrmals ausprobiert , weder mit F12 noch mit Powerbutton wurde der Sleep endgültig gestartet,
Hatte dann selbst schon mal bisschen im Log geschaut und dein Plugin läuft wirklich bis zum Punkt wo das "sudo...shutdown.sh" aufgerufen wird, nur dann passiert nichts.
Im Log sieht man dann nur noch die Meldungen das der Prozess-ID beendet wurde und die (Erfolgs)Abschlussmeldung mit den ASCII-Männchen.
Trotzdem bleibt der PC an.
Wenn ich aber wiederum das shutdown.sh mit den passenden Werten -> z.B. "sudo shutdown.sh ACPI Wakeuptime" aufrufe, dann funzt das script.

Ach Ja, ich habe den Shutdown.sh soweit abgeändert, dass nicht "shutdown -h now" aufgerufen wird, sondern "pm-suspend" für Suspend-to-Ram.
Aber auch diese Änderung funktioniert mit dem o.g. händischen Aufruf , nur wenn es durch dein default.py aufgerufen wird, funzt es nicht.
Es wird noch nicht mal die Eintragungen unter /sys/.../../wakeuptime dann gemacht, das shutdown.sh wird einfach nicht aufgerufen

Zitat von BJ1

echo 'Cmnd_Alias PVR_CMDS = '$HOME/'.kodi/addons/service.tvh.manager/resources/lib/shutdown.sh' > vis.txt
echo $USER' ALL=NOPASSWD: PVR_CMDS' >> vis.txt
more vis.txt

Zitat von BJ1

in visudo reingeschrieben werden.

Habe ich schon so integriert, sonst würde ja ein händischer Aufruf von "sudo /home/Benutzername/.kodi/addons/service.tvh.manager/resources/lib/shutdown.sh ACPI Aufwachtest auch nicht funktionieren, bzw. er würde nach nem Passwort fragen.
Aber das funktioniert ja wie gesagt. So richtig weiss ich nicht weiter.

Vielleicht fällt Dir noch was ein, ich werde aber auf jeden Fall mal den HDMI-Doctor wieder einbauen...

Gruß ,

MArkus

Hi !

Ich habe seit ein paar Tagen Kodibuntu (Helix) mit tvheadend (unstable) laufen.
Hab dein Plugin mal händisch installiert und es wurde auch erkannt und ich konnte alles konfigurieren.

Leider habe ich 1,2 Problemchen von denen ich nicht alle selbst lösen konnte:

1. das shutdown.sh wollte partout nicht starten
-> habe dann gemerkt, das irgendwie Dos-Codes drin waren, nachdem ich dos2unix rüberlaufen liess, startete es auch.

2. Es ist alles so konfiguriert wie in der Anleitung beschrieben mitsamt sudo ohne password für das shutdown.sh
-> Leider wird das shutdown script NICHT durch das Plugin gestartet, wenn ich es aber händisch als kodi-user aufrufe funktioniert es.
Ich fand aber weder im Plugin.log noch im Kodi.log noch im system.log irgendwelche Fehlermeldungen ?
Warum wird der Sudo Aufruf durch default.py nicht gemacht ?

3. Durch was wird es gelöst, dass der PC nach einer programmierten Aufnahme und keiner Benutzeraktion sich wieder schlafen legt ?
-> hatte heute morgen um 06 Uhr ne Aufnahme programmiert und den PC (per händischen) Aufruf von shutdown.sh ACPI "Zeitpunkt" schlafen gelegt.
-> Der PC ist auch aufgewacht, die Aufnahme wurde gemacht, aber er lief immer noch , als ich um 11 Uhr geschaut habe .
-> Ok , könnte auch daran liegen, das der Aufruf von Shutdown.sh über das default.py nicht funktioniert.

4. Braucht der TVHeadend User der im Plugin hinterlegt wird definitiv ADMIN Rechte, oder reicht Webinterface, Streaming ?
-> wie müssen die Rechte dort genau aussehen ?

Soweit erstmal meine Probleme , ich hoffe es gibt eine Lösung dafür
(Vor allem das Problem mit dem shutdown.sh ist echt komisch -> händisch gehts, per default.py nicht !? )

Gruß und schon mal nen guten Rutsch,

Markus

gerne , mache ich nachher mal ...

Ja, sorry - hatte ich vergessen zu tippen..
Ist natürlich MIT : , es funktionierte grundsätzlich ja mit diesen beiden optionen

Nutze nun erstmal die "gepachte" Version aus yavdr/testing weiter , allerdings mit ClearOnSwitch=0 und -w alsa-close-open.

So,

ich habe nun mal einiges auf meinem System durchgestestet mit der gepatchten softhddevice Version und den diversen Optionen.
Nachzulesen in diesem Thread -> Link

Zusammenfassung:

Bei mir funktioniert eigentlich immer nur die Option ClearOnSwitch=0 , oder ClearOnSwitch=0 und -w alsa-close-open (mit Patch).

So,

ich hab bei mir nun auch mal einige Tests gemacht. Hatte ja das Problem , dass nach XBMC beenden der Ton weg war in VDR und mit der Option ClearOnSwitch = 0 ging es dann wieder.
Nun die (angeblich) gepatchte Version auf yavdr/testing installiert und probiert.

asound.conf seht auf :
pcm.!default {
type hw
card 0
device 7
}

In der plugin.softhddevice steht standardmässig :
-D
-a hw 0,7
-p hw 0,7

Nun mit den Tests begonnen...

Mit ClearOnSwitch = 0:
- Kein Ton in VDR, schon beim ersten Starten nicht

Mit ClearOnSwitch = 1 :
- Kein Ton in VDR , schon beim ersten Starten nicht

Mit ClearOnSwitch = 1 und -w alsa-close-open :
- Ton in VDR
- Nach Beenden von XBMC wieder kein Ton in VDR

Mit ClearOnSwitch = 1 und -w alsa-close-open und -w alsa-close-open-delay :
- Ton in VDR
- Nach Beenden von XBMC wieder kein Ton in VDR

Mit ClearOnSwitch = 0 und -w alsa-close-open (also wie ohne Patch und nur ClearOnSwitch = 0) :
- Ton in VDR
- Nach XBMC beenden wieder Ton

Mit DETA und ATTA hab ich erst gar nicht probiert, weil es ja so schon nicht funktioniert hat!
Also bei mir keinerlei Verbesserungen , das einzige was hilft ist ohne Patch ClearOnSwitch = 0 , oder mit Patch ClearOnSwitch = 0 UND -w alsa-close-open

Gruß,

Markus

hab ich auch gesehen - ich werde morgen abend mal testen und berichten...

[edit] ..oder auch nicht, wenn ich sehe was Andere noch in dem Thread schreiben ... mal bis morgen abwarten.

Werde es morgen gerne noch mal probieren.

Inzwischen scheint es sich aber rausgestellt zu haben, das das neuere softhddevice Paket aus dem yavdr/testing wohl doch nicht, oder nicht richtig den Patch enthält -> siehe Link

Vielleicht sollte ich mit dem Testen der Optionen mal abwarten, bis auch in yavdr/testing ein Paket mit dem kompletten Patch verfügbar ist ?
Wenn ich Dich richtig verstehe , sind diese Optionen zum Testen ja in meiner aktuell genutzten vom 20.12.2013 noch gar nicht drin..

Also wg. dem enthaltenen Patch - Wurde so in meinem UrsprungsThread so geschrieben: XBMC 12.3 unter yaVDR (Ursprungslink)

Diese beiden Parameter habe ich beide noch nicht probiert, weder unter dem Paket vom 20.12.2013 , noch unter dem neuen Paket vom 14.01.2014.
Teste gerne beides noch mal , nur gerade Laufen Aufnahmen und es wird auch TV geschaut auf meiner Kiste Muss da später heute abend, oder morgen Abend mal Testen.

Meine Tonausgabe läuft per Passthrough über HDMI ( hw 0,7 ) und es sind die beiden Optionen -a und -p mit hw 0,7 in der plugin.softhddevice.conf definiert (sonst hätte das bei mir gar nicht mit dem Ton funktioniert).

Hi !

Kurz zur Erklärung ich nutze yaVDR (testing repo) und habe seit Installation von XBMC 12.3 auch das Problem, das softhddevice das Audio-Device nicht frei gibt.
Gestern wurde nen nen neues softhddevice Paket geschnürt (0.6.1rc1.git20140114.1359-0yavdr0~precise) , welches den hier genannten Patch enthalten soll.

Nach der Installation geht nur überhaupt kein Sound mehr bei mir, also wieder zurück auf die vorherige Version von softhddevice (0.6.1rc1.git20131220.2124-0yavdr0~precise) aus yavdr/testing und mal probiert die Option ClearOnSwitch auf 0 zu stellen.
Und plötzlich funktioniert wieder alles auch ohne Patch. Also kann ich nur sagen, das bei mir der Patch leider nicht funktioniert ...

Hi !

Zitat von seahawk1986

Probier mal die aktuellste Version von softhddevice aus testing-vdr, die enthält den Patch aus softhddevice gibt Sounddevice nicht frei - vielleicht hilft es...

Ich bin ja wie gesagt wieder auf die vorherige Version von softhddevice aus "testing" gegangen und habe mir mal den genannten Thread durchgelesen.
Nachdem ich nun auf alten Stand genau diese "ClearOnSwitch" Option auf 0 gestellt habe, funktioniert bei mir auch wieder alles

Keine Ahnung warum die neue softhddevice Version mit dem Patch aus testing bei mir überhaupt keinen Ton mehr bringt , aber mit der alten softhddevice und der Option ist es nun wieder alles i.O.

Falls sich da noch was ergibt , ich teste gerne ne gepatchte softhddevice erneut.

Also ich habe das Problem nur in VDR (Ton weg), wenn ich den XBMC beende.
Es scheint aber schon vorher ausgelöst zu werden, weil das Sounddevice von VDR belegt bleibt.

Wobei es noch die Frage ist, warum VDR (bei mir) nur mit Device 7 funzt, der XBMC aber Device 3 nutzt und funzt auch ?!

Ich habe mit alsa noch ein paar Tests mit alsasound gemacht und ich habe bei mir 4 Devices (3,7,8,9). ALLE sind aktiv geschaltet.
Nur bei Device 3 bekomme ich keinen Ton, bei 7,8,9 bekomme ich eine Tonausgabe.

Wenn ich den Automatismus von der Weboberfläche nutze und auf HDMI Passthrough stelle, wird in der asound.conf aber nur die Device 3 eingetragen !?
Also genau die , wo ich mit nem alsasound Test eben keinen Sound rausbekomme ?
Oder ist die asound.conf gar nicht so wichtig für VDR ? Andererseits bekomme ich bisher nur Sound im VDR , wenn eben in asound.conf das Device 7 eingetragen ist UND in plugin.softhddevice.conf -a und -p auch auf 0,7 stehen !
Wobei hier plughw oder hw egal ist !

Bin gerne bereit noch zu testen, nur so richtig einen Reim drauf machen kann ich mir nicht.
Ach ja hatte in XBMC noch nen Test gemacht und dort ist fast egal , was ich unter Device anwähle (3,7,8,9) überall kommt Ton , wichtig ist das als Ausgabe HDMI angewählt ist.

Gruß,

Markus

So, bin auch erstmal wieder zurückgegangen auf die vorherige Version.

Wenn ich nun unter /etc/asound.conf:

pcm.!default {
type hw
card 0
device 7
}

und /etc/vdr/plugins/plugin.softhddevice.conf:

-D
-a plughw:0,7
-p plughw:0,7

Bekomme ich wieder ohne Problem Ton.

Hab mal im Alsamixer geschaut und dort sind alle 4 HDMI Devices NICHT gemutet.

also ich hatte wie gesagt eh Probleme von Anfang an mit dem Ton.
Bei mir hatte nie die automatische Config von asound.conf gepasst, die erstellt wird, wenn im Webmenü die Soundconfig angepasst wird.
Also musste ich bisher die asound.conf so anpassen wie in meinem vorletzten Post geschrieben UND ich habe in der plugin.softhddevice.conf zwei Einträge gesetzt:

-a plughw:0,7
-p plughw:0,7

mit dem besagten Ton-Problem seit 12.3

Nun eben Update , alle anderen Einstellungen gelassen und gar keinen Ton mehr gehabt.
In XBMC hab ich inzwischen wieder Ton , nachdem ich die SoundEinstellungen wieder angepasst habe, waren statt auf HDMI auf Analog resettet.
In VDR geht immer noch kein Ton, obwohl von Vdr immer ein Sounddevice belegt wird ...

Gerade installiert und ausprobiert ( bin ja eh auf testing
nu habe ich gar keinen Ton mehr in VDR und auch in XBMC !?