[Milhouse]

There is "virtual suspend" built into these builds - all it does is remove power to the HDMI which allows the connected display device to enter eco mode. There is no suspend-to-RAM as you probably have with the Chromebox, so resuming from "suspend" should work reliably with the RPi.

[bill_orange]

I just noticed a problem with PICTURES. At least build #0503 and #0504 are affected. The same operation on the same collection works in 6.0.3.

Attempting a recursive randomized slideshow on a large picture collection containing mixed file formats results in either no show and high CPU activity or a spontaneous reboot. No slide show appears in either outcome. I suspect that this is a ffmpeg issue. The collection that fails is 77G in size and contains a variety of picture formats.

Here's the log.

http://xbmclogs.com/pnbhbhilw

[Milhouse]

At least build #0503 and #0504 are affected. The same operation on the same collection works in 6.0.3.

Be nice to know which build it started with - there's a lot of builds between 6.0.3 and #0504.

Attempting a recursive randomized slideshow on a large picture collection containing mixed file formats results in either no show and high CPU activity or a spontaneous reboot. No slide show appears in either outcome. I suspect that this is a ffmpeg issue. The collection that fails is 77G in size and contains a variety of picture formats.

Do you really mean reboot, or it is Kodi that restarts? If the latter, you'll have a crashlog (see note #4, first post).

[popcornmix]

I just noticed a problem with PICTURES. At least build #0503 and #0504 are affected. The same operation on the same collection works in 6.0.3.

Try disabling "show exif picture information" in library/pictures settings.

Basically it's a known issue with kodi and a large numbers of photos - you'll run out of memory. See:
http://forum.kodi.tv/showthread.php?tid=261384

[bill_orange]

At least build #0503 and #0504 are affected. The same operation on the same collection works in 6.0.3.

Be nice to know which build it started with - there's a lot of builds between 6.0.3 and #0504.

Attempting a recursive randomized slideshow on a large picture collection containing mixed file formats results in either no show and high CPU activity or a spontaneous reboot. No slide show appears in either outcome. I suspect that this is a ffmpeg issue. The collection that fails is 77G in size and contains a variety of picture formats.

Do you really mean reboot, or it is Kodi that restarts? If the latter, you'll have a crashlog (see note #4, first post).

I guess that I do mean reboot. I looked for a crashlog and none was present. I will try to home in on the build. I am using berryboot so jumping between versions is difficult.

[popcornmix]

I guess that I do mean reboot. I looked for a crashlog and none was present. I will try to home in on the build. I am using berryboot so jumping between versions is difficult.

Simple way to be sure. ssh in before the crash/reboot.
If ssh connection is still active after the crash/reboot it wasn't a reboot.

It's unlikely to be a reboot - that usually only occurs with a very inadequate power supply.

[bill_orange]

I guess that I do mean reboot. I looked for a crashlog and none was present. I will try to home in on the build. I am using berryboot so jumping between versions is difficult.

Simple way to be sure. ssh in before the crash/reboot.
If ssh connection is still active after the crash/reboot it wasn't a reboot.

It's unlikely to be a reboot - that usually only occurs with a very inadequate power supply.

I stand corrected. I opened an SSH connection and attempted the slideshow and got a restart / reboot. Since the SSH connection was retained, it must be a restart. No crashlog, however. I was, however, able to get a log file which includes the crash. Maybe that will help.

http://xbmclogs.com/pz8q9wjhg

[bill_orange]

I just noticed a problem with PICTURES. At least build #0503 and #0504 are affected. The same operation on the same collection works in 6.0.3.

Try disabling "show exif picture information" in library/pictures settings.

Basically it's a known issue with kodi and a large numbers of photos - you'll run out of memory. See:
http://forum.kodi.tv/showthread.php?tid=261384

No change in behavior with the EXIF setting off. Good thought though.

[bill_orange]

I guess that I do mean reboot. I looked for a crashlog and none was present. I will try to home in on the build. I am using berryboot so jumping between versions is difficult.

Simple way to be sure. ssh in before the crash/reboot.
If ssh connection is still active after the crash/reboot it wasn't a reboot.

