@lduboeuf I'll formulate a question for next Q&A-session. There is probably more to know and to consider than just a driver which could be implemented more completely.
I can still bring up the issue in the ofono-binder-plugin repository later.
Thanks!

It appears that the RIL-modem-software has no implementation of setting fast dormancy.

The FP4 has five plugins installed in folder /usr/lib/aarch64-linux-gnu/ofono-sailfish/plugins:

-rw-r--r-- 1 root root  19176 Aug 23  2023 apndbplugin.so
-rw-r--r-- 1 root root 367264 Oct  7  2024 binderplugin.so
-rw-r--r-- 1 root root  70592 Sep 25  2024 mtkbinderpluginext.so
-rw-r--r-- 1 root root   6096 Nov 19  2023 rilbinderplugin.so
-rw-r--r-- 1 root root 320424 Aug 23  2023 rilplugin.so

The packaging information in gitlab/ubports/development/core/packaging says that sources of binderplugin, rilbinderplugin and rilplugin are available at mer-hybris at github. (I suppose the other two plugins are not related to setting fast dormancy.)

An ofono plugin initializes driver methods when it is registered. Radio settings are initialized in this struct (defined in sailfishos/ofono/.../ofono/include/radio-settings.h):

struct ofono_radio_settings_driver {
   (...)
   void (*query_fast_dormancy)(...)
   void (*set_fast_dormancy)(...)
   (...)
}

In the mer-hybris binderplugin this structure is initialized (ofono-binder-plugin/src/binder_radio_settings.c line 234):

binder_radio_settings_init() {
   ofono_radio_settings_driver_register(&binder_radio_settings_driver);
}

but binder_radio_settings_driver does not provide fast dormancy methods (line 224). It only sets:

static const struct ofono_radio_settings_driver binder_radio_settings_driver = {
	.name                 = BINDER_DRIVER,
	.probe                = binder_radio_settings_probe,
	.remove               = binder_radio_settings_remove,
	.query_rat_mode       = binder_radio_settings_query_rat_mode,
	.set_rat_mode         = binder_radio_settings_set_rat_mode,
	.query_available_rats = binder_radio_settings_query_available_rats
};

As a result, radio_set_property_handler() in ofono/src/radio-settings.c (line 658) returns "Not implemented":

if (rs->driver->set_fast_dormancy == NULL)
	return __ofono_error_not_implemented(msg);

There are other repositories on github with the same code, but none of them provide fast dormancy methods.

Now what could be next? Of course I could be overlooking things. Is my conclusion right (RIL modem software does not implement fast dormancy)? If so, is it worth fixing? I'd say yes, as the difference in battery usage is large and 2G/3G are being phased out. And if it is worth fixing, then where? The ofono-binder-plugin repository is active. Would this be the place to ask? @lduboeuf can I have your advice once more?

Thanks. I'll check there if I can find why FastDormancy does not seem to be implemented.

Some progress to mention:

• As far as I can tell from the sources, setting FastDormancy should work, but I'm not sure I am looking at the right sources (gitlab ubports development core ofono-ubports)
  For a check:

phablet@ubuntu-phablet:/usr/sbin$ ./ofonod --version
1.29

and

phablet@ubuntu-phablet:/usr/lib/systemd/system$ dpkg -l | grep ofono
...
ii  ofono-sailfish 1.29+git8-0ubports1~20240527210340.1~66073d0+ubports20.04                        arm64        Mobile telephony stack (daemon)
...

• If I run testscript set-fast-dormancy (location mentioned above, from subdirectory test), it responds

