yashsingh1/xdaforums huggingface dataset:
[Android Head-Units] rigattoni:
Agreed to both of you [MENTION=9325785]Scopesys[/MENTION] and [MENTION=4292729]SpeedFire-[/MENTION]

It´just a matter of the needed place on the screen for a round compass. If you want to have a good visible speed you need to have a big compass on the screen... and that´s not really usable.

For me it doesn´t match to my "gusto", so I think I won´t use the compass as it is.
[Android Head-Units] ric69:
French translation updated 100% on onesky site ;)
[Android Head-Units] SpeedFire-:
Thank you!
[Android Head-Units] Th0m4s88:
I don't know why but since I updated to the latest version of FCC and DAB-Z the autostart of DAB-Z only worked one out of 20 tries with cold boot.

What happens is:

-headunit finishes booting up

-FCC starts and finishes loading

-the player widget shows the picture and info of the last DAB-Z program/title before reboot and shows play

-instead of starting DAB-Z the player widget changes to pause and the quick player sign and the play/pause/jump forward/backward signs become gray (like showing something is not available I think)
[Android Head-Units] ric69:
My pleasure thank you master :good:

During tests this afternoon, I saw spedometer oscillating from 0 to 1 or 2 or 3 while I was stopped , and when I drove, speed was wrong (or long to update ... approx 10km/h)

Is it my gps sensor? (It's most probable as it is inside the car) I have 8 or 10 satellite / 12 most of time

With Waze speed is correct
[Android Head-Units] SpeedFire-:
Speed is provided directly by GPS chip on your device.
[Android Head-Units] ab1702:
Same problem for me too with dab-z and also Apple Music. They don’t autostart if they were the last player used from cold boot or waking from sleep.
[Android Head-Units] TYourdog:
Anyone have any suggestions?
[Android Head-Units] Funisimo:
Can't get calling to work, nothing happens even installed the fcc starter and the other one, any help appreciated
[Android Head-Units] Scopesys:
My GPS speed oscillates a little, between 0 and 1 when I am stationary, - but that is pretty common as a speed display in all apps, because the actual GPS is sending out that very low random speed, because of varying random errors in your GPS location, from which it is calculating the speed.

While I would agree that is INCORRECT, it "should" be zero,but is really not a FCC's "fault".

I look at it with "the Glass 1/2 full". If it is "twitching about" a little between 0 and 1, (when I am stationary) then I know the GPS is working !!!!

I guess a developer "could" code in a Minimum speed to display, maybe 2 MPH, but then some will complain that it displays 0 MPH when I am moving very slowly at 1 mph !!

For more important is that the COMPASS does not twitch about then you are stationary, and the GPS errors are potentially thinking you are moving that 1 mph is a ransom direction -- and display that random direction. FCC would seem to be taking care of this, with a highly stable compass, and some good processing of GPS data :)

Notice that FCC does not display a compass direction when you 1st start FCC, and only starts to display a direction after you have moved, and there is a confirmed direction.

I really like that, rather than doing what some other apps do, (like Torgue), and default to displaying NORTH at startup.

FCC knows better :)

---------- Post added at 20:50 ---------- Previous post was at 20:41 ----------

I believe I have the same issue with my Uninstalled Allwinner head unit - at least did up to a few weeks ago (have not updated it in some time)

Roadlover Allwinner (RL-YZGHC801) (T3-A7 [1024 x 600] MMC Android 6.0) 2GB RAM, 32GB ROM (Not Rooted)
​

My installed Eonon Unit is working 100% correctly with FCC .. I could not be more pleased :)

.
[Android Head-Units] TYourdog:
Ah man.. do you know of any versions that worked better? Do you think it is a head unit issue or a coding compatibility issue?
[Android Head-Units] okij:
Yes, indeed! :)

[MENTION=4292729]SpeedFire-[/MENTION]: Would it be possible that you apply your GPS algorithm also to your offline Mapbox display, so that it behaves like your Google Maps display, or isn't it possible to use your algorithm for Mapbox?

As you know, currently the Mapbox map is twitching around when the car is stationary, which renders it quite useless. I would like to use it instead of Google Maps to save some mobile data when needed.
[Android Head-Units] Scopesys:
HAPPY NEW YEAR to [MENTION=4292729]SpeedFire-[/MENTION] and all those in this forum.

