Login at Kodi Home

**garbear** · 2015-12-26, 15:05

Hope everyone had a good christmas Smile

if not, grab the builds I just uploaded and have fun!

BlueMSX has been fixed to not crash Kodi anymore. Also, some new button maps have been included for windows and linux.

steve1977 · 2015-12-26, 20:09

Not sure whether that's the best place to ask the question. Any thoughts whether Retroplayer may get merged into Kodi 17 alphas once they resume?

cmiller1 · 2015-12-26, 20:30

This kills support for the Apple IR Remotes! Maybe something in how it tries to implement controller support?

Jönke · 2015-12-26, 20:31

Any chance for a Rpi 2 test build with latest Openelec ?

longelf · 2015-12-26, 21:50

(2015-12-26, 20:30)cmiller1 Wrote: This kills support for the Apple IR Remotes! Maybe something in how it tries to implement controller support?

I've also found that since the new controller system, the Android remote control app Yatse no longer works. The buttons for 'Home'. 'TV', etc still work but navigation and volume controls don't function at all. The official Android remote, Kore, still works just fine.

I'm also having a lot of trouble with the controller config, just weird behaviour that I'm trying to get to the bottom of, see if I can find a pattern. I'm going to play with it for a while, see if I can work out exactly what's going on, then I'll post some questions. So far, I can use the controller until I try to configure it, then the buttons no longer do what they're supposed to. 'Left' will stop working, then start working again for no reason, so I get stuck at the System menu, but if I go into it I can't use 'Up' or 'Down'. If I quit and relaunch, functionality returns for a bit then randomly stops working again, without changing anything. I'm beginning to wonder if I have a dodgy controller, but it works fine on the XBox.

Windows 7 x64, running in portable mode, using an XBox 360 wireless controller.

**enen92** · 2015-12-27, 03:34

@garbear just fyi it seems there is a problem with the latest osx build...I think it is missing the emulators. The build from 23/12 works well. Size is different as well 150 mb vs 200 mb.

Cheers

GSP-UFC · (This post was last modified: 2015-12-27, 13:22 by GSP-UFC.)

(2015-12-27, 03:34)enen92 Wrote: @garbear just fyi it seems there is a problem with the latest osx build...I think it is missing the emulators. The build from 23/12 works well. Size is different as well 150 mb vs 200 mb.

Cheers

I'm having the same problem in windows keeps asking me to install emulators? or am i doing something wrong?

**Montellese** · 2015-12-27, 20:20

(2015-12-26, 21:50)longelf Wrote:
(2015-12-26, 20:30)cmiller1 Wrote: This kills support for the Apple IR Remotes! Maybe something in how it tries to implement controller support?

I've also found that since the new controller system, the Android remote control app Yatse no longer works. The buttons for 'Home'. 'TV', etc still work but navigation and volume controls don't function at all. The official Android remote, Kore, still works just fine.

Probably because they are using EventServer while Kore fully relies on JSON-RPC. But obviously EventServer should still work so this is a bug/regression.

**garbear** · 2015-12-27, 22:33

(2015-12-26, 20:09)steve1977 Wrote: Not sure whether that's the best place to ask the question. Any thoughts whether Retroplayer may get merged into Kodi 17 alphas once they resume?

I'm opening the PR for controller input next week. Input is about 60% of RetroPlayer now, so once that's in, RetroPlayer will be more merged than not Smile

(2015-12-26, 20:31)Jönke Wrote: Any chance for a Rpi 2 test build with latest Openelec ?

My build machine just got a new mobo, but it's having the same IO freezing problem, so maybe it's not the southbridge? I'll try running an RPi 2 build in the next week or two and see what happens.

(2015-12-27, 07:46)GSP-UFC Wrote:
(2015-12-27, 03:34)enen92 Wrote: @garbear just fyi it seems there is a problem with the latest osx build...I think it is missing the emulators. The build from 23/12 works well. Size is different as well 150 mb vs 200 mb.

I'm having the same problem in windows keeps asking me to install emulators? or am i doing something wrong?

I'll upload new builds tonight. Must have been a problem with Jenkins. I can build locally if needed.

