Posts by escalade

I'm on a Haswell NUC and haven't seen stuttering since the Frodo days, so this is definitely not a general Intel problem. I have "sync playback to display" off.

pawnthep

Sawasdee krap to you, and of course it's possible! When you run Chrome in this build, you're basically running it in a minimal Arch installation inside a Docker container. The image used for that is pulled from my Docker hub repo, I've updated it now to include Thai fonts as well. You'll need to run this command in an SSH session:

# docker pull escalade1/arch-chrome

The next time you launch Chrome, you should be all set

lefty420

You're welcome, I'm a big Nintendo fan as well but from the GB/NES/SNES era Unfortunately for me Dolphin requires a very fast CPU, my i5 NUC wasn't able to run F-Zero but at least I can run Mario Kart smoothly.

I've uploaded a 20160816-2 build with the following changes:

- Two GC controllers pre-configured for DS4 via Bluetooth
- You can now run dolphin.sh without any arguments in SSH to bring up the GUI
- Removed the annoying error box about system language when starting up the GUI version

I don't know any programming languages either, this is all scripting and packaging. I've been using Linux since around 1995 though, and at that time if you wanted to do anything useful you'd need to compile some stuff and read manuals. Lots and lots of manuals. Because no google and no damn internet These days people tend to give up if there isn't a youtube video lol

New build 20160816:

- Added Dolphin
- Added nxengine-libretro
- Added unclutter (hides inactive mouse cursor when starting Emulationstation)
- Docker 1.12.1-rc1

Notes on Dolphin.

Put your roms in /storage/roms/wii and /storage/roms/gamecube. If you are upgrading from a different build, remove /storage/.config/emulationstation/es_systems.cfg and reboot. This will ensure that Emulationstation is set up to launch Dolphin properly.

Now back to playing Mario Kart Double Dash

It turns out packaging Dolphin was easier than expected. It's buildsystem fetches and builds most of the dependencies by itself and links them statically to the binary. The only packages that needed packaging was portaudio (needed for mic support) and openal-soft (i think you can probably build without it). The rest was already in LibreELEC or available in the package tree.

You can find my package here. It can easily be turned into an addon, all it needs is an addon() function to populate the addon with the additional libraries, binaries and the resources Kodi needs to launch it.

Looking at the dependencies it requires enet, libao, openal, soundtouch and wxgtk all of which are not currently packaged. Those packages likely have other dependencies as well. And then it uses cmake which can be challenging. Since there is no source available, I'm guessing that he simply zipped up all the binaries and libraries from some other distribution like many others have done when creating addons.

I've been thinking about creating a small tutorial with the basics, but every time I think about what to put in it I think the same thing as chewitt. Learning the basics is easy and fast by looking at other addons. However, you won't get very far with the basics. A lot of packages require patching to be able to cross compile correctly. You'll need to learn what autoconf is, how the cross compiling toolchain is set up, and what a makefile does. That means spending hours upon hours trying and failing until you get it working.

Ah, I stand corrected. The binary name is originally pastebinit, but I can see that the busybox package symlinks it to paste indeed

chewitt

It's pastebinit

BlockABoots

Doesn't seem to crash here.

jaykass

Nothing I can do about Kodi bugs.

Here's how I do it by editing the Estuary skin.

That's odd, worked on my rpi3

You can run the previous alpha on it until the new patch is sorted out. I'm already on the latest scummvm core. Yes I'm considering dolphin if i get the spare time.

EDIT: For anyone who upgraded to the generic build yesterday, you might have noticed that Chrome/Spotify did not work. I've uploaded a new build today with the missing scripts.

Ok, I haven't tested it yet just pulled the latest cherry trail patches from plbossart, which is what's been used before. I have a Wintel Pro myself as well, but haven't had time to test the latest on it. Will do after the weekend.

That's because the cherry trail audio was removed in master after the 4.7 upgrade. You should try my build from today, as mentioned above I've added a new patch.

It was removed when the kernel was updated to 4.7 as there was no existing patch at that point. The patch has been updated recently so will probably be back in the next alpha version. I've added it in my latest community build, if you would like to test.

The unofficial repo was merged into LE, rsync should be already available as an addon. Did you look?

I've finally found the issue with scanning FLAC files. Previously I've switched to GCC 6 as some buildbot cores were depending on the new C++ ABI. Rolling back to GCC 5 again fixes it. As a result I've switched back to building cores for the generic build, results are always better when compiling specifically for the target platform. Probably a good idea to stick with the same as LE8 master uses as well.

20160812 (still building):

- Updates to mesa, vulkan-loader, mupen64plus, snes9x, retroarch, fba, core-info and libretro-database
- Made retroarch fullscreen by default
- Added tyrquake and yabause cores
- Added FLAC/mp3 support to scummvm-libretro
- Revert to GCC 5.4 and building generic cores instead of downloading from buildbot
- Cherry/Bay trail HDMI audio patch for 4.7

Notes on Vulkan: at the moment, launching games from XMB leads to a segmentation fault (crash). Using the CLI to specify core and rom works. This was working before, likely a new bug in RetroArch/Mesa. Vulkan performance is much better now (on Haswell), but GL/KMS/X is still far superior.

Or you could simply enter \\1.2.3.4 in explorer, where 1.2.3.4 is your IP address. Or turn off local master browser setting.