Looking back over 2019, there were so many fixes and additions to FCC, that now it is barely recognizable, compared to how it was a few years ago.

It has certainly added greatly to my enjoyment of driving my car with FCC installed, as well being great fun in being a part of following its development.

Thank you [MENTION=4292729]SpeedFire-[/MENTION] for all your hard work, and dedication to FCC, and for being so responsive to users issues and request.

FCC is , (in my opinion), by far the best Android Car Head Unit Launcher available.
[Android Head-Units] cityhunterxyz:
I have a head unit that was doing that and I seem to have fixed it through a setting the head unit had, the unit I have was made by XY Auto but was sold under the name Liehuzhekeji on amazon. anyhow under a Factory settings option in the settings dashboard was an option to select applications to be loaded upon startup, it recommends not selecting more than 3 apps for this, I selected FCC auto and Torque and found that neither app has to do a full reload when started, it seems to me like the manufacturer did some tinkering with how apps suspend in the background as I had a similar problem when downloading my google play music library to my head unit in my driveway if I was tinkering with setting up other apps the downloads kept cancelling like the process was being killed, perhaps you have a similar setting.
[Android Head-Units] okij:
FCC Mode Action app

I also wish a Happy New Year to [MENTION=4292729]SpeedFire-[/MENTION] and everyone on this forum! :)

Yesterday I made a small app (see attachment) with Tasker App Factory which just sends the broadcast intent "ru.speedfire.flycontrolcenter.MODE_CHANGE_ACTION" (which I got from this post) to cycle through the players which have been selected in the FCC settings settings of the MODE widget.

I assigned this app to the Mode button in the Mod settings of the Hal9k Android 9 ROM that I use on my head unit.

The advantage of this procedure (in comparison with assigning the player apps like DAB-Z and FM-Radio to the Mode button directly) is that FCC handles the changes between the players much better, i.e. performs them in the background or sends the player to the background after the playing has started. Now the usage of the Mode button works much better for me, e.g. the navigation app isn't disturbed when I change the audio source. :victory:

I share this information and app, since it might be useful for other users.
[Android Head-Units] SpeedFire-:
HAPPY NEW YEAR!

Thank you for all your help, bug reports and great ideas!

Here is an alpha

FCC Launcher 3.348:

- Attempt to fix players and DAB-Z autostart on boot.

Please check
[Android Head-Units] tonimontoia:
the dab does not restart after a change from radio or other, then if the launcher is restarted the dab does not start
[Android Head-Units] SpeedFire-:
Thanks. Can you please test this one?

FCC 3.348d
[Android Head-Units] tonimontoia:
Ok i test

---------- Post added at 02:44 PM ---------- Previous post was at 02:03 PM ----------

then sometimes it works sometimes it does not work, if you switch from poweramp to dab it makes a bit of a mess, from dab to radio it sometimes passes though, there is also the Bluetooth to be reviewed that most do not start
[Android Head-Units] okij:
FCC starting issues when waking head unit from standby

I tried FCC 3.348d and for me it's working as good as FCC 3.347. That means I don't have any problems switching between DAB-Z, FM-Radio and GoneMad Music Player, which I also have applied to the player widget. I'm sorry that I cannot help further testing this and have to leave it to [MENTION=1580792]tonimontoia[/MENTION] who has issues when switching between players.

However I still have major problems with FCC 3.348d (as well as with older versions) on my PX5 head unit running on Hal9k's Android 9 to get FCC properly started when waking my head unit from standby. I observe the following three different cases, which occur quite randomly (i.e. I cannot reproduce them reliably):

FCC starts properly when waking the head unit from standby, so also the last used player starts playing after some seconds. This is how it should be.

FCC starts when waking the head unit from standby, but takes a bit to long to get settled, so I get an Android message "FCC Launcher is not responding / Close app / Wait" (please see attached picture). Nonetheless the last used player starts playing after some seconds, but it's annoing to have to tap on "Wait" to get rid of the Android message.

FCC doesn't start at all. Instead one of the last used apps (e.g. FM-Radio or Tasker), sometimes even the Android task switcher, is in the foreground after the unit has been woken from standby. In this case FCC only starts after tapping on the Home button.

