yashsingh1/xdaforums huggingface dataset:
[Android Head-Units] SpeedFire-:
In this alpha I tried to restore the last player (if it was the 4th player in some widget - it should be restored):

FCC Alpha 3.307
[Android Head-Units] bossman4:
I have made some progress with the Pumpkin Single Din unit. It is a CPU AC8227L QuadCore 1,2 GHz MTK8227L. I am not sure what the base CPU pick I should make in FCC, but the PX5 choice that I have been using does not seem to bother it.

The Radio.APK was missing in the stock Pumpkin software, so FCC could not make it a choice on the FCC Quickplayer. I found a source for the APK and installed with APK installer. When I start the new Radio application from the apps menu, it is fine...….so the APK works.

When I try to make RADIO a choice on the FCC Quick menu, it does not show up as an option. All the other installed players (Black Player, FM Tuner (Podcast), Amazon and PowerAmp) show up as options for the quick picks, but not Radio.APK.

Do I need to rename this APK, so FCC Quickplayer can recognize it?

In the meantime, I will try the .307 version on both units.
[Android Head-Units] Scopesys:
[MENTION=4292729]SpeedFire-[/MENTION]

Thanks you ... but ....... Unfortunately this seems to have introduced another issue.

No matter what I set the 4th player to be, if I select one of the other players, the 4th player is then changing to Google Music, even if Google Music app is not running.

The impression I get form what you have said in the past, is that FCC is remembering what players have played, and their information (Text & Artwork), so they can be re-displayed when a player is changed.

This may not be the best thing to do...?

What might be better is a different priority.

A new quickplayer is selected

#1 Change the quickplayer selection to indicate that player is now the current quickplayer

#2 REMOVE current artwork and Player song information, setting artwork to default generic PLAYER Graphic, and the artist and song text to Blank (or maybe a few dashes)

#3 Then go and try to get the CURRENT Artwork and Player song information from that player.

It is better to display NOTHING, than the wrong information, and if it works as above, it should NEVER display the incorrect information, and most issue will then be about getting the current information.

Trying to remember what was the information for a player that was playing some time ago, or even players that are no longer even running, may not be the best approach, as it is very prone to displaying incorrect, or at least Out-of-date information.

BTW: The above results were obtained both after a simple update to 3.307, and the same results after completely uninstalling FCC, deleting all FCC info on the HU, a re-boot, and a fresh install of FCC 3.308
[Android Head-Units] SoberXDA:
I agree... Especially when my 4th player is youtube vanced... "Restarting" doesn't make sense then as it does not even start with the last played video...
[Android Head-Units] Scopesys:
Same for any streaming Radio station type source, that is playing a set program, and set audio at any specific time,

Personally, I would reluctantly accept if it always started up with the 1st Quickplayer, but what is not so good is when it starts up with a player, displaying the incorrect information for that player ( either the old data from another player, or its own old data)

To me, #1 priority is to indicate correctly what player is playing, and only display information, if that is the correct CURRENT information for that player. Displaying INCORRECT information is far worse than displaying no information at all.

It should also not, after a time ( from a few seconds, to a few minutes !!), suddenly swap to another player by itself.

ie Priority should be to determine what player it should be playing, and then stick with that, unless the driver manually changes it.

The Player widget seems to be by far the most complex widget, with the most variables which are outside Speedfire-'s control (ie almost any player, developed by a vast range of developers with varying skills), but once it is working correctly, hopefully, it will not get broken.

Also, at any time , One of the quickplayer should show selected, there should NEVER be a time when all show non-selected., and the only thing that should change that selection is a manual interaction by the driver.

Note: selected is either selected and playing, or selected and paused, which are typically different colors.
[Android Head-Units] SpeedFire-:
[MENTION=9325785]Scopesys[/MENTION] just to clarify. You recent posts mean that the latest alphas work less stable than the previous ones or you just request some further improvements?
[Android Head-Units] Scopesys:
[MENTION=4292729]SpeedFire-[/MENTION]

