Music Widget won't show Radio info if set to generic option.

DUDU-Meng

Nechigawara
surfer63
At present, generic Music only adds tag recognition for standard media information of other players on the basis of already adapted and docked players, and it only has tag recognition and progress functions.
The automatic recognition channel you are talking about currently does not have this feature, and if it does, it will not be generic music, it will be another function. There are currently no requests for this feature.

Mikescotland

DUDU-Meng I'm struggling to understand your post, I'm sorry. Read it a few times.
You mentioned there was no requests about music widget having all under one umbrella without that nonsense switching between "general music" and "system music" then you're wrong. It was mentioned quite a few times in this forum.
However it's done, it can be reworked. If the widget can operate last played app with meta data, progress and play / pause / next /previous, I don't see any reason why the system app for radio, bt music and local files couldn't send this info as well and be also operated by "genetic music". Surely, it would involve reworking it but it would be the end of that confusing switching between groups of players.
I doubt this will be ever done, as I could see by our discussion about a bug in PiP called from tapping on music widget. I called it a bug as this was inconsistent with which application you allowed for PIP, you on the other hand requested me to submit a feature request when it was clearly a bug.
And last thing. Maybe it's time to get off your high horse with a banner "we know better what's good and convenient for our customers" because sometimes you don't. Also, I like answers from @dudu-lai and @DUDU-HUANG as they seems to be well thought and helpful. By looking at your answers, sometimes it sounds like you just answer for the sake of answering without anything substantial or even within the topic (vide: topic about 4G slow speed).
Ps. Music widget and all approach must be reworked anyway as it's unstable, awkward and inconvenient, pulls wrong covers, doesn't react to cover changes, forces lyrics in all views which doesn't exist or are wrong, doesn't react after wake up for play button. The list of bugs is long and currently I find it the most buggy function of Dudu7.
Ps 2. All works on DUDU seem to be chaotic, bugs are missed in this chaos and noone really sees what's the progress of their submission. You would avoid many repeated questions / features if you just create a simple Google doc with known bugs, possible resolution and perhaps time frame, and another one with feature request, all to be viewed by users. That's how it's done professionally.

Nechigawara

DUDU-Meng Ok, and what is the best way to submit this kind of request? Thank You.

DUDU-Meng

Nechigawara

Mikescotland
I feel I've explained this quite clearly: generic music can only recognize standard tag information from the media channel, such as song playback progress, artist, album, title, etc.
FM is a separate channel entirely—the audio isn't even on the same channel—and it doesn't follow standard protocols.
Bluetooth music data is transmitted via Bluetooth protocols, which are entirely different from the generic music protocol.
The generic music feature in the music widget currently only supports standard media tag recognition. It doesn't automatically switch between channels, nor have we received requests for such functionality.

Nechigawara

DUDU-Meng And that's why I ask where can I request this feature. Since the forum only has 3 tags and no tags were related to feature requesting. Thank You.

Mikescotland

DUDU-Meng are you for real? Widget doesn't do anything with audio channels and you confirmed by saying it operates in generic mode with "standard media tag".
Read again the whole thread.
If app for BT audio / radio / local files sends standard media tag (in layman terms), widget treats them as like any other standard player.
Problem is it doesn't (and you said so), so it must be reworked. I suspect this is a FYT standard app and you basically cannot rework it, if that's the case just say it, instead of clouding the response short of calling Mercury in retrograde, so everyone would just say "ah, OK, never mind".
Again, you repeated noone asked for it.
I don't know, maybe I have hallucinations reading other complaints about it.

DUDU-Meng

Nechigawara
https://forum.dudu-auto.com/t/function-request

DUDU-Meng

Mikescotland
You can look into Bluetooth tag and Bluetooth lyrics protocols, as well as FM hardware circuitry.

Mikescotland

DUDU-Meng it doesn't matter what app sends. DuduOS knows the tags from BT app / radio / local player, so sending them in generic version isn't a problem for a high school Android developer.
Doesn't send in a normal way? Well, either rework the app so it does, or translate them behind the stage and rework the widget.
First option - if you can rework the app.
Second option - if you can't because it's a system FYT app.

surfer63

DUDU-Meng You can look into Bluetooth tag and Bluetooth lyrics protocols, as well as FM hardware circuitry.

It has nothing to do with that or with audio channels. This is a completely Android to Android information propagation.
Some app does something and has the information and pushes it into the MediaSession api. It doesn't matter where this info comes from.
I could now write an app with input fields "write nonsense", "write more nonsense", "artist", "frequency", let the user type it in and then push "write nonsense" and "write more nonsense" into the MediaSession api so that the generic widget can show it as "title", "album", "artist", "frequency". And if the user types in another text, it will be propagated as well.
It doesn't matter where the info comes from. As long as it is received in the app, the app can push it further.
You could even use an Android spreadsheet app that pushes file name, worksheet name and cell content via the MediaSession api to "title", "artist", "album" (or whatever combination, although this would be completely useless).
Your FM app receives information (RDS info, frequency) from the FM-tuner chip through the MCU, but doesn't push anything into the MediaSession api.
NavRadio+ receives the same info (RDS info, frequency) from the FM-tuner chip through the MCU, but does push it into the MediaSession api, so it can be displayed in the generic widget.