I really would like to put FCC to the ROM's whitelist of apps which aren't closed during standby. This basically works (i.e. FCC is shown instantly after waking the head unit from standby), but then I have the following two issues:

The last used player doesn't start playing at all, so I have to do this manually.

I could configure DAB-Z to start when the DAB USB device is detected, so that at least DAB starts playing automatically (also if it was not the last used player), but then the station and title display in the player widget are in the wrong order, as I already reported some time ago.

So I would like to ask you to implement a way that the last used player is started even if FCC has not been closed in standby. I read somewhere (I guess on this thread or on the DAB-Z tread) that there is no Android event (intent) which is sent after the device is woken from standby, but that USB devices always trigger some event when being woken from standby. So by using this trick it should be possible to implement this behaviour.

Maybe [MENTION=7838245]realzoulou[/MENTION] can help you with this, since he has implemented an option in DAB-Z to automatically start playing when the DAB USB device is detected after standby.
[Android Head-Units] rigattoni:
I never had this issue as you in the last few versions.

Unpacked my Klyde PX5 4/32 with Hal9k´s Android 9 for testing the last few versions.

As player: FM, DAB-Z, Poweramp pro, and Radioplayer (online radio).

So I´m out too for testing this issue...

FCC is always restarted after standby mode, same as Blitzer.de PLUS.

Applications whitelisted: Skype, Tasker, TomTom.

DAB-Z is setup as start minimized when USB is connected.

In FCC my settings for audio are:

Start last player on boot

Play even if player is paused.

I never ran into these issues you described in your posting.

...so seems to be related to some differences in hardware/supplier, or whatever else.... strange...
[Android Head-Units] Scopesys:
[MENTION=4292729]SpeedFire-[/MENTION]

Please consider adding the ability for FCC users to include their own files to customize certain areas of FCC.

For Example: (some I would like to be able to customize)

(a) Two Minimap json files ( a day one and a night one)

(b) A Player widget Artwork mask file

(c) A Compass Scale and Compass pointer files ( + in this case, the corresponding edit selection graphic)

No doubt, there will be other FCC features that could take advantage of such a customization system

There are probably many way to do this, and before I made this request, I considered some of them, and narrowed my suggestion down to the one below.:-

A "user" FCC folder, where such files can be placed with defined names.

This folder should not get deleted if FCC is uninstalled.

It could also contain sub folder ("examples"), where an example of each file type is placed when FCC is installed, along with a text file, that explains the purpose of all currently supported file names.

When FCC is installed or updated, only this example folder is "Replaced" with that versions set of example files, and text documentation file.

Users could then create their own files in the main FCC User Directory, and FCC would look to see what files have been placed there, and use them to include in edit selections for the appropriate widget etc.

The HELP documentation Text file would be available in the Example folder, to aid users in creating their specified user files, with per-defined names.

If, at any time, it is thought that a bad user file is causing an issue, that file could be temporarily replaced by the corresponding one from the example folder, (which should not have issues), to verify that it is not a user's created file causing the perceived issue.

While a system could be designed to have these user files placed elsewhere, the above system has the advantage of keeping them all in the same place, along with current example version and current documentation, all in the example folder.

It might also be easier this way, to ensure that the user files survive FCC updates and re-installs.

In the past, this sort of Customization has been achieved by specific request from users for specific new options, and those requiring to have to be created by SpeedFirer and included in FCC.

The system above would have the advantage that users could created their own customization, with the option to adjust and tweak them to meet their own needs, without burdening the developer to add these new alternatives, that may only be of interest to a few,

In addition, those users who create their own custom files, would have the option to share them with others etc etc
[Android Head-Units] Mickel66:
I got a similar problem with my headunit (android 9 / Malaysk)

Waking after standby I must push the Home button, and FCC is starting like it must be.

If I don't do this, auto-brightness is not working, Spotify will not re-start etc.
[Android Head-Units] okij:
Thanks for confirmation of this issue! :)

[MENTION=4292729]SpeedFire-[/MENTION]: I just had to make a trip in my car and tested the start from standby (with FCC not whitelisted) about 4-5 times. Now every time I got the Android message "FCC Launcher is not responding / Close app / Wait". Is it possible that the latest FCC 3.348d does something more in the background when starting, so that the system thinks that FCC is not responding? In the previous versions I got this Android message only sporadically.