Less stable .... as it gets itself sorted after a re-boot, and then the strange new bug that it always want to set the 4th play to Google Play, after a re-boot.

Previous version seems more stable, but the latest introduced this bug where FCC changes the 4th payer after a re-boot.

ACTUALLY, ref Video, it does this switching to Google Play every time 4th player is selected, so nothing directly to do with RE-Boots or Re-starts.

Video showing FCC changing 4th player to Google Play when 4th player is selected by driver.

(Does not matter what the 4th player started off being, and when FCC does this, Google Play is not running in background, and does not have any notifications showing)

https://drive.google.com/open?id=1ANQFCrflwrPvzkeVPhivHGLIrR9te9nI
[Android Head-Units] xxdannyxx02:
I cant add any widget to the home screen, when I drag a widget to the home screen it just quickly auto deletes. Any ideas on how to fix this issue?
[Android Head-Units] Scopesys:
[MENTION=4292729]SpeedFire-[/MENTION]

Got 3.307 running in emulator, and made video, showing Device + Logcat

https://drive.google.com/file/d/1JJQbVp-12QqoIpm8cj2A5B8xbnW72HSZ

Hopefully you can see something that is meaningful in the log at the point where the Quickplayer widget messes up.

I am very new to Android Studio, and cannot tell what is really being Logged as a FCC issue, or an issue in the setup of my Emulated Device.

I have seen Errors reported when FCC is trying to use the FCC database, and I also have seen occasion where some widgets disappear from the FCC screens, and I have to restore from backup to get them back.

One question: What detail level is best to use for the LogCat? Verbose or just Warning ?

Is a video like the one in this post of any more use than just a text Logcat ??
[Android Head-Units] bossman4:
I have only three choices on the quick player and am not using Amazon, Google Play or Spotify at this time. Much of the time FCC Quickplayer will switch correctly between players, but "sometimes" the artwork does not change. If I cycle through the same steps again, then the artwork changes correctly. I think Scopesys's video and log are picking up that behavior, but it does not appear to be 4th player "sensitive", unless FCC is looking for a phantom 4th player. I have the feeling when this gets worked out, the online services will work ok, once they are started up. It is nice to see FCC quickplayer holding steady until the online app finishes a startup. Not sure with the online services..... when the artwork is fed to the unit vs. the audio feed to the unit. If the artwork shows up late during a lag, maybe FCC does not see it in time.

Nice to see all the customization that is available with FCC that Scopesys has done!

By the way, when I had an FM Radio choices without an FM Radio APK (1st choice), it would get confused until I got back to toggling between the on unit media players.
[Android Head-Units] rigattoni:
Nearly the same on my unit.

After just now 2 hrs running in foreground I face the problem that the widget does not react anymore.... or less as expected.

I created a video, attached as 7z.

View attachment 4864375
[Android Head-Units] Scopesys:
Nice video of 3.207 .. saw some things going wrong there that I see as well on both my HU and in Android Studio...

Can you confirm that this issue was introduced in 3.307, and did not exist in previous version. ie 3.306 worked a lot better, and did not freeze up after 2 hours.

I am typically finding the opposite... when FCC first starts, it spends 2-3 minutes, doing something that makes it stutter, but then it starts to work smoothly.

[MENTION=4292729]SpeedFire-[/MENTION]

For me, 3.306 was a lot less buggy.

To me, as a user, the priority within the FCC Player widget should be

#1 Responding to user input to it's controls, and indication that it is seeing the inputs and acknowledging them correctly,

ie when a quickplayer is selected, #1 is is show that selection taking place.

(ie User Interface must have a High Priority)

#2 Is to switch to that selected player, and REMOVE the old Artwork & Text (song/artist), typically replacing the Artwork with either a Generic Artwork, or one that depicts the selected Player.

#3 Play that Player.

#4 Only then, go and try to get the Correct Current Artwork and Text information for that player.

NO Information about what is playing is better than Incorrect Information.