It's unlikely to be a reboot - that usually only occurs with a very inadequate power supply.

I stand corrected. I opened an SSH connection and attempted the slideshow and got a restart / reboot. Since the SSH connection was retained, it must be a restart. No crashlog, however. I was, however, able to get a log file which includes the crash. Maybe that will help.

http://xbmclogs.com/pz8q9wjhg

This log file might be better. I am not sure if the first one captured the crash.

https://onedrive.live.com/redir?resid=F1...file%2clog

[Milhouse]

Here it is: http://xbmclogs.com/pquz55osi

Same behavior with #0423 and #0424

Thank you.

So quasar works with #0420 but not #0423 or #0424. Strange. The only obvious change in #0423 is the libressl change, possibly connman 1.32, but the quasar query isn't https, at least not to the local trakt server.

Quasar does however appear to be crashing due to an invalid/unexpected response from the local trakt server - maybe trakt is having a problem authenticating remotely? I think you need to get the log from the trakt server (if there is such a log), or speak with a trakt/quasar developer (pinging @Razze for trakt).

I've followed the steps in http://forum.kodi.tv/showthread.php?tid=...pid2321749 and with build LE #0401 I get the authorisation code. Great.

I also get the authorisation code by clicking "Addons" > "Settings" (context menu) > "Advanced" > "Authorize Quasar", and that's my current "test method".

Starting with build LE #0408 I get an HTTP Error. I get this error with all builds after #0408, including #0420.

Build LE #0408 is the first with PR:128 so unfortunately this looks like another certificate issue.

To see the issue, in LE #0407:

Code:

