[zaphod24]

Which pvr client are you using? I'm using mythtv. I have 2 rpi3 devices and both had the issue with nothing under default or livetv on 0825 but after reverting to 0824 recordings are accessible again.

[f1vefour]

Which pvr client are you using? I'm using mythtv. I have 2 rpi3 devices and both had the issue with nothing under default or livetv on 0825 but after reverting to 0824 recordings are accessible again.

If mythtv is on a different device try restarting it, I had this issue with tvheadend and it resolved it.

According to reverting builds it may be unlikely.

[mark_dj]

It's set to expert, but I can't change the size there, only the position?

Make sure you're testing with Estuary. What are you seeing if it's not the same as below?

Thanks for that, the skin didn't show these settings so it's fixed now. Took me WAY longer than expected though

Also, Dead Poets Society (the movie) doesn't seem to work on Kodi. I've tested it with multiple versions of both Kodi and the movie but nothing is shown when I start the movie. Has anyone ever heard of this problem?

[Milhouse]

Thanks for that, the skin didn't show these settings so it's fixed now. Took me WAY longer than expected though

If you're using a third-party skin that's your choice, but you shouldn't be reporting issues with third party skins in this thread. Only report issues you can reproduce with stock Estuary.

Also, Dead Poets Society (the movie) doesn't seem to work on Kodi. I've tested it with multiple versions of both Kodi and the movie but nothing is shown when I start the movie. Has anyone ever heard of this problem?

Nope. Post a debug log (wiki) of you trying to pay this movie.

[Saner]

It's worth trying to turn off h/w decoding and try it.

I had a couple that refused to pay video, that kicked it

[mark_dj]

Thanks for that, the skin didn't show these settings so it's fixed now. Took me WAY longer than expected though

If you're using a third-party skin that's your choice, but you shouldn't be reporting issues with third party skins in this thread. Only report issues you can reproduce with stock Estuary.

Also, Dead Poets Society (the movie) doesn't seem to work on Kodi. I've tested it with multiple versions of both Kodi and the movie but nothing is shown when I start the movie. Has anyone ever heard of this problem?

Nope. Post a debug log (wiki) of you trying to pay this movie.

I did actually try and look for it with the stock Estuary skin, but was unable to find it (hence my 6 hour search). I guess switching to the skins back and forth somehow reset (some of) my settings.

It's worth trying to turn off h/w decoding and try it.

I had a couple that refused to pay video, that kicked it

Thanks, gonna give that a spin

[BigNoid]

Here's my crashlog with the debug build. It started with #822 and the crashes only occur when the Xbox 360 controller is plugged in.

[zaphod24]

Which pvr client are you using? I'm using mythtv. I have 2 rpi3 devices and both had the issue with nothing under default or livetv on 0825 but after reverting to 0824 recordings are accessible again.

If mythtv is on a different device try restarting it, I had this issue with tvheadend and it resolved it.

According to reverting builds it may be unlikely.

Looks like Milhouse was kind enough to report the issue with PR 10333 and it looks like that PR introduced a regression which someone has already corrected. Thanks to Milhouse for reporting!

[popcornmix]

Here's my crashlog with the debug build. It started with #822 and the crashes only occur when the Xbox 360 controller is plugged in.

This backtrace looks screwy to me:

Code:

Thread 1 (Thread 0x592ff3a0 (LWP 12790)):
#0  NPT_BsdSocket::RefreshInfo (this=this@entry=0x0) at Neptune/Source/System/Bsd/NptBsdSockets.cpp:1334
#1  0x0082da4c in NPT_BsdTcpClientSocket::WaitForConnection (this=0x0, timeout=<optimized out>) at Neptune/Source/System/Bsd/NptBsdSockets.cpp:1998
#2  0x0082d9a0 in NPT_BsdTcpClientSocket::Connect (this=0x745b7450, address=..., timeout=60000) at Neptune/Source/System/Bsd/NptBsdSockets.cpp:1983
#3  0x008290e4 in NPT_HttpTlsConnector::Connect (this=<optimized out>, url=..., client=..., proxy=proxy@entry=0xde553d, reuse=reuse@entry=true, connection=@0x592febec: 0x0) at Neptune/Source/Core/NptTls.cpp:1134
#4  0x008205c8 in NPT_HttpClient::SendRequestOnce (this=this@entry=0x7201d968, request=..., response=@0x14bb66c: 0x0, context=0x592fed08, context@entry=0x0) at Neptune/Source/Core/NptHttp.cpp:1707
#5  0x00821264 in NPT_HttpClient::SendRequest (this=this@entry=0x7201d968, request=..., response=@0x592fecdc: 0x0, context=0x0, context@entry=0x592fed08) at Neptune/Source/Core/NptHttp.cpp:2047
#6  0x0084af54 in PLT_HttpClientSocketTask::DoRun (this=0x7201d940) at Platinum/Source/Core/PltHttpClientTask.cpp:125
#7  0x0083c6c8 in PLT_ThreadTask::Run (this=0x7201d940) at Platinum/Source/Core/PltThreadTask.cpp:179
#8  0x0082f154 in NPT_PosixThread::EntryPoint (argument=0x72013260) at Neptune/Source/System/Posix/NptPosixThreads.cpp:481
#9  0x76d5ded0 in start_thread (arg=0x592ff3a0) at pthread_create.c:335
#10 0x751a2390 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:89 from /lib/libc.so.6