The impression I get is that FCC is trying to remember what each player was playing, when it was playing ? or is it trying to be more clever, and update its stored information about what each player is playing, even if that is not the currently selected player ?
[Android Head-Units] rigattoni:
I see this issue since the last update, yes.

I also have some stuttering after start up and see the reported issue even after wake up from deep sleep. Only a full reboot heals it for a time.

Nevertheless, I fully agree to your statement [MENTION=9325785]Scopesys[/MENTION], stability of the UI should have highest priority.
[Android Head-Units] Scopesys:
I must admit, I have never run FCC for any extended length of time, so I have never experienced this. (don't take long journeys in the car with the FCC head unit).

This evening, I have set FCC running in the Car in the garage, with a battery charger on, so the head unit does not flatten the battery.

At startup, after it's settling down period, it seems to be working well.

Will see what has happened by tomorrow morning.

Maybe I will find a big pool of Memory on the garage floor, from a memory leak ?:confused:

-----

2 Hours Later

FCC was left running Radio for 2 hours.

Returning to the Car, FCC, that was switching perfectly between players 2 hours ago, is now almost totally non-responsive, and is behaving just like [MENTION=2534110]rigattoni[/MENTION] 's Video.

What was surprising to me, is that on the 1st Player change after 2 hours, FCC found it necessary to do a re-start.

Note: This was after reverting back to 3.306, so it would seem to be a symptom of at least 3.306 & 3.307

Wonder what it will be like in 10 hours tomorrow morning ?
[Android Head-Units] Scopesys:
[MENTION=4292729]SpeedFire-[/MENTION]

Well, after a further 8 hours, FCC's Quick Player selector, while able to select different players, had totally lost it ability to indicate which player had been selected, or display player information.

SYMPTOMS:

In fact trying to do almost anything in FCC typically resulted in FCC doing a restart. Sometimes, FCC would also display that it had stopped.

Forcing a FCC re-start, or even a re-boot made no difference.

Using an App Killer program, and completely removing all running apps from memory , and then restarting FCC made no difference. FCC was still un-responsive.

Switching to the Units original launcher, resulted in normal operation of the Head Unit using that Launcher.

Switching back to FCC, and FCC was still unresponsive, and wanted to constantly re-start.

FIX

The only way to restore FCC's correct operation was to restore the FCC settings.

After this, and a Re-STart, FCC operated correctly, as it had before this extended test.

CONCLUSION

Over this extended test period, FCC corrupted its Database, or Cache ? to such an extent as to make FCC unusable. Restoring the Setting (Database etc) restored FCC to it's original working state.

THOUGHTS

While running FCC in the Android Studio Emulator, I see a large number of Warnings and Errors.

Many of these I think are associated with Emulation (ie No Bluetooth etc)

But I do see FCC Database errors and warning about operation son the database, so maybe the Database is getting corrupted or filled with excessive historical data etc ?

Over a short time, this is not too bad, and only results in FCC starting to misbehave, but left alone for an extended period, with just a Mp3 player playing, maybe this becomes excessive and brings FCC to a halt.

This might also explain that why sometimes, over a period of running FCC for maybe an hour a day, some of the widgets seem to disappears or change their settings.

BTW: After 8 hours, this morning when I checked FCC, and it was all but locked up, the MP3 player, Blackplayer had stopped playing, but it has some 2000+ songs, and was set to random play, so should have run for ever.

THE GOOD NEWS

Before I restored FCC setting from the same backup I had loaded before this test, I was able to make a backup of the setting after this 10 hour test, so I have both

(a) Originally restore backup, before this test

(b) Backup of FCC setting, (database etc) after the 8 Hour test when FCC was functioning correctly.

They look almost identical to me... which I guess is good, but does not explain a lot :(
[Android Head-Units] rigattoni:
[MENTION=4292729]SpeedFire-[/MENTION]

Additional information:

If the unit reaches the "unresponsive" status and you switch between e.g. DAB-Z and PowerAmp, both apps have audio focus. That means that the unit is playing both at the same time....
[Android Head-Units] SpeedFire-:
Hopefully some of the latest bugs in Player Widget are fixed here:

FCC Alpha 3.308
[Android Head-Units] Scopesys:
Many thanks. Appreciate you working over the weekend on this.

Please could you expand on what bugs have have worked on in 3.308, so we know what to be looking for and testing.

The more you can share with us about what is changing, and how things work, the easier it is for us to give you relevant feedback when we test.
[Android Head-Units] SpeedFire-:
It's hard to describe everything. Mainly:

- More consistent widget view during initial start

- 4th player visibility

- No flickering of active player after restart
[Android Head-Units] Scopesys:
3.308 is better than 3.307 & 3.306 as far as switching between players is concerned, but still is not 100% reliable.

Long term stability is unknown.

Bug introduced in 3.308

Player Widget - Artist and song.

Both Primary & secondary text size can no longer be changed.

ie altering slider has no effect on Text Size.

Please also consider setting Artwork display to Default, and artist - song to Blank as soon as the quick player is changed, and then update them from there, if data is available.

Even better, set the Initial Artwork to the ICON for that app, that is already in app_Icons.db[Icon]

and

Initial text in Album & Song both to app_Icon.db[label]

Having switched to another player, if the Artwork and Song/Artist do not update Immediately to the correct data (which it cannot do until that correct & current data if got), it is far better to display a DEFAULT Player Icon and Song/Artist than incorrect data from the previous player.

------------------

Also, FYI - while I was checking my FCC backups, to see if how they differed etc, I noticed an inconsistency.

Ref: widget_pref.xml

iconwidget_is_custom_layout

<boolean name="iconwidget_is_custom_layout495" value="true" />

maybe should be

<boolean name="iconwidget_is_custom_layout_495" value="true" />

like the format all other "names" that have a _ before the widget ID#

Also same in preferences.xml

widget_player_state_saved

ie

<boolean name="widget_player_state_saved78" value="true" />

maybe should be

<boolean name="widget_player_state_saved_78" value="true" />

Maybe your XML parser will have difficulty with this exception, but goes un-noticed if the default is always "true"
[Android Head-Units] rigattoni:
Yes, same on my unit.

I can tell something about long term stability tonight, because my unit is still on bench and running the hole evening.

Yes, I would prefer that too.

Edit ~3hrs later:

Player widget is no longer responsible. It switches the player in background, but does not activate the "button". Audio focus issue is again. 2 different player playing music at the same time. In my case DAB-Z and Poweramp playing at the same time.
[Android Head-Units] Scopesys:
When i had the same thing happen, even system re-boot did not fix it.

FCC had to see a backup being restored to it to recover, although I think the data in the backup was effectively the same as the backup of the setting when FCC was had it's button activation issues.

If FCC cannot even respond to the user input selection, and indicate that the selection has been made, there is little hope for anything else to result from that selection.
[Android Head-Units] SpeedFire-:
Alpha 3.309:

- Font size functionality restored

- Switching between players is done via a default album art and "-" in artist/track fields.

- "iconwidget_is_custom_layout" is migrated to "iconwidget_is_custom_layout_" ("widget_player_state_saved" is not used, so no migration is required)

FCC Alpha 3.309
[Android Head-Units] SpeedFire-:
And another Alpha 3.310:

- Higher quality album arts

- Fix of disappearing artist/track on restart

FCC Alpha 3.310
[Android Head-Units] Scopesys:
Looking Good. Best so far. Seems to work a lot smoother, and the changes between layers is a lot more positive, and works well.

Have to be careful not to try to change to many times too quickly, especially when animated Notifications are on, but normally, one would not be doing that (only when testing and pushing to the limits)

Confirm:

Fonts sizes are back working.

Switching between players is nicely using default Artwork and dashes.

Running overnight -- will update this post in the morning..

There may still be some Player specific issues, especially with some streaming players, and I suspect those issues of getting artwork have always been there, and just not noticeable as the General Player Widget was contributing more update issues than the specific players. If this is true , maybe best left as a lower priority, after everyone has confirmed that the basic Player Widget is working well for all.

I think this weekend must be a record for Version Updates, so once again, THANK YOU [MENTION=4292729]SpeedFire-[/MENTION] for all you many Hours of work, especially over this weekend.

I also think that many would be surprised, if you gave us an "estimate" of the number of Hours TOTAL, you have put into FCC, from day 1 to preset. I do not think that most realize just how much time it takes to develop such an app, or just software development in general, All they see is the time it takes to download the app and install it ;)
[Android Head-Units] Scopesys:
FCC r 3.309 after a few hours of running.

Unfortunately, same issue as 3.308 & 3.307 ... after a time, the Quickplayer widget stop working correctly.

I started to make this video at about 3 hours after starting 3.309

When 3.309 was installed, it was working well, and was very responsive.

After 3 hours, it would seem the only way to restore is operation, is to restore FCC settings.

Neither Restarts of FCC or system re-boots seem to help... only a FCC setting restore.

It's a LONG (unedited video) .. showing just what happened when I came to test 3.309 after 3 hours of operation, and now the only way to correct it. was a FCC settings restore, and then some intensive switching between players, till it settled down.

The DEFAULT Artwork, and the dashes for the Song/Title on Quickplayer change, makes it a lot easier to see what is going on, and how it is, or is not operating, so those changes made to build 3.309 were well worth it :)

