I have a setup where my TV is connected to the AV-R. To the AV-R are connected two RasPis and some other peripherals. As turning a RasPi on either means turning physically reconnecting power or some extra hardware, they stay on all the time. One has LibreELEC running on it, the other Racalbox 4.1.

When I turn the TV on to watch TV, the RasPi with Recalbox steals focus: I turn the TV on, the AV-R goes on and switches the system to show the Recalbox screen. This does not happen with the LibreELEC RasPi (even when that is the only one powered up) so I'm guessing it has something to do with the software. In LibreELEC this behavior is something I would expect to be able to configure in the CEC-Adapter configuration (even though I'm not seeing an option that says "claim focus when TV is turned on"). I don't know how much CEC recalbox "speaks" or if this is a feature of the underlying Raspbian, but I'm wondering if there is some way to make Recalbox be more passive on my entertainment system connections.

This behavior was also present in 4.0.1.

What needs to be said: 4.1 is fantastic on the RasPi3! I'm having no problems with the BT interface (8bitdo controllers), the new web interface for configuration with virtual controller and keyboard is beyond expectations and the on-screen-keyboard in ES is just what I needed. You guys rock! Thank you very much!

@substring
The desire for internal BT is esthetic and practical: for one I don't want to buy another piece of electronics which I don't need. And also, I bought this awesome Pi case which looks like the NES which I had as a child, only in very small, and I'm not going to ruin that by plugging a BT dongle into it. Yeah, wired is OK, but my back hurts sitting on the carpet so close to the TV.

A canary test is actually a hidden update to a small number of users, who are usually unaware of their function as a canary, not a method for a protracted roll out of a large update. I feel canary tests are a failure by design, as people running productive systems are used as Guinea pigs without their consent, I have often argued against them and opted for more RCs with voluntary testers who can be readily found for most projects and IMHO are often much more helpful in identifying the problems instead of just being p**sed at the developers for delivering an insufficient product (and they are right!). But no matter, a protracted rollout due to bandwidth reasons is very legitimate and by no means a canary test.

As I basically have no time to be writing this, but have done so anyway, I have no time to get into configuring RetroPie tonight, so maybe I will just check back here soon to find a 4.1 version available for a clean install and so you will have made me just another happy retro gamer dwelling in the memory of a long long time ago, when life was simple: school, computer games, BASIC, and the occasional fight with the parents.

Keep it up!

Dudes... (isn't that so 90s?)

@RustyMG
LOL, guess you know your way around these forums and this project.

@Substring

• The comment wasn't meant to be harsh. As I have participated in quite a few open source projects, and at a very previous point in my life earned a few bucks with software development, I'm just familiar with the usual mode of development: closed alphas, sometimes open alphas, sometimes closed betas, open betas, open release candidates and then a release. I didn't, and still don't understand, the development and release cycle of this project, and since this helps me decide whether to wait for a certain project or version, I just asked what point in the process you have reached.
• And if our communicating across two language barriers is part of the problem, I hope this acknowledgment will settle some of the arising discomfort, no harm meant.
• As to the PIs BT-module, currently I have no difficulties while running the NES and the prBoom emulators on Retropie, but I know nothing more about this.
• The automated update process and the accidental DoS-attack you fear, could maybe be reduced by serving the new version to only a fraction of the requests, the best ratio of update-to-4.1-answers to we-are-still-at-4.0.2-answers could be determined by the frequency of the update check, the number of running systems and so on (in short, the number of requests the server receives over any given time period). This way the load can be distributed over time.

Again, no harm intended.

(Now I will get back to trying to figure out, whether I will invest time in configuring the wretched RetroPie or wait for RecalBox 4.1)

@Substring
Lacking support for the built-in Bluetooth on the Pi3, the current 4.0.2 is simply not an option. So I ask:

Do you have an ETA for 4.1? Days? Weeks? A month? Several Months? A year?

What is the current state of development? Unstable seems to have been an alpha of some kind, or was it what you would consider a beta? Are you currently working on non-public RCs, or how am I supposed to understand the hints of this magical "soon-to-be released wonder of all things that will be 4.1" without needing any more community input?

I'm just trying to understand and weigh my options: invest a little more time now to set up the complicated but powerful RetroPie or live with an incomplete RetroPie for a short time and then soon move to a hassle free RecalBox.

Your work is much appreciated, provided that I can actually make use of it...