Thread 1 should contain the main Application thread. Not a load of socket stuff. Milhouse - might this backtrace have been broken by one of the bumps?
binutils? Anything else compiler / system libs / gdb related?

[Milhouse]

Milhouse - might this backtrace have been broken by one of the bumps?
binutils? Anything else compiler / system libs / gdb related?

No, #0824 and #0825x are both clean builds, with no package bumps other than those documented. I've been testing the binutils/gcc/etc. package bumps in a different repo that is completely separate from the repo I use for these builds (they don't even share ccache).

BigNoid says this started with #0822, can it just be a coincidence that there is a controller related PR in #0822? I could try reverting it, and BigNoid can tell if it has any effect.

[Milhouse]

@BigNoid can you try debug-enabled build #0826x: RPi2

It's basically #0825x with the following changes reverted:

1. XBMC:
   • Bump peripheral API - enable translating between controller profiles (PR:10299, 3 commits, 9 files changed)
     
2. peripheral.joystick:
   • [udev] Add udev implementation (PR:46, 1 commit, 9 files changed)
     
   • v1.2.0: Controller translation and udev support from RetroPlayer branch (PR:47, 29 commits, 59 files changed)
     
   • [addon.xml] Bump peripheral API to v1.0.22 (missed in b15053e) (56e322ca)
     
   • [addon.xml] Bump version to v1.2.0 for controller translation and udev suppport (2a69ba41)
     

While I don't understand the backtrace either, I also have no reason to suspect it is wrong (as in bad build) at this stage. The fact that the crash only happens when a controller is connected makes me suspect the controller-related changes, particularly as they were added in the first build that has this problem. Perhaps there is some threading/corruption issue occurring?

There's a peripheral.joystick update that will be in tonight's build, but I wouldn't have thought it will have any effect on this issue (though looking at that backtrace, who knows anymore...)

[BigNoid]

Installing now, thx.

[popcornmix]

No, #0824 and #0825x are both clean builds, with no package bumps other than those documented. I've been testing the binutils/gcc/etc. package bumps in a different repo that is completely separate from the repo I use for these builds (they don't even share ccache).

BigNoid says this started with #0822, can it just be a coincidence that there is a controller related PR in #0822? I could try reverting it, and BigNoid can tell if it has any effect.

My belief is that the joystick bump has caused the SIGSEGV crash and that started in #0822.
But I believe a separate regression has broken backtrace. That may have occurred in any build since backtraces were last seen working (possibly a couple of weeks or more back).
The backtrace Bignoid reported is not plausible. The symbols are unrelated to the code that has been running as so backtrace is useless.

[popcornmix]

Just to clarify, a working backtrace for Application thread (thread 1) should always look like:

Code:

Thread 1
...
#28 0x007e81c8 in CXBApplicationEx::Run() ()
#29 0x00669320 in XBMC_Run ()
#30 0x00357c34 in main ()

Anything else is garbage.

[Milhouse]

This is a crashlog from #0825x that I forced with "kill -SIGSEGV $(pidof kodi.bin)" - looks fairly normal to me...

http://sprunge.us/TJYS

Would it be possible for a process/thread to corrupt the call stack?

@BigNoid can you try the "kill -SIGSEGV" command on #0825x with and without the controller connected to see if there's any difference in the resulting crashlogs?