kannst du mal bitte [definition=12,0]debug[/definition] [definition=12,9]logging[/definition] aktivieren und dann nochmal testen bitte?
Die logs sind keine [definition=12,0]debug[/definition] logs
okay... mahc ich gleich mal
Mmh... also... habe den DEbugging Modus gestern abend wie gesagt gestartet und bis jetzt läuft es sauber durch..
Ich brauche Zeit, um den Fehler nachzustellen. Ist nicht einfach.
Mmh... also... habe den DEbugging Modus gestern abend wie gesagt gestartet und bis jetzt läuft es sauber durch..Ich brauche Zeit, um den Fehler nachzustellen. Ist nicht einfach.
Ha... wenn man vom Teufel spricht: Gerade 06.12.2017 ca.16:37h ist es passiert:
1) iPad angemacht
2) Die iPad App "THE" gestartet
3) Verbindung via HTTP zum Raspi etabliert
4) Kodi 17.6. stürzt ab und startet neu.
[definition=12,4][definition='1','3']Debug[/definition][/definition] [definition='1','0']log[/definition] im Anhang.
Was ist denn das für eine App für das iPad? Kannst du mal einen Link zu der App bereitstellen?
Also, irgendwie sehe ich in dem Logfile gar nichts. Das Logfile ist ganze 2 Minuten lang. Es beginnt um 16:36 und endet um 16:38. Ich vermute mal, dass du einen Crash hattest, dann neu gestartet hast, und dann das Log gepostet hast. Somit ist der Fehler aber im kodi.old.[definition='1','0']log[/definition] zu finden (das ist das Logfile von vorangegangener Session). Das aktuelle Log sieht für mich sauber aus.
Kannst du das ganze bitte nochmal reproduzieren und dann beide logs auf pastebin posten. Die Logs hier anzuhängen ist mühselig. Da wir sie immer wieder runter laden müssen. Wenn du per SSH drauf bist (auch nach einem Neustart wenn Kodi gecrasht ist:
pastebinit /storage/.kodi/temp/kodi.[definition='1','0']log[/definition]
sowie:
pastebinit /storage/.kodi/temp/kodi.old.[definition='1','0']log[/definition]
Dann müsste entweder in '/storage/' oder in '/storage/.kodi/' ein crashlog mit einer Nummer vorliegen. Die Nummer sollte das Datum beschreiben. Bitte also auch einmal diese Datei via pastbin pushen.
Bei den obigen Befehlen bekommst du eine URL als Antwort zurück. Diese dann bitte hier posten.
Bitte folgendes in dem Wissen lesen, dass ich noch ein relativer Neuling in Sachen Linux und Linux Debugging bin.
Wegen dem Crashlog:
Es sieht so aus als ob die cec-library das Problem hervorgerufen hat.
Thread 42 (Thread 0x69b953a0 (LWP 4668)):
#0 0x75199598 in nanosleep () at ../sysdeps/unix/syscall-template.S:84
#1 0x751c6eac in usleep (useconds=<optimized out>) at ../sysdeps/posix/usleep.c:32
#2 0x007d9e6c in PERIPHERALS::CPeripheralCecAdapter::Process() ()
#3 0x005bc0ac in CThread::Action() ()
#4 0x005bc79c in CThread::staticThread(void*) ()
#5 0x76ed1f40 in start_thread (arg=0x69b953a0) at pthread_create.c:335
Backtrace stopped: Cannot access memory at address 0x66
Hast Du an der Stelle etwas gedreht?
Cheers
Claudia
Da gibt es noch 4 weitere Cannot access memory at ... im Log zu sehen -> muß also nicht der Grund sein.
Cheers
Claudia
Edit: aber die anderen sind im cond_wait, einzig cec in Ausführung -> also doch cec?
Die logs sind keine [definition=12,0]debug[/definition] logs
Das hatte ich ja vorher schon mal erwähnt:
Vom [definition=9,2]kodi.[definition='1','0']log[/definition][/definition]:
04:30:33.384 T:1944674880 NOTICE: Disabled [definition=12,0]debug[/definition] [definition=12,9]logging[/definition] due to GUI setting. Level 0.
Vom kodi.old.[definition='1','0']log[/definition]:
23:57:29.969 T:1944965696 NOTICE: Disabled [definition=12,0]debug[/definition] [definition=12,9]logging[/definition] due to GUI setting. Level 0.
Es ändert sich nichts an der Tatsache, dass wir [definition=12,0]debug[/definition] logs brauchen. Wenigstens das Crashlog weißt [definition=12,0]debug[/definition] Einträge auf.
@ClaudiaFIch bin mir auch immer unsicher. Wenn ich aber aus dem Crashlog das hier lese:
Zitat[Thread [definition=12,2]debugging[/definition] using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/usr/lib/kodi/kodi.bin --standalone -fs --lircdev /run/lirc/lircd'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
[Current thread is 1 (Thread 0x586593a0 (LWP 5801))]
Daraus würde ich schließen, dass man in "Thread 1" nachschauen muss. Gerade wenn man nach "0x586593a0" weißt das auf "Thread 1" hin.Im Thread 1 sehe ich ein paar Dinge, die mit JSON zusammen hängen, was mich wieder darauf schließen lässt, dass es mit der App zusammen hängt. Yatse sowie auch Kore senden JSON Kommandos an den Webserver (der muss ja aktiv sein, damit die Kommunikation funktioniert.
Im Endeffekt würde ich wirklich auf die App tippeen und ggf. sogar sagen, dass es kein Kodi Problem ist. Yatse, sowie auch Kore, machen bei mir keinerlei Probleme
Könntest du uns mal einen Gefallen tun und folgendes per SSH machen:
mv /storage/.kodi /storage/kodi-backup
und dann Kodi mal neu starten. Dann bitte mal versuchen nur die nötigsten Einstellungen vorzunehmen, damit die App Kodi bedienen kann (Webserver einschalten). Mich würde interessieren, ob Kodi ebenfalls crasht wenn man nur die App benutzt ohne, das irgendwelche andere Plugins installiert sind.
Ich sehe auch in einem der Logs jede Menge dieser Fehler:
04:30:53.557 T:1517253536 ERROR: AddOnLog: Tvheadend HTSP Client: pvr.hts - Command hello failed: No response received
Das Crashlog ist ebenso voll mit Einträgen, die TVH betreffen. Ich würde dich also mal bitten, obiges Kommando auszuführen. Das ist eine Art Werks-Reset und du hast ein komplett jungfräuliches Kodi danach. Es sind bei dir auch zusätzliche Repos installiert, die man eigentlich für TVH nicht benötigt. Wir bieten TVH in unserem eigenen Repo an.
Ich gestehe, dass ich tatsächlich nur rate und ich werde das Crashlog auch an unser Team weiter leiten. Vielleicht hat da auch jemand eine bessere Antwort für dich. Wenn es mein System wäre, würde ich aber wie oben gesagt, damit anfangen, ein frisches Kodi zu testen. Vielleicht schießt auch eines der Add-ons quer und verursacht so einen Fehler.
CEC hätte ich so erstmal nicht im Verdacht.
Alternativ, wenn du Kodi nicht zurück setzen magst, kannst du auch Mal eines der Milhouse Builds testen.
Es wird keine Fixes mehr für LE 8.2.1 geben. Sollte es also ein Kodi 17 Problem sein, wird sich daran nichts mehr ändern, da der Fokus nun auf Kodi 18 liegt
@DaVu - ja, deine Analyse macht mehr Sinn.
Im Thread1 wird auch der abort call, sprich das SIGABRT Signal abgesetzt.
Shame on me - hätte mir durchaus auffallen dürfen. 
Bin mal gespannt was da evtl. raus kommt.
Cheers
Claudia
Ich habe nur mal durchgeschaut ohne Ahnung zu haben.
Warnings empfande ich bis jetzt nicht immer super schlimm aber Warnungen sind Warnungen...
WARNING: CSkinInfo: failed to load skin settings
Das mag er nicht und taucht öfter mal auf
WARNING: No information found for item '/var/media/FILM/Akte X – Die unheimlichen Fälle des FBI/Akte X – Die unheimlichen Fälle des FBI-1.ts', it won't be added to the library.
Übrigens würde ich eigentlich Lieber Kodi 18 nutzen!?!?! Wusste garnicht, dass das als stable Version schon existiert?!
Tut es auch nicht. Kodi 18 ist ein sehr junges Alpha. Also bitte keine Wunder erwarten. Das ist gerade noch komplett in der Entwicklung.
Case closed
Hö? Ist dein Problem jetzt gelöst? Wenn ja, in wie fern? Klappt es mit der 18er Version? Wäre schön, wenn wir ein Feedback bekommen würden.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