phablet@ubuntu-phablet:~/.local/bin$ set-fast-dormancy 1
Setting fast dormancy for modem /ril_0...
Traceback (most recent call last):
  File "/home/phablet/.local/bin/set-fast-dormancy", line 26, in <module>
    radiosettings.SetProperty("FastDormancy", dbus.Boolean(enable));
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 72, in __call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 141, in __call__
    return self._connection.call_blocking(self._named_service,
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 652, in call_blocking
    reply_message = self.send_message_with_reply_and_block(
dbus.exceptions.DBusException: org.ofono.Error.NotImplemented: Implementation not provided

• Testscript get-tech-preference returns:

phablet@ubuntu-phablet:~/.local/bin$ get-tech-preference
Technology preference: umts

and this value changes correctly if I switch to 2G or to 2G/3G/4G

• I added two lines to this script slightly to return all radiosettings:

for p in properties:
    print(p)

It shows:

phablet@ubuntu-phablet:~/.local/bin$ get-radiosettings
TechnologyPreference
AvailableTechnologies

So it seems that my current ofono implementation does not have a FastDormancy setting. @lduboeuf You suggest the reason might be the component in between the modem and ofono. What component is that?

Thanks for this reaction. Looking at the repowerd source explains why I did not find more hits for "FastDormancy": most of the time, it is "fast_dormancy", with an underscore . I'll check if this brings me any further.

One of the topics on my UT-on-Fairphone4-wishlist is to understand what I can do to use the phone's battery optimally. In the past half year I have seen large differences in battery use when the phone is off, so screen off and no active apps (nothing shows if you swipe from the right). The phone used to need a recharge every 3 or 4 days, but currently it is just 1 day, while my daily usage pattern is roughly the same.

I probably changed settings, not knowing this would be the effect. I have now been checking more structurally. What I find is that setting Mobile Connection type to "2G only" or "2G/3G" instead of "2G/3G/4G" causes the full difference. I could have known, as the first options says 'saves battery'. The effect is like what I read in an old post (topic 6211), but that is a different phone (Xiaomi mi A2), and in my case it does not matter whether I turn data on or off. (I have a phone-only SIM-card, no reason to turn data on. Still I checked.)

From the system settings sources (Sim.qml) I see that the options are used to set a property 'technologyPreference' of an OfonoRadioSettings QML component, where '2G only' is 'gsm', '2G/3G' is 'umts', and '2G/3G/4G' is 'lte. In the ofono documentation I also find a Dbus radio-settings API (radio-settings-api.txt), where there is a FastDormancy property which is described as 'a major power-saving feature for mobile devices'. It seems as if this parameter is never explicitly being set in UT: searching the UBports core respositories does not result in hits. But this looks as a possible source of the differences.

I checked if the the modem might be limited, but from what I find on the internet, the FP4 is built on the Qualcomm Snapdragon 750G processor, which includes a modem called X52. This modem does not seem to pose a hardware limitation.

I also find a modem-manager package which might allow me to experiment with the modem. I tried to install it and run it in Libertine container, but from within the container, I do not have access to the Dbus.

So there are my questions: * What is the phone doing in the "2G/3G/4G"-setting that it does not do in the other two settings? * If it is related to the FastDormancy-setting, where is this setting use? Where should I look? Is there a way to experiment with that? * How to get modem-manager (mmcli) to run?

(I'm sorry for not posting links, apparently not enough reputation to do that.)

Thanks!

@danfro Yes I am tryng the tchncs.de bridge. And from a German perspective I am foreign as well, and new. So this may well be the reason. How can I follow the developments?

@Moem (or perhaps @danfro) I tried this today, but I do not get a QR code as a response to the login message. Am I missing something?

I created an account at matrix.org, via the website of Cinny.
I installed Cinny on my FP4 (UT 20.04 OTA-7) from Open Store, the version is recent, so I did not download the click package as some people did further on in this thread.
I created a room and invited the bot.
I opened Signal on my old phone, clicked settings, linked devices and add new device. Then the Signal app appears to be ready to read a QR-code.
On my FP4 I message 'login' to the bot, but then nothing happens.

I would think the statuses have a meaning, but I was not able to find documentation for that. So I'm calling play() for whatever status shows up
From what I tested through clickable desktop I found that Loaded indicates the player is ready to play, and apparently if the status is Loading, it is not. But on the phone no other statuses occur, I tested repeatedly and in a couple of cases I waited for at least 10 minutes for other statuses to show up. No luck.

Thanks for the suggestion, but no, that does not work either. The player status and playback state is 'Loading' & "paused" before onCompleted triggers, and calling play() then doesn't change that.
I tried also with Qt.application.onStateChanged, to see if the application needs to be active, but no difference.

I have made a small QML application with a MediaPlayer with a fixed URL stream source, which I want to start at application startup.
Using clickabe desktop the application works. The players status changes from 'Loading' to 'Loaded', and at this status change play() starts the player. My desktop is Ubuntu 20.04.
Using clickable the application does not work. clickable log shows that the player status remains 'Loading', calling play() only puts the player in playback state 'paused'. My phone is a Fairphone 4, UT 20.04 OTA-7. The apparmor has "policy_groups": ["audio", "networking"],.
For the code see below.
The button is to test for possible permission problems. But that is not the case, if clicked, the stream plays.
What also works is to start a timer (interval 3s) which calls audioPlayer.play().
But that shouldn't be necessary, should it? What am I missing here?

The code:

    import QtQuick 2.7
    import Lomiri.Components 1.3
    import QtMultimedia 5.12
    
    MainView {
        id: root
    
        Rectangle {
    
            anchors.fill: parent
    
            Button {
                id: manualPlay
                text: "Play"
                onClicked: {
                    console.log("Clicked Play")
                    audioPlayer.play()
                }
            }
    
        }
    
        MediaPlayer {
            id: audioPlayer
            audioRole: MediaPlayer.MusicRole
            source: "http://icecast.omroep.nl/radio4-eigentijdsfb-mp3"
            onStatusChanged: {
                console.log("onStatusChanged(): status = ", getPlayerStatus(status), " playbackState = ", getPlayerState(playbackState), " app state = ", getApplicationState(Qt.application.state));
                if (audioPlayer.playbackState !== MediaPlayer.PlayingState) { console.log(" calling play()"); audioPlayer.play(); }
            }
        }
    
        function getPlayerStatus(playerStatusCode) {
            switch (playerStatusCode) {
            case MediaPlayer.NoMedia:       return "NoMedia"
            case MediaPlayer.Loading:       return "Loading"
            case MediaPlayer.Loaded:        return "Loaded"
            case MediaPlayer.Buffering:     return "Buffering"
            case MediaPlayer.Stalled:       return "Stalled"
            case MediaPlayer.Buffered:      return "Buffered"
            case MediaPlayer.EndOfMedia:    return "End of media"
            case MediaPlayer.InvalidMedia:  return "Invalid media"
            case MediaPlayer.UnknownStatus: return "Unknown status"
            default:                        return "unknown player status";
            }
        }
    
        function getPlayerState(playerStateCode) {
            switch (playerStateCode) {
            case MediaPlayer.PlayingState:  return "Playing"
            case MediaPlayer.StoppedState:  return "Stopped"
            case MediaPlayer.PausedState:   return "Paused"
            default:                        return "unknown player state";
            }
        }
    
        function getApplicationState(applicationStateCode) {
            switch (applicationStateCode) {
            case Qt.ApplicationSuspended:   return "Suspended"
            case Qt.ApplicationHidden:      return "Hidden"
            case Qt.ApplicationInactive:    return "Inactive"
            case Qt.ApplicationActive:      return "Active"
            default:                        return "unknown application state";
            }
        }
    
    }

I installed Ubuntu Touch 20.04 (OTA-7) on a Fairphone 4, to renew my involvement in the open source community, and I started to explore UT to see in what way I could contribute - there is a lot to choose from.
As the radio alarm on my old Android phone was never really reliable, I looked for a UT alternative (which does not exist, does it?), and then at alarms and streaming radio.

From the (focal) radio apps in the store, the Radio app (by patrickjane) is fine. Information on the music which playing is initially visible in a scrolling label, but after starting and stopping the player a couple of times, the label only says 'Playing'. Somehow, that became worse, so currently, I never get the music information anymore. So I did the following:

• I downloaded the source and stripped it down to the essentials, used 'clickable' to build and install it on the phone. The metadata never displays, because the onMetadataChanged signal handler is never triggered. On the desktop (Ubuntu 20.04, 'clickabe desktop'), it works as expected (in a Docker container).
• I checked other audio streaming apps for Focal, but none present metadata. From the old Xenial apps (found here), only flas presents metadata, but flas accesses the metadata property of QML Mediaplayer directly, not through a signaling mechanism.
• I have monitored the D-bus on the phone and I see that metadata is presented to the bus by media-hub. It also seems (I'm not sure) that the Radio app listens to the MediaHub Service session which is sending PropertiesChanged signals. These signals contain metadata including titles.
• I also checked apparmor log entries (using journalctl). There are about 15 apparmor="DENIED" entries for a single run of the app (opening, playin a station for some time, stopping the player, closing the app). Two originate from the dbus-daemon, for interface "com.lomiri.content.dbus.Service" and member "HandlerActive", I have no idea if that is related to this bug.

Remarkably, the sound indicator shows music titles on both devices. A 2021 post mentions the issue, with the sound indicator as a workaround. That may work for a user, but from a developer perspective that adds to the riddle.
So I also took a look at the sound indicator. If I understand correctly, audio players can register to the Ayatana sound indicator so that they are displayed in a very minimal way. I did not find any further information on how that works. I have been looking at the source of mediahub and the Ayatana sound indicator to find out, but I get lost.

So I am curious as to what is going on here:

1. What difference between the FP4 and the Docker container on the desktop may cause the metadata signaling mechanism to work differently on both? How can I find out?

2. How do audio players, the sound indicator and the media-hub interact? Does the Radio app register to the sound indicator? And if it registers, why do music titles appear in the indicator, and not in the app itself? If it is a different player that registers to the indicator, which one is that? And how could this player take over the stream playing in the Radio app? Or has it always been there, as a kind of a pass-through player, which is shown by the sound indicator, but then fails to pass on the metadata?

@Moem Thanks. I downgraded to Android 11 before running the UBports installer, and that was successful. It wasn't all first-time-right (see above, had to run fastboot as root), but it was easy enough to find and overcome the obstacles using this forum.

@kevin-lhotellier I'm in the same situation (or similar).

With respect to the command "fastboot flashing unlock" and its response "waiting for any device", and then waiting indefinitely...: what worked for me is to run this command as root in Ubuntu. I tried this after reading a suggestion to run the command 'as Administrator' in Windows, on the Fairphone forum.

With repect to the instruction in UT for FP4: "Your device must be running the Fairphone OS version of Android 11 before installing another operating system. With a previously installed custom ROM, it won't work!", I wonder if a downgrade from Android 13 to 11 is at all necessary. Android 13 is hardly a custom ROM, isn't it?

Any help or experiences regarding this last question?

Thanks!