Failing bidirectionally, that’s interesting. Can you provide logs of this situation?
Logs are too long to post here. Where would you like them?
If you have a Gitlab account, I would appreciate an issue there with the log. If you don’t, feel free to mail whisperfish [at] rubdos [dot] be
Here you go.
PSA:
Signal is back again
Yep, six minutes after I posted that!
Now I can no longer play audio people have recorded.
The media player opens but says Cannot open somehash.aac . There was no further info in the log I made when running from the cli (with -v).
EDIT: should I return to 3.4, update whisperfish and test there first? I have a number of other problems on 4.1 (some network?) so I’m thinking of going back a step (while I still can).
Can you try copying the file on your computer, and testing whether it plays fine there?
I have the same issue; .aac files won’t play on Media app. Linux Signal Desktop does play them. The sender has an Android Signal.
I think I already have one recording I can inspect and send, if need be.
PS. Network connectivity issues are daily for me, mostly Android apps, but sometimes native apps, too. Sometimes flight mode helps, so I guess it’s the operator/congestion…
By the way, I’m unable to add a device (e.g. to use desktop Signal). Perhaps an issue with “AddDevice.qml”?: cannot enter or paste anything in the “add device” field.
I was unable to find the file. But I’m not so certain some of these problems aren’t sfos 4.1, 4.2 I’ve just flattened the 4.1 install and upgraded to 4.2. I’m testing 0.6 on 3.4 and will begin with 4.2 when I have a moment.
I just tested, I can paste in it. Can you make a bug report, specifically stating the versions of SailfishOS and Whisperfish? Can you try pasting from something else than the QR scanner?
If I just click the audio in WF, playback fails. If I pre-open jolla-mediaplayer
from terminal, and then click the file, it plays just fine.
Running an application from command line bypasses firejail, as it requires a specific Exec command. So, either WF should play the file itself (doable I guess), or copy the file to an accessible location (bad for privacy), or pre-launch the Media app from command line (cumbersome).
Riiiiiight. Okay, we’ll have to push our own player forward a bit then.
Workaround meanwhile is to reconfigure the attachment path in .config/harbour-whisperfish/harbour-whisperfish.conf
to something that the media player can access. We need a FAQ entry for this.
Before I do so, let me describe the issue a bit more, as it’s extremely weird. In the “add device” field, I’m unable to enter or paste anything, UNLESS it starts with “tsdevice://”.
As the code given by QRscanner starts with “signl://”, I cannot use it. No paste, no keyboard entry. Also, trying to enter or paste anything erases the clipboard.
Cool, that means we have two bugs now, because for me the tsdevice://
is not enforced, and apparently Signal changed the code format then.
For the second one, 8442143818 is to blame in Signal Android. Looks like it’s only the schema that changed, so I’ve added support for it in 31b7a1e020d6ba57d4b0165f8c3008b202a2a63c. I’ll edit this post when it’s built on CI with some links for you to test.
Builds of 0.6.0-dev.b1646.31b7a1e
are ready at Package Registry · Whisperfish / Whisperfish - Signal on Sailfish OS · GitLab
- harbour-whisperfish-0.6.0-0.dev.b1646.31b7a1e.armv7hl.rpm
- harbour-whisperfish-0.6.0-0.dev.b1646.31b7a1e.aarch64.rpm
- harbour-whisperfish-0.6.0-0.dev.b1646.31b7a1e.i486.rpm
@Objectifnul, could you test this and let me know whether it resolves the issue?
Thx! Looks like our friend Moxie keeps monitoring your work to make sure he can add/modify something to make Whisperfish obsolete quickly.
Naaaaah, they just unified the sgnl://
prefix. That’s fine by me They do keep me on the tips of my toes though!
Moxie is not the only decision taker any more, and the person that I’m in contact with is being very kind.