It also shows multiple other issues, like Incorrect artwork, incorrect players etc etc

If you want to get anything out of it, you will probably need to view it multiple times. there are so many issues recorded.

The improvements in the past few version, has improved the switching between Quickplayer, so now it is a LOT MORE clear, that different players behave differently when being switched to, and it is now easier to determine what is common to all players, and the additional specific issues that some individual players have.

At the moment, basically for me, I probably need to do Restore before each car journey (while I still have connection to my Google Drive on my Home wifi network - or start using the SD for FCC settings backup)

VIDEO (audio NOT very good -- will need to get a better Mic - and stop mumbling )

https://drive.google.com/open?id=1BAi40No-c0LQlCEqfKqrT0efct8sSXNJ
[Android Head-Units] bossman4:
I tried 3.310 on my Eonon unit that is close to the Scopesys model. I tired all this after startup, not later

I have a separate screen with Quickplayer all by itself

I have the main screen that looks very similar to the second template by speed fire

FM Radio

I pull up the quick player screen with FM Radio as the first choice. I have not made icons for the radio stations and don't have those options check marked. I have gotten consistent behavior with FM radio button pushing. The audio switches to FM and then the screen switches to the main screen with the standard graphic and the correct text. If I click in the circle, it shows the full screen radio app. If I go back to the quick player screen, the correct text shows up in the circle. If I switch to another player and then back to the radio, it consistently goes back to the main screen. If the FM Radio choice works like it is supposed to do, the Quick Player screen should change the text (and image) in the circle and not switch to the main FM screen.

Black Player

As long as you do not move the USB sticks around (storage) once it starts, it has very consistent behavior when chosen. The correct text and graphics show up when the choice is made. Works very well.

Player FM ( Podcast app)

Player FM downloads podcasts to SD or USB devices and stores it in a static spot. As long as you do not move the USB sticks around (storage) once it starts, it has very consistent behavior when chosen. The correct text and graphics show up when the choice is made. Works very well.

Amazon Music

I tried Amazon Music again to see if things had changed. There are two operating modes for Amazon Music, online and offload. The application is extremely sensitive to the movement of USB or SD cards and must redownload when changes have occurred which takes a long time when you are dealing with HD files. The way I have been doing the beta testing is that I have been loading new versions with a different USB. It is not clear which external storage device is being used to host the downloaded music files, but the testing always seems to set back Amazon to square one. The point is that once Amazon has downloaded the song and the artwork on the local storage and fires up, FCC seems to make the right choices in the Quickplayer. So testing the Quickplayer while Amazon Music is in Online mode just adds more complexity.

If you use Amazon Music in local mode, it appears to work consistently in Quickplayer as it is now.

I have not done long term testing, so I have not experience as noted by others.