RetroPie 4.3.17 Stretch images

herb_fargus

This is the failed compilation log for openblok on raspbian stretch:

maz

I understand is probably not even a bug but wanted to share.

Bluetooth Audio - bluealsa is not included on Stretch Lite (which is why I assume it isn't in Retropie either, and probably isn't needed by default for retropie). It is easy to install now just use "sudo apt-get install bluealsa". The other step that is needed is to also set a default PCM to point toward bluealsa with your mac address for the bluetooth device. I can provide / link to details on setting up. I don't know the retropie packaging system and if this could or should be put as experimental or if people should just run apt-get themselves anyway. There is issues with lag anyway.

The issue is with audio lag over bluetooth. I am not sure if / how to configure, but it is basically a 1 second delay which probably means bluetooth audio is only good for playing music. Video / Games would be super annoying with that lag. Googling didn't help me find a solution. Some say to disable wifi as they both run on 2.4ghz, but that had no effect. I think that is only for quality issues anyway, not the lag due to what I think is just buffering.

Every once in a while people ask about bluetooth audio on reddit, so I will watch and or proactive put out a post when this is released. I was super hopeful with stretch since bluealsa makes it way easier than before, but the lag makes me sad.

Again there is probably nothing for retropie to do, but since questions could come up I wanted to share.

liebowa

@maz Thanks for following this, as this is the one feature that I personally am looking for the most out of stretch.

fluffypillow

@herb_fargus Fixed OpenBlok, thanks.

I've also tried Super Mario War, and while your fork builds successfully, it segfaults on launch, apparently caused by an SDL_DisplayFormat error. The SDL2 version works fine.

herb_fargus

@fluffypillow I tested the binary and compiling from source on my pi 3 on stretch and it seems to work fine. My fork is split out just for use on the pi but I wonder if it would merit any benefit to build off your latest fork despite the netplay instability as I trust your code over mine.

fluffypillow

@herb_fargus Ah you're right, it does work from binary. Unfortunately other than the netplay and the SDL2 port, most of the time was spent trying to make the code maintainable, so there aren't too many visible features :( The SDL2 port might be useful though.

PS. It seems to work fine from source too now.

AlexJ

Hello,
Did someone tried to compile daphne-pi on stretch ?
While it was working fine on jessie, with the same romset, it played blinded and muted on stretch.
I tried to compile with gcc 4.9 and gcc 6.3, same result.
Bye

herb_fargus

I reflashed the image for more testing but after doing so am finding it troublesome to connect my 8bitdo sf30 pro controller. It is recognised in the menu but fails to authenticate.

(Creating device failed: org.bluez.Error.AuthentificationFailed: Authentification Failed)

I don't know if the 8bitdo is still thinking it's connected to the old image or if I mixed something up so I'll keep digging. I imagine a reflashing of the 8bitdo firmware will probably fix it and it's probably just user error on my part but it's something to be aware of if it's persistent for other users going forward

grant2258

@alexj

I know hypseus (sdl2 daphne port) is having problems on the on the pi on stretch as well the video just freezes. It also doesnt work on debian 9 x64. I wonder if its the new kernels with meltdown fixes that are effect mutex locks. I dont know if thats the same kind of problems you where having. Ill download the image and try compiling forked version of daphne and see if it works or not.

Sano

@meleu
Joystick selection doesn't seem to work anymore on this image.

Example for NES, with Dualshock3 selected for player 1 with "by name" method :

pi@retropie:~ $ cat  /opt/retropie/configs/nes/joystick-selection.cfg 
input_player1_joypad_index = "Sony PLAYSTATION(R)3 Controller #1"

pi@retropie:~ $ cat  /opt/retropie/configs/nes/retroarch.cfg 
# Settings made here will only override settings in the global retroarch.cfg if placed above the #include line

input_remapping_directory = "/opt/retropie/configs/nes/"

input_player1_joypad_index = "0"
# input_player2_joypad_index = "1"
# input_player3_joypad_index = "2"
# input_player4_joypad_index = "3"
#include "/opt/retropie/configs/all/retroarch.cfg"

pi@retropie:~ $ cat  /dev/shm/runcommand.log 
--- start of joystick-selection log
joystick selection by name is ON!
joystick indexes for "nes" was configured
joystick indexes for "all" was configured
--- end of joystick-selection log
Parameters: 
Executing: /opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-fceumm/fceumm_libretro.so --config /opt/retropie/configs/nes/retroarch.cfg "/home/pi/RetroPie/roms/nes/Dr. Mario (Europe).zip" --appendconfig /dev/shm/retroarch.cfg

Still the controller for player 1 is the other one (Hori Fighting stick mini)...

Edit : tried with other systems : same behaviour
I also tried to configure 2 PS3 controllers as player 1 and 2, same. Player 1 stay with the Hori stick, Player 2 is mapped with the first PS3 controller.

Edit again : After some tests I checked the jslist files :

pi@retropie:~ $ cat /tmp/jslist.
jslist.2Nyz  jslist.3XSC  jslist.hfJr  jslist.Tbq2  jslist.tmyw  jslist.UUnk  
pi@retropie:~ $ cat /tmp/jslist.*
0:Sony PLAYSTATION(R)3 Controller #1
1:HORI CO.,LTD. Fighting Stick mini 4 #1
0:Sony PLAYSTATION(R)3 Controller #1
1:HORI CO.,LTD. Fighting Stick mini 4 #1
0:Sony PLAYSTATION(R)3 Controller #1
1:Sony PLAYSTATION(R)3 Controller #2
2:HORI CO.,LTD. Fighting Stick mini 4 #1
0:Sony PLAYSTATION(R)3 Controller #1
1:Sony PLAYSTATION(R)3 Controller #2
2:HORI CO.,LTD. Fighting Stick mini 4 #1
0:Sony PLAYSTATION(R)3 Controller #1
1:Sony PLAYSTATION(R)3 Controller #2
2:HORI CO.,LTD. Fighting Stick mini 4 #1
0:Sony PLAYSTATION(R)3 Controller #1
1:HORI CO.,LTD. Fighting Stick mini 4 #1

The strange thing is The Hori Controller is USB connected (and never disconnected), so it should always be index 0 (what seems to be retroarch view)...
But his index in your script changes according to the PS3 controllers connected.

@psyke83 Could it be that your sixaxis module somewhat forces the index of the PS3 controllers to the first ones, regardless of the already connected controllers ?
(That would explain the active led 1 on the controller, before upgrading when I connected a DS3, the led 2 was on, because of the arcade stick being the first)

meleu

@sano said in RetroPie 4.3.11 Stretch images for testing:

Joystick selection doesn't seem to work anymore on this image.

:(

Thanks for the heads-up. Will try to check it when I find some free time.

Sano

Thanks a lot @meleu ;)
And try to enjoy your free time, this is not so critical :)