(2015-12-27, 20:20)Montellese Wrote:
(2015-12-26, 21:50)longelf Wrote:
(2015-12-26, 20:30)cmiller1 Wrote: This kills support for the Apple IR Remotes! Maybe something in how it tries to implement controller support?

I've also found that since the new controller system, the Android remote control app Yatse no longer works. The buttons for 'Home'. 'TV', etc still work but navigation and volume controls don't function at all. The official Android remote, Kore, still works just fine.

Probably because they are using EventServer while Kore fully relies on JSON-RPC. But obviously EventServer should still work so this is a bug/regression.

Apparently EventServer relied on the old crappy joystick stuff for some functions. It'll have to be updated for the new API. This is a good thing, because it means any cell phone, remote or network device can be used as a controller in game. I'll put fixing EventServer on my list of things to do and add a note to KNOWN ISSUES.

charlie0440 · 2015-12-27, 22:36

@garbear

I compiled OpenElec with xbmc from your retroplayer-15.2 branch (commit 2b3807d), I wanted to try mupen64 so I compiled game.libretro.mupen64plus using https://github.com/a1rwulf/mupen64plus-libretro.git. This all compiled fine. When I launch an n64 rom from the IARL addon kodi starts to launch the emulator but then kodi restarts itself

crashlog: http://sprunge.us/QWAM

Any ideas?

**garbear** · 2015-12-27, 23:37

(2015-12-27, 22:36)charlie0440 Wrote: I compiled OpenElec with xbmc from your retroplayer-15.2 branch (commit 2b3807d), I wanted to try mupen64 so I compiled game.libretro.mupen64plus using https://github.com/a1rwulf/mupen64plus-libretro.git. This all compiled fine. When I launch an n64 rom from the IARL addon kodi starts to launch the emulator but then kodi restarts itself

crashlog: http://sprunge.us/QWAM

Any ideas?

In the log I see

Code:
Thread 1 (LWP 881):

#0  0x0000000000000000 in ?? ()

#1  0x00007f3542888645 in retro_run () from /usr/lib/kodi/addons/game.libretro.mupen64plus/game.libretro.mupen64plus.so

#2  0x0000000000a0c89a in GAME::CGameClient::RunFrame() ()

#3  0x0000000000958ec6 in CRetroPlayer::Process() ()

#4  0x0000000000dcfde5 in CThread::Action() ()

#5  0x0000000000dd054a in CThread::staticThread(void*) ()

#6  0x00007f35a8fb84a4 in ?? () from /lib/libpthread.so.0

#7  0x00007f35a59df4bd in clone () from /lib/libc.so.6

If you compile with make DEBUG=1 then we'll get symbols for the function that crashes.

Did you see the BlueMSX stuff a few days ago? Basically, what it comes down to, is that we're gonna have to load each misbehaving emulator in a debugger and figure out what libretro code works for RetroArch but crashes for other frontends.

**garbear** · 2015-12-28, 01:17

(2015-12-26, 21:50)longelf Wrote: I'm also having a lot of trouble with the controller config, just weird behaviour that I'm trying to get to the bottom of, see if I can find a pattern. I'm going to play with it for a while, see if I can work out exactly what's going on, then I'll post some questions. So far, I can use the controller until I try to configure it, then the buttons no longer do what they're supposed to. 'Left' will stop working, then start working again for no reason, so I get stuck at the System menu, but if I go into it I can't use 'Up' or 'Down'. If I quit and relaunch, functionality returns for a bit then randomly stops working again, without changing anything. I'm beginning to wonder if I have a dodgy controller, but it works fine on the XBox.

Windows 7 x64, running in portable mode, using an XBox 360 wireless controller.

This might be due to portable mode. Kodi ships with some button maps, and assumes that user button maps are stored in a different location, but when it's the same location the reads conflict with the writes. Can you remove all buttonmaps that ship with Kodi and try again?

longelf · (This post was last modified: 2015-12-28, 01:46 by longelf.)

(2015-12-28, 01:17)garbear Wrote: This might be due to portable mode. Kodi ships with some button maps, and assumes that user button maps are stored in a different location, but when it's the same location the reads conflict with the writes. Can you remove all buttonmaps that ship with Kodi and try again?