Actually you don't need this option in DAB-Z anymore, because FCC will now start DAB-Z in the background (with the "Start last player on boot" option activated) if it has been playing before standby. IMHO this is an improvement, because the player which has been used before will resume to play, which doesn't have to be DAB-Z every time but could also be a different player.

I had the "Start last player on boot" option activated anyway and now also activated "Play even if player is paused", but this doesn't make differency for the issues that I described in post #4955. I really hope that [MENTION=4292729]SpeedFire-[/MENTION] will look into the FCC starting issues. :fingers-crossed:
[Android Head-Units] SpeedFire-:
There was an issue with remembering the last player before going to sleep (maybe it still exists).

Please try this version: FCC 3.348e
[Android Head-Units] SpeedFire-:
I've made some changes to prohibit FCC Launcher from starting while the device is switching off. Maybe this resulted in such an error. Can you record a LogCat log?
[Android Head-Units] okij:
Yes, of course I can take a LogCat log for you. I'm just not sure if I will manage it today or do it tomorrow.
[Android Head-Units] Scopesys:
[MENTION=4292729]SpeedFire-[/MENTION]

Version 3.348 does now remember the player that was playing when the unit shut down. :)

It seemed to have stopped doing this correctly in the past "few" versions, but prior that that, it was remembering.

But there is now another strange thing happening. :(

On shut down/restart, when the FCC populates the screen with the Player widget, it often displays the Artwork from the 2nd to last player !!! that was selected before shutdown, and then, only when the correct last player starts to run, does it update the artwork and Title/Artist to the correct CURRENT player info.

Why does it even remember the 2nd to last player's info . ????

I would have expected FCC, on restart, to Initially display the default Player Logo, and the "BLANK" Artist & Title, until such time that it has established the current player playing, and got the CURRENT Artwork & Artist/Title.

Yes, it finally gets there, but it is real strange that it initially Initializes to display the 2nd-to-last selected player's info, as opposed to that of the player that was playing at shutdown.

In any case, even displaying the SHUTDOWN TIME "Artwork & Artist/Player" as a Initialization "Default" until the correct data can be obtained from the player would seem to be a bad choice, especially when that data could be from an old stream that played days ago !!

Therefore, I would suggest that the correct operation should be, ON RE-BOOT, in Initialize to the Default Player Logo, and Blank Artist/Song, until such time that the currently selected player is up and running, and FCC can get the CORRECT CURRENT player Artwork and Artist/Title form that Player. ( which I think is how you intended it to work)

BTW: It does correct display the Default Player Icon as Artwork, and Blank Artist/Player when a new player is first "SELECTED", until the new data from the currently playing player is available, something that you fixed a few months ago, and has been working perfectly ever since . :)
[Android Head-Units] SpeedFire-:
Good point. Try this one:

FCC 3.348f
[Android Head-Units] ab1702:
[MENTION=4292729]SpeedFire-[/MENTION] I’ve just tried this version and it sounds like I have different results to other users.

If hardware/software makes a difference then I am using PX5 device, Android 8, Hal9k rom and newest GS mcu.

1. Was using dab-z and then turned unit off, turned unit it back on and it woke from sleep and then automatically started playing dab-z which was perfect.

Now 2 issues.

2. Was using Apple Music and then turned unit off, turned unit back on and it woke from sleep but didn’t automatically start playing Apple Music again. It didn’t start playing anything it was silent so I had to manually start a player.

As I’ve said before this did previously did work in older versions of fcc before you started to try and fix the autostart of dab-z problem.

3. Was using dab-z and then restarted the unit so it was a cold boot, when unit restarted it didn’t automatically start playing dab-z and nothing happened so I had to manually start a player.
[Android Head-Units] okij:
I now took a LogCat log and attached it to this post. During those tests I had FCC 3.348d installed.

Before taking the log, I started the head unit four times with the following results:

At about 22:31 o'clock: FCC started with Android message "FCC Launcher is not responding / Close app / Wait". I then pressed on "Wait" after a few seconds.

At about 22:32-22:33 o'clock: FCC started without problems.