rpi22:~ # curl -v http://localhost:65251/trakt/authorize
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 65251 (#0)
> GET /trakt/authorize HTTP/1.1
> Host: localhost:65251
> User-Agent: curl/7.48.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/plain; charset=utf-8
< Date: Thu, 05 May 2016 17:57:27 GMT
< Content-Length: 0
<
* Connection #0 to host localhost left intact

but in LE #0408 there is an "internal server error":

Code:

rpi22:~ # curl -v http://localhost:65251/trakt/authorize
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 65251 (#0)
> GET /trakt/authorize HTTP/1.1
> Host: localhost:65251
> User-Agent: curl/7.48.0
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Date: Thu, 05 May 2016 17:54:53 GMT
< Content-Length: 0
< Content-Type: text/plain; charset=utf-8
<
* Connection #0 to host localhost left intact

Since Quasar is shipped with a pre-compiled binary it's not possible to tell what it's doing (maybe the code is on Github or Sourceforge, not looked) but it doesn't seem to like the CA bundle that is shipped with LibreELEC.

The nearest I can come to determining what Quasar is doing is that if I recreate "/etc/pki/tls/cacert.pem" (which is no longer present after PR:128) then Quasar works again even in the latest builds, so it would seem that Quasar has some hard dependency on /etc/pki/tls/cacert.pem (which is just a sym link to /etc/ssl/cacert.pem)

I've had a quick word with the LE team and we'll add back the "/etc/pki/tls/cacert.pm" sym link in tonight's build.

[Kiralina]

Here it is: http://xbmclogs.com/pquz55osi

Same behavior with #0423 and #0424

Thank you.

So quasar works with #0420 but not #0423 or #0424. Strange. The only obvious change in #0423 is the libressl change, possibly connman 1.32, but the quasar query isn't https, at least not to the local trakt server.

Quasar does however appear to be crashing due to an invalid/unexpected response from the local trakt server - maybe trakt is having a problem authenticating remotely? I think you need to get the log from the trakt server (if there is such a log), or speak with a trakt/quasar developer (pinging @Razze for trakt).

I've followed the steps in http://forum.kodi.tv/showthread.php?tid=...pid2321749 and with build LE #0401 I get the authorisation code. Great.

I also get the authorisation code by clicking "Addons" > "Settings" (context menu) > "Advanced" > "Authorize Quasar", and that's my current "test method".

Starting with build LE #0408 I get an HTTP Error. I get this error with all builds after #0408, including #0420.

Build LE #0408 is the first with PR:128 so unfortunately this looks like another certificate issue.

To see the issue, in LE #0407:

Code:

rpi22:~ # curl -v http://localhost:65251/trakt/authorize
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 65251 (#0)
> GET /trakt/authorize HTTP/1.1
> Host: localhost:65251
> User-Agent: curl/7.48.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/plain; charset=utf-8
< Date: Thu, 05 May 2016 17:57:27 GMT
< Content-Length: 0
<
* Connection #0 to host localhost left intact

but in LE #0408 there is an "internal server error":

Code:

rpi22:~ # curl -v http://localhost:65251/trakt/authorize
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 65251 (#0)
> GET /trakt/authorize HTTP/1.1
> Host: localhost:65251
> User-Agent: curl/7.48.0
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Date: Thu, 05 May 2016 17:54:53 GMT
< Content-Length: 0
< Content-Type: text/plain; charset=utf-8
<
* Connection #0 to host localhost left intact

Since Quasar is shipped with a pre-compiled binary it's not possible to tell what it's doing (maybe the code is on Github or Sourceforge, not looked) but it doesn't seem to like the CA bundle that is shipped with LibreELEC.

The nearest I can come to determining what Quasar is doing is that if I recreate "/etc/pki/tls/cacert.pem" (which is no longer present after PR:128) then Quasar works again even in the latest builds, so it would seem that Quasar has some hard dependency on /etc/pki/tls/cacert.pem (which is just a sym link to /etc/ssl/cacert.pem)

I've had a quick word with the LE team and we'll add back the "/etc/pki/tls/cacert.pm" sym link in tonight's build.

Thank you for looking into it.

This is only the trakt problem, but in the May buids, starting with #0501 it occurs also a second problem. Quasar finds the links (can't say more), but it doesn't download any thing. Kodi blocks when I try to start a download. It needs a hard reboot. This is the log http://xbmclogs.com/pggc3jcu2

Currently I'm using build #0429b where the download works, but trakt integration doesn't (not a huge problem for me)

I hope this helps a little.

[david1976aus]

Try disabling some of the add-ons you are running at startup, ie. xbmcbackup, watchedlist, libraryautoupdate, chechpreviousepisode. Starting with a "clean" .kodi would confirm this is a problem caused by a third-party add-on.

I have uploaded a clean log to http://xbmclogs.com/puseenaie

And still the same problem? How long is the splash remaining on screen? This isn't really what I'd call a "clean" Kodi - you've still got a bunch of third party add-ons installed - I see a ZipManager error from xbmcbackup that could be causing a problem. Rename the .kodi folder and try again. Do you have the same problem with a release build (LE7)?

I have started a fresh and the delay seems to have disappeared completely now. However I am noticing that I am seeing videos freeze and hang in the middle of playback.

What can you suggest to diagnose that? as it seems to happen on a variety of video files

[Milhouse]

What can you suggest to diagnose that? as it seems to happen on a variety of video files

A debug log, as usual.

[bill_orange]

At least build #0503 and #0504 are affected. The same operation on the same collection works in 6.0.3.

Be nice to know which build it started with - there's a lot of builds between 6.0.3 and #0504.

Attempting a recursive randomized slideshow on a large picture collection containing mixed file formats results in either no show and high CPU activity or a spontaneous reboot. No slide show appears in either outcome. I suspect that this is a ffmpeg issue. The collection that fails is 77G in size and contains a variety of picture formats.

Do you really mean reboot, or it is Kodi that restarts? If the latter, you'll have a crashlog (see note #4, first post).

Regarding which build did this start with #501-2015 works fine. Build #1101 does not. That narrows it down a fit, anyway.

[Milhouse]

Thank you for looking into it.

This is only the trakt problem, but in the May buids, starting with #0501 it occurs also a second problem. Quasar finds the links (can't say more), but it doesn't download any thing. Kodi blocks when I try to start a download. It needs a hard reboot. This is the log http://xbmclogs.com/pggc3jcu2

Currently I'm using build #0429b where the download works, but trakt integration doesn't (not a huge problem for me)

I hope this helps a little.

Sounds like the same deadlock problem reported here when using the YouTube search: http://forum.kodi.tv/showthread.php?tid=...pid2328176