You know everything about every setting and functionality of these units, but please discuss this underlaying Android functionality with your programmers.

DUDU-Meng

I don't understand—even if it can automatically recognize FM, Bluetooth music, and Spotify and switch between them, do you still need to manually open these apps?
Wouldn't it be more efficient to just click here to switch directly?
I don't understand

Nechigawara

DUDU-Meng So you suggest users should swap the mode (Radio/BT/Poweramp) here directly instead of open an app directly?

Mikescotland

DUDU-Meng @Nechigawara talks about minimalist mode, I'm talking about normal mode music widget.

DUDU-Meng

Nechigawara
If you're concerned about the music widget's auto-detect player and Bluetooth music features, do you need to enable them first? If so, wouldn't switching directly here be faster and more convenient?
If you don't need the music widget and only want to use the full-screen FM or Bluetooth music interfaces, then regardless of the default setting, it will function normally once opened in full-screen mode. In that case, auto-detect becomes unnecessary, right?

Nechigawara

DUDU-Meng From what I tried today by making Poweramp and Spotify run on startup and only use music widget to switch between audio sources.

Poweramp and Spotify don't always fully start on startup, and when I press the play button on widget, it asks me to open those apps in full-screen mode once. Then back to home screen again, same as what I normally do.
If I want to select the first song I want to listen, I have to open Poweramp and Spotify in full-screen mode anyway. But Radio Station can be made select-able on the widget with favorite station system.

But yeah, aside from those problems, it works nice and cleanly. I like it and didn't know the widget can do that.

DUDU-Meng

Nechigawara
Music widget serves solely to display music information.

Nechigawara

DUDU-Meng Yes, that why I still need to open Poweramp and Spotify in full-screen mode anyway. So swap audio sources with music widget become kind of an extra step. But I can deal with it for now.

If the audio widget can catch the current audio source automatically, that would be the best.

DUDU-Meng

Mikescotland
1.Standard mode can be switched here.

2.You can set up a toggle button in the music widget to switch between up to three music apps.

3.You can also configure the action that occurs when a widget is clicked.

Mikescotland

DUDU-Meng I know I can do it. But it resolves nothing. Do you really think I'm able to tap on 4x4 mm icon to switch the widget to another group of players when driving???

surfer63

@DUDU-Meng
Here’s a simple Android Kotlin function that pushes the current metadata (title, artist, station name from FM) into the MediaSession API so it can be broadcast to system components (like the generic widget). As you can see it pushes the station name simply into the Album tag.

import android.content.Context
import android.graphics.Bitmap
import android.media.MediaMetadata
import android.media.session.MediaSession
import android.media.session.PlaybackState

class RadioMediaSession(context: Context) {

    private val mediaSession: MediaSession = MediaSession(context, "RadioMediaSession")

    init {
        mediaSession.setFlags(
            MediaSession.FLAG_HANDLES_TRANSPORT_CONTROLS or
                    MediaSession.FLAG_HANDLES_MEDIA_BUTTONS
        )
        mediaSession.setPlaybackState(
            PlaybackState.Builder()
                .setActions(
                    PlaybackState.ACTION_PLAY or
                            PlaybackState.ACTION_PAUSE or
                            PlaybackState.ACTION_PLAY_PAUSE
                )
                .setState(PlaybackState.STATE_PLAYING, 0L, 1f)
                .build()
        )
        mediaSession.isActive = true
    }

    /**
     * Push current radio metadata to the system.
     *
     * @param title Track title (if available)
     * @param artist Artist name (if available)
     * @param stationName FM station name
     * @param artwork Optional album art or station logo
     */
    fun updateMetadata(
        title: String?,
        artist: String?,
        stationName: String?,
        artwork: Bitmap? = null
    ) {
        val metadataBuilder = MediaMetadata.Builder()

        title?.let { metadataBuilder.putString(MediaMetadata.METADATA_KEY_TITLE, it) }
        artist?.let { metadataBuilder.putString(MediaMetadata.METADATA_KEY_ARTIST, it) }
        stationName?.let { metadataBuilder.putString(MediaMetadata.METADATA_KEY_ALBUM, it) }
        artwork?.let { metadataBuilder.putBitmap(MediaMetadata.METADATA_KEY_ALBUM_ART, it) }

        mediaSession.setMetadata(metadataBuilder.build())
    }

    fun release() {
        mediaSession.isActive = false
        mediaSession.release()
    }
}

Off course this is only a skeleton version and the programmers need to use the proper variables from the FM app and the BT AVCRP variables.

EDIT: I updated it to also include the station logo, if available. Again: use the proper variables as the BT stream and the FM app use them.

DUDU-Meng

surfer63
I'm aware of all that. The current discussion is whether it's necessary to frequently switch between FM and third-party music apps, and whether the existing switching methods already meet the requirements.
Technically, it's feasible to automatically switch between Bluetooth music and FM—or even recognize audio channels—but is this feature truly practical?