[Germeleon]

Dear Milhouse,d ear team,

I'm currently using #0505 and I can't update the built-in DB in the Amazon Prime Video-App.

When I'm clicking on "update movie and tv database" I'll receive a "Can't update DB, see logs" error message.

My debug Log looks as following (password: K0d1):

https://privatebin.net/?d35db69f321b9cd5#RtNwPnUipoEeBx168OI7D/ImakzKfec4LVGhFOPZpTQ=

It seems that there are still issues due to the python patches. Please fix this.

Kind Regards,

Germeleon.

[Klojum]

Dear Milhouse,d ear team,

First, that is not a complete kodi.log (we need FULL and unedited logs), and secondly, posting your log privately and posting the password on a public forum is a bit of a contradiction to me.

[Germeleon]

Sorry Klojum, you are right.

Here is my unedited kodi.log (password: K0d1).

https://privatebin.net/?18fd38b43e1cea18...Uf8UFk9Fg=

To sum up, here are my issues:

- Update of the Amazon Video App's DB not possible (see above)
- system-freeze while playing a video with Amazon VOD-App (test video: Prism Break, season 3, last episode)
- high CPU usage in Amazon VOD (~200 %, 2 of 4 cores are used, it seems that MMAL doesn't use hw acceleration, use of OMXPlayer is disabled in player settings. But it seems OMXPLayer is being used anyway?)

All issues above with current kodi-version #0505


Why I use privatebin.net

I like the idea that my logs are being deleted automatically after one week. This should be a good time space to analyze and resolve issues. Plus my logs are available for this forum only, and no crawler can download and parse them automatically (like seen with content on pastebin.net). It is a nice combination of privacy and problem solution for me.

[h3yn0w]

@h3yn0w

Hi,

had the same problem with every nightly since #422 but #505 is the first one which is doing its job again. I also think that it is due to the python-patches.

Thanks.

I’ve tried 505 , and unfortunately for me am still having issues with the python patches.

[mikeb8591]

More important than the remote is the IR receiver. Could you please post the output of "ir-keytable" and your kernel log ("dmesg | paste")?

so long,

Hias

0317 on the top, 0505 on the bottom

https://pastebin.com/4zJbw0j0

Thanks,
Mike

[HiassofT]

0317 on the top, 0505 on the bottom

https://pastebin.com/4zJbw0j0

Thanks, this seems to be the same receiver that caused issues here: https://forum.kodi.tv/showthread.php?tid...pid2727866

Could you run "ir-ctl -t 100000" on the current build (while kodi is running) and see if this fixes things? (sorry, just noticed a typo in my other post, it should be "ir-ctl -t ...", not "ir-keytable -t ...").

Then install build 0423, create a file .config/modprobe.d/ir-debugging.conf with the following content:

Code:

options rc_core dyndbg
options ir_rc6_decoder dyndbg
options mceusb dyndbg

Then reboot, stop kodi, run "ir-keytable -t" and press the OK button 2 times, with a few seconds in between.

Then please post the output you got from ir-keytable -t and your full (!) dmesg "dmesg | paste".

Now change the mceusb line in .config/modprobe.d/ir-debugging.conf so that it reads

Code:

options mceusb dyndbg fixed_timeout=1

then reboot, and do the same steps again.

After that your can remove the ir-debugging.conf modprobe file

so long,

Hias

[mikeb8591]

0317 on the top, 0505 on the bottom

https://pastebin.com/4zJbw0j0

Thanks, this seems to be the same receiver that caused issues here: https://forum.kodi.tv/showthread.php?tid...pid2727866

Could you run "ir-ctl -t 100000" on the current build (while kodi is running) and see if this fixes things? (sorry, just noticed a typo in my other post, it should be "ir-ctl -t ...", not "ir-keytable -t ...").

Yes, running 'ir-ctl -t 100000' does seem to fix it.

Then install build 0423, create a file .config/modprobe.d/ir-debugging.conf with the following content:

Code:

options rc_core dyndbg
options ir_rc6_decoder dyndbg
options mceusb dyndbg

Then reboot, stop kodi, run "ir-keytable -t" and press the OK button 2 times, with a few seconds in between.

Then please post the output you got from ir-keytable -t and your full (!) dmesg "dmesg | paste".

dmesg is here: http://ix.io/19zz there was no output from ir-keytable -t

Code:

livingroom:~ # systemctl stop kodi
livingroom:~ # ir-keytable -t
Testing events. Please, press CTRL-C to abort.
^C
livingroom:~ # dmesg | paste
http://ix.io/19zz

Now change the mceusb line in .config/modprobe.d/ir-debugging.conf so that it reads

Code:

options mceusb dyndbg fixed_timeout=1

then reboot, and do the same steps again.

dmesg: http://ix.io/19zB

still no output on ir-keytable -t

After that your can remove the ir-debugging.conf modprobe file

so long,

Hias

[HiassofT]

Yes, running 'ir-ctl -t 100000' does seem to fix it.

Ah, good to know, you can use that as a temporary workaround (eg add it to .config/autostart.sh) until the underlying issue is resolved.

But first I'd like you to redo the tests. Sorry, forgot to mention that you also need to stop eventlircd (therefore you got no output from ir-keytable -t) and unfortunately the dmesg was cut down - we probably need to increase the kernel log buffer.

First add "log_buf_len=10M" to the end of /flash/cmdline.txt. It should then look like this:

Code:

boot=/dev/mmcblk0p1 disk=/dev/mmcblk0p2 quiet log_buf_len=10M

Then setup .config/modprobe.d/ir-debugging.conf as before, reboot into build 0423, stop kodi and eventlircd and check with ir-keytable -t. But now only press the OK button once for about 0.2-0.5 seconds on each of the tests (this should reduce the amount of log generated).

Instead of uploading dmesg to a paste site store it in local files, eg "dmesg > dmesg-test1" and then ZIP up both logfiles and upload them to dropbox or something similar. The ZIPs shouldn't be too big, but the uncompressed logs could be too large for paste sites.

In addition to that I'd like you to check another thing with build 0423: create ir-debugging.conf with the following content:

Code:

options rc_core keyup_margin=20

Then reboot and check if the remote operates as normal. Also try a bit smaller values (eg 10 instead of 20) and larger ones (up to about 30-50). Finding out if that helps and if yes what the minimum value is could provide some more info to create a fix. You have to reboot after each change so the new settings take effect.

so long,

Hias

[aleksobs]

Help, please fix it!

The missing fanart while navigating Files is being worked on.

God knows how you'll react when something critical is broken.... ;-) 

 Hi! I tested build 0505 the error is still present. FANART is not visible.

[arpharazonn]

Hi, first of all thanks you for the great work!

My raspberry pi restart itself when starting. I see kodi logo on screen and restarting... Its try 3 times and safe kodi opening (the red one). I tried stock config.txt, updating 2 times but no luck.

Here my crash log: http://ix.io/19AZ

I need your help,  thank you!

[mikeb8591]

Ah, good to know, you can use that as a temporary workaround (eg add it to .config/autostart.sh) until the underlying issue is resolved.

0505 seemed unstable for me, probably for other reasons.

But first I'd like you to redo the tests. Sorry, forgot to mention that you also need to stop eventlircd (therefore you got no output from ir-keytable -t) and unfortunately the dmesg was cut down - we probably need to increase the kernel log buffer.

stopping eventlircd didn't seem to have any affect:

test-1
LibreELEC (community): devel-20180424011910-#0423-g6ce3be6 (RPi2.arm)
livingroom:~ # systemctl stop kodi
livingroom:~ # systemctl stop eventlircd
livingroom:~ # ir-keytable -t
Testing events. Please, press CTRL-C to abort.
^C
livingroom:~ #

test-2
LibreELEC (community): devel-20180424011910-#0423-g6ce3be6 (RPi2.arm)
livingroom:~ # systemctl stop kodi
livingroom:~ # systemctl stop eventlircd
livingroom:~ # ir-keytable -t
Testing events. Please, press CTRL-C to abort.
^C
livingroom:~ #

Instead of uploading dmesg to a paste site store it in local files, eg "dmesg > dmesg-test1" and then ZIP up both logfiles and upload them to dropbox or something similar. The ZIPs shouldn't be too big, but the uncompressed logs could be too large for paste sites.

larger-buffer dmesg files are here:

http://www.awen.com/~mburgett/kodi/ir-de...-test-1.gz
http://www.awen.com/~mburgett/kodi/ir-de...-test-2.gz

In addition to that I'd like you to check another thing with build 0423: create ir-debugging.conf with the following content:

Code:

options rc_core keyup_margin=20

Then reboot and check if the remote operates as normal. Also try a bit smaller values (eg 10 instead of 20) and larger ones (up to about 30-50). Finding out if that helps and if yes what the minimum value is could provide some more info to create a fix. You have to reboot after each change so the new settings take effect.

relative to no ir-debugging.conf behavior:

10 - a bit worse.
20 - about the same
30 - about the same
40 - about the same
50 - substantially worse.

Thanks,
Mike

[Jagr CZ]

It is possible to add bluetooth to receive using the GUI menu (Bluetooth setting).  Receiving bluetooth audio from a smart phone.
Thanks.

[HiassofT]

http://www.awen.com/~mburgett/kodi/ir-de...-test-1.gz
http://www.awen.com/~mburgett/kodi/ir-de...-test-2.gz

Hmmm, these logs look like you had bad IR reception, none of the IR signals could be decoded properly. The previous dmesg showed proper IR receptionand decoded signals.

Could you test a bit more with the second variant (the one that has fixed_timeout=1 in ir-debugging.conf) on build 0423? That should behave exactly like build 0417, i.e. without the mceusb patches.

Just test this with kodi, watch if the button presses are as you expect, make sure the battery is fully charged and you point the remote straight to the IR receiver.

If you change ir-debugging.conf it's also a good idea to fully power off your RPi so that the receiver is in "cold state" - USB commands to change the IR timeout behaviour might persist across reboots.

Once you got proper button presses in Kodi please redo the tests (this time powering off instead of just rebooting).

The ir-keytable -t output from your very first log is a bit odd, this can also happen if the a button is bouncing / worn out. Would be good if we could rule that out with proper, full logs.

so long,

Hias

[Milhouse]

New LibreELEC.tv Leia build #0506: RPi / RPi2
(Supercedes previous build)

SHA256 Checksum: ddfc14c767ba4a346b597895c511169db9bc67f9c5ddb56a7ed0c10f8a729581 (RPi)
SHA256 Checksum: 9163010da28c2608db3cf71f9552f0e1daafdf9db83f6a0d5f765987249681ab (RPi2)

text:
# uname -a

Linux rpi512 4.14.39 #1 Sun May 6 21:04:46 BST 2018 armv6l GNU/Linux



# vcgencmd version

Apr 26 2018 23:18:12 

Copyright © 2012 Broadcom

version 90a06d6c6299583cfbf40033bbf895a45920fa71 (clean) (release)



# lsb_release

LibreELEC (Milhouse): devel-20180506210251-#0506-g8463ee0 [Build #0506]



# Kodi version

(18.0-ALPHA2 Git:eb1e22e). Platform: Linux ARM 32-bit

Based on tip of LibreELEC.tv master (8463ee0, changelog) and tip of XBMC master (8257c47, changelog) with the following modifications:

• Includes newclock5 patches
  
• Includes latest bcm2835-driver master (287af2a)
  
• Includes latest kodi-platform master (e8574b8)
  
• Includes latest libcec master (8adc786, ahead +26)
  
• Includes latest libnfs master (6a33413, ahead +132)
  
• Includes latest p8-platform master (a822e19)
  
• Includes latest addons: inputstream.adaptive (0f0ced4), inputstream.rtmp (8920456, +1), peripheral.joystick (80224e1), pvr.argustv (377f796), pvr.demo (d5e5cd1), pvr.dvblink (c61ea73), pvr.dvbviewer (098d23c), pvr.filmon (0ca1665), pvr.hdhomerun (484b91d), pvr.hts (9533cce), pvr.iptvsimple (77156cb), pvr.mediaportal.tvserver (9702684), pvr.mythtv (9d15025), pvr.nextpvr (de30ff2), pvr.njoy (bd6581f), pvr.octonet (54680a3), pvr.pctv (5e95300), pvr.stalker (da6f0f8), pvr.teleboy (dbdc96e, +3), pvr.vbox (3cf15ad), pvr.vdr.vnsi (d6fe796), pvr.vuplus (00a963f), pvr.wmc (2acca13), pvr.zattoo (1244e14), vfs.libarchive (1b00b57, +1)
  
• Exclude [env] kodi-0100-temp-add-pr13594.patch: merged upstream
  
• Include [env] compare (perma): dmidecode: initial package
  
• Include [env] patch: RPi/RPi2: enable Broadcom WiFi debugging (see details)
  
• Include [env] patch: libcec: fix PR390
  
• Include [env] patch: libcec: don't link non-existant libtinfo
  
• Include [env] patch: rev hack for kodi
  
• Include [env] patch: HACK: Disable multiple PVR addons during migration. Always enable inputstream.* and os.*
  
• Include [env] patch: Add experimental splash video for RPi
  
• Include [env] patch: Bump included addon versions to prevent online updates
  
• Include [env] patch: Add kodi binary addons (pvr, adsp, inputstream, vfs, other)
  
• Include [env] PR:2449 (perma): Adding support for AMD GPUs
  
• Include [env] PR:2677 (perma): qemu: update to 2.12.0
  
• Include [env] PR:2679 (perma): eventlircd: don't grab power buttons
  
• Include [env] PR:2680 (perma): kodi: mid-May 2018
  
• Include [env] PR:2682 (perma): linux: update to linux-4.14.39
  
• Include [pkg] patch: skin.estuary: reduce system info font size (kodi)
  
• Include [pkg] PR:13814 (perma): Reusepython
  
• Include [pkg] PR:13854 (perma): [music]Fix fanart for library items on playback from file view
  

Build Highlights:

1. Rebase revert that causes OMX stutter
   

Build Details:

1. XBMC:
   • VAAPI: add vp8 support (PR:13843, 2 commits, 5 files changed)
     
   • VideoPlayer: VAAPI - enter idle state after flush (PR:13857, 1 commit, 1 file changed)
     
2. newclock5:
   • New commits in this build:
     • Revert "VideoPlayer: flush renderManager when hiding video" (6f9d5dc2)
       
     • Revert "VideoPlayer: no preinit if already configured" (781657b1)
       
   • Updated commits in this build:
     • Revert "VideoPlayer: do not render video until a/v streams are in sync" (f227d4cd => 9d919b65)
       

[mikeb8591]

[ ... ]
Once you got proper button presses in Kodi please redo the tests (this time powering off instead of just rebooting).

The ir-keytable -t output from your very first log is a bit odd, this can also happen if the a button is bouncing / worn out. Would be good if we could rule that out with proper, full logs.

Ok, the results of all the tests are here. It should be noted that I also see occasional, seemingly random key activity several seconds after I've stopped my keypress. Some of these are captured in the .txt file, inside this .zip. Each test captures one "normal" press of the OK button.

I also observed that the red led on the IR receiver is basically on solid for the duration of my keypress in the fixed_timeout=1 case (and with 0417 and earlier) but flashes rapidly in all the other test scenarios.

http://www.awen.com/~mburgett/kodi/ir-de..._tests.zip

This remote has performed flawlessly up til now, and indeed still works flawlessly with 0417 and earlier builds, so I'm not inclined to agree that I have worn out buttons.