I think I narrowed it down to the jslist executable.

Here are 2 results before and after powering on a DS3 :

pi@retropie:~ $ /opt/retropie/supplementary/joystick-selection/jslist 
0:HORI CO.,LTD. Fighting Stick mini 4
pi@retropie:~ $ 
pi@retropie:~ $ /opt/retropie/supplementary/joystick-selection/jslist 
0:Sony PLAYSTATION(R)3 Controller
1:HORI CO.,LTD. Fighting Stick mini 4

Whatever, Retroarch still sees Hori as the 1st controller and DS3 as the 2nd, hence the issue...
If it can help, from the OS point of view, Hori is /dev/input/js0 and DS3 is /dev/input/js1

psyke83

I'm not too familiar with the controller order stuff, but isn't the HORI controller a PS3-compatible controller? That means it'll use the hid-sony driver.

That's a relevant detail, because the old ps3controllerdriver works differently. The sony_hid driver (with or without my module) would use the name Sony PLAYSTATION(R)3 Controller, but ps3controller (assuming you use the DS3 via bluetooth) selects the name PLAYSTATION(R)3 Controller, and it's enumerated through a uinput virtual input device.

If this is a sixaxis bug (or if not a bug, different behaviour from the driver), then it's off-topic regarding the stretch image and I would suggest continuing the discussion in my thread to keep this one on track.

FWIW, I have two official DS3 pads, and they seem to select the correct led corresponding to the controller number.

Sano

For information, I updated today, including OS packages, and the console autologin option reverted back to false, resulting in a console login prompt at boot.
I had to reconfigure it through raspi-config in order to boot to ES.
If someone could try to reproduce this... It could be an upstream bug.

BuZz

@sano I've seen this also. It is an upstream bug (unless they somehow wanted this by design, which I doubt).

BuZz

@sano It's caused by the systemd package update - from the upgrade log

Setting up systemd (232-25+deb9u2) ...
addgroup: The group `systemd-journal' already exists as a system group. Exiting.
Removed /etc/systemd/system/getty.target.wants/getty@tty1.service.
Created symlink /etc/systemd/system/getty.target.wants/getty@tty1.service → /lib/systemd/system/getty@.service.

I will report this upstream.

BuZz

Issue opened here - https://bugs.launchpad.net/raspbian/+bug/1755811

BuZz

4.3.14 stretch images are now available in the first post.

I will be testing them out on my Raspberry Pi 3 B+ when it arrives. But the packages are up to date, so they should work.

Sano

@buzz Nice, I was wondering if you saw my post about this.
Tagging interested people from other threads : @ganondork @pjft @tashman
Thanks for them, I didn't buy a Pi 3B+ (not yet).

BuZz

Looks like there may be a problem with the images - as I can't boot them here from a quick test. Possibly due to upstream Raspbian changes that are incompatible with the build script. Will update with more information soon.

[edit] Actually it could be my desktop/build system, as I updated it recently.

[edit] It was: They are missing the fat partition :-)

mkfs.vfat: command not found

Have fixed up the image builder dependencies. Currently building 4.3.15 images.