Yeah I wondered that too, but I got the same behaviour when I ran in standard mode. Curiously, when I initially installed your new controller build, it saw the controller but button presses did nothing. Once I configured it for 'Kodi' it seemed to work, until I then tried to configure for 'GBA'. As soon as I selected 'A', it flashed briefly then went straight to asking for input for 'B', whether I selected 'A' using the controller button or 'Enter' on the keyboard. From that point on, no matter what I tried, the controller and keyboard showed the same strange behaviour, defaulting to left if I tried to go right and only up and down working properly on the home screen. In System->Settings, up and down just flashed through the setting options really quickly and I could only go back. Restarting Kodi fixed it until I tried to configure the controller again.

Even more curiously, I can configure the controller for a system once. If I try to do another one without restarting Kodi, it goes back to doing what I described above. This is as close to a pattern I have managed to figure out.

Let me now what troubleshooting steps you would like to try and get to the bottom of it. It happens with your latest Windows build.

Just tried removing the standard Kodi keymaps, and got an error on launch 'unable to generate gui'. If I just remove keyboard.xml and joystick.xml, Kodi launches and I can run the controller config. When I configure it for 'Kodi' again, then go back to the home screen, up and down work fine, as do left and right in all but the main ribbon, where Kodi has 'System' selected and I cannot move it off that. Plus the gui is making an odd jerking movement when it is on the main ribbon. Restarting Kodi eliminates this behaviour and the controller is controlling Kodi just fine, until I run the config again.

charlie0440 · 2015-12-28, 02:13

(2015-12-27, 23:37)garbear Wrote: If you compile with make DEBUG=1 then we'll get symbols for the function that crashes.

Can you clarify what I should be compiling with this argument. I tried compiling OE and mupen64 with DEBUG=1 but the log looks no different > http://sprunge.us/cEBP
Do you mean kodi?

**a1rwulf** · (This post was last modified: 2015-12-28, 09:46 by a1rwulf.)

(2015-12-27, 23:37)garbear Wrote:
(2015-12-27, 22:36)charlie0440 Wrote: I compiled OpenElec with xbmc from your retroplayer-15.2 branch (commit 2b3807d), I wanted to try mupen64 so I compiled game.libretro.mupen64plus using https://github.com/a1rwulf/mupen64plus-libretro.git. This all compiled fine. When I launch an n64 rom from the IARL addon kodi starts to launch the emulator but then kodi restarts itself

crashlog: http://sprunge.us/QWAM

Any ideas?

In the log I see

Code:
Thread 1 (LWP 881): #0 0x0000000000000000 in ?? () #1 0x00007f3542888645 in retro_run () from /usr/lib/kodi/addons/game.libretro.mupen64plus/game.libretro.mupen64plus.so #2 0x0000000000a0c89a in GAME::CGameClient::RunFrame() () #3 0x0000000000958ec6 in CRetroPlayer::Process() () #4 0x0000000000dcfde5 in CThread::Action() () #5 0x0000000000dd054a in CThread::staticThread(void*) () #6 0x00007f35a8fb84a4 in ?? () from /lib/libpthread.so.0 #7 0x00007f35a59df4bd in clone () from /lib/libc.so.6

If you compile with make DEBUG=1 then we'll get symbols for the function that crashes.

Did you see the BlueMSX stuff a few days ago? Basically, what it comes down to, is that we're gonna have to load each misbehaving emulator in a debugger and figure out what libretro code works for RetroArch but crashes for other frontends.

The backtrace shows a call to a function at address 0x000000 which most likely is a function pointer that's set to NULL.
The problem is that https://github.com/garbear/xbmc/commits/...layer-15.2 is missing the libretro-gl stuff needed for mupen64.
@charlie0440: You need to either rebase https://github.com/garbear/xbmc/commits/retroplayer-gl on top of the current 15.2 branch or cherry-pick the top 6 commits of this branch.

EDIT: Please note that https://github.com/a1rwulf/mupen64plus-libretro.git is rather outdated. You could also try to compile mainstream to have a recent version. But I'm not sure if the input patches still apply (https://github.com/CharlieMarshall/OpenE...520cba4a09 ).