At about 22:34 o'clock: FCC started with Android message "FCC Launcher is not responding / Close app / Wait". I then pressed on "Wait" after a few seconds.

At about 22:35 o'clock: FCC didn't start at all. Instead, Tasker (which I started before sending the head unit to standby) was in foreground when starting the device from standby and stayed like this until I pressed the Home button. Only then FCC started.

After taking the log, I installed FCC 3.348f. The old album and track info now isn't displayed (or quickly erased) when starting or changing a player, so this seems to work. :good: But there is a new bug now: The album art isn't displayed anymore, even if it gets updated by the player.
[Android Head-Units] Scopesys:
I also confirm that Artwork updates, working in 3.348e, now never update in 3.348f - always now displaying the Default Artwork

(except FM radio, that will display the user defined FM radio Artworks)
[Android Head-Units] SpeedFire-:
Maybe this:

FCC 3.348g
[Android Head-Units] okij:
Thanks, album artwork is fixed again. :)
[Android Head-Units] Th0m4s88:
DAB Z works better when switching players now but still refuses to autostart on cold boot. Could it be that because of the unique characteristics of the app DAB Z is not recognized as a player by FCC? All other players are autostarting perfectly with every try when they were the last working players, only DAB Z doesn't.
[Android Head-Units] Scopesys:
Thanks - Artwork fixed and updates now, but unfortunately, there is still an instability when changing players.

It looks like that on a player change, the artwork & artist/title are now correctly being initialized to default/blank, but then sometimes a player info from two players ago get displayed, before the correct current player info is displayed.

This is not always happening, and seems to happen randomly most of the time, although in the attached video, I was able to find a combination of player changes that this occurred in quite consistently.

At other random times, FCC would going into a whole series of artwork updates from previous players before either setting on the correct player and it's current artwork, or even end up on a different player to that that had been selected.

Most of the above, I have managed to catch in the video, but as these occurrences are so random, the video is long and somewhat muddled... but it does show the problems.

https://drive.google.com/file/d/1J2q29TCkzJsQ2NZxgsaZx2wQNWjrV0Ug/view?usp=sharing
[Android Head-Units] surfer63:
Maybe it is something completely different.

All those units going into deep sleep disconnect their USB-devices. On wake-up these USB devices are reconnect but only after Android is completely up-and-running again, and then the USB-reconnect is still quite slow.

What if FCC does start DAB-Z, but DAB-Z cannot find its USB-dongle yet because it has not yet been coupled by Android. In that case DAB-Z will not start.

That can only be tested if you could set some delay for FCC's autostart function.
[Android Head-Units] Flemischguy:
That cold boot problem happens also without FCC installed. The software tries to connect 5 times with the DAB+ dongle, get the message it can't find the hardware and then the FM tuner kicks in. If i remember well, real zoulou told me it could help that you connect the DAB+ dongle on a USB pasivie hub.

So it ain't a FCC problem.
[Android Head-Units] surfer63:
This only confirms what I said one post up. The USB "mounting" is simply way too slow.

Or so it seems ...
[Android Head-Units] ab1702:
This is a different thing altogether. I have seen this before on my unit but it happens maybe once every 6 week. I have to restart my unit once or twice and then it fixes it. The issue with fcc not autostarting dab-z from a cold boot happens every time.

---------- Post added at 08:24 PM ---------- Previous post was at 08:21 PM ----------

This is exactly what I see aswell, only it doesn’t start Apple Music either from sleep or cold boot.

As an experiment I tried using some different players that I’ve never used before and these did autostart so I only see the problem with Apple Music and DAB-Z from cold boot( autostart from sleep works fine).
[Android Head-Units] okij:
[MENTION=8476598]ab1702[/MENTION] and [MENTION=9693399]Th0m4s88[/MENTION]:

Usually I don't make cold boots on my head unit, but today I tested if can reproduce the issue that you reported. I couldn't, i.e. DAB-Z started playing as intended after a cold boot.

Therefore I would advice you to take LogCat logs so that [MENTION=4292729]SpeedFire-[/MENTION] can have a closer look at your issue.
[Android Head-Units] SpeedFire-:
This version is sent to Play Strore as a new release FCC Launcher 3.349:

- Player autostart on boot fix

- Time and Player widget fix (did not update sometimes, especially after initial setup)