[4.5.0.18] French operator SFR: Webradio: no sound

REPRODUCIBILITY: 100% (always)
OSVERSION: 4.5.0.18
HARDWARE: Sony Xperia XA2 - Dual SIM - h4113 - h4113 - 1.0.0.12 - armv7hl
UI LANGUAGE: English (UK) (user: en_GB, os: en_GB.utf8)
REGRESSION: yes (since: 4.4.0.72 - arm)

DESCRIPTION:

The webradio http://www.radiogrenouille.com/live-player/# is not working anymore after 4.4.0.72, with French operator SFR.

PRECONDITIONS:

Have a French SFR dataplan.
Connect to data from this operator.

STEPS TO REPRODUCE:

  1. Open the above radio web page in the stock browser
  2. Press the play button

EXPECTED RESULTS:

Sound should play

ACTUAL RESULTS:

No sound

MODIFICATIONS:

  • Patchmanager: yes
  • OpenRepos: yes
  • Chum: yes
  • Other: none specified

ADDITIONAL INFORMATION:

Device Owner User: defaultuser
Home Encryption: enabled

This webradio is working on the same phone, same user, with a SIM and data from French operator Free.


the initial version of this bug report was created using Bugger 0.9.9+git3

Also a Sony Xperia XA2 - Dual SIM 4.5.0.18 user here. No problem playing the stream with the stock browser.

Thank you for testing.
Happy to hear that there is hope!

I just reflashed but even before, I couldn’t play it.
Very strange…

You are right, with an empty 4.5.0.18 reflashed XA2, http://www.radiogrenouille.com/live-player/# is working.

I found out that the cause of the not working webradio comes from… the operator.

With the French operator SFR, it’s not working.
With the French operator Free, it’s working.
Same phone, same user.
Weird.

When launched from command line:

SFR operator (sound not working):

[ric9k@XperiaXA2-DualSIM ~]$ /usr/bin/sailfish-browser
[D] unknown:0 - Using Wayland-EGL
greHome from GRE_HOME:/usr/bin
libxul.so is not found, in /usr/bin/libxul.so
Created LOG for EmbedLiteTrace
[D] onCompleted:105 - ViewPlaceholder requires a SilicaFlickable parent
Created LOG for EmbedLite
Created LOG for EmbedPrefs
Created LOG for EmbedLiteLayerManager
[W] unknown:0 - QConnmanTechnologyInterface::scanReply() “Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.”
Call EmbedLiteApp::StopChildThread()
Segmentation fault (core dumped)

Free operator (sound working):

[ric9k@XperiaXA2-DualSIM ~]$ /usr/bin/sailfish-browser
[D] unknown:0 - Using Wayland-EGL
greHome from GRE_HOME:/usr/bin
libxul.so is not found, in /usr/bin/libxul.so
Created LOG for EmbedLiteTrace
[D] onCompleted:105 - ViewPlaceholder requires a SilicaFlickable parent
Created LOG for EmbedLite
Created LOG for EmbedPrefs
Created LOG for EmbedLiteLayerManager
JavaScript error: resource://gre/actors/AudioPlaybackParent.jsm, line 16: TypeError: browser is null
[W] unknown:0 - QConnmanTechnologyInterface::scanReply() “Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.”
Call EmbedLiteApp::StopChildThread()
Segmentation fault (core dumped)

Difference:

JavaScript error: resource://gre/actors/AudioPlaybackParent.jsm, line 16: TypeError: browser is null

More errors on the working situation! :upside_down_face:

First post updated.

The stream url itself is http://live.radiogrenouille.com/live

Why use a massive browser when you can stream this url with a dedicated player like sRadio, SailWave, Jupii or SMPC?
Not sure if it will fix your specific issue if it is related to blocking ports, but it makes live easier I think.

1 Like

Hmm…yes, why? Thanks, I just didn’t think of it. Guess I didn’t consider an additional app for a seldom use.
But yes, I now tried sRadio and SailWave. Nice!

But still:
Players won’t play the station http://live.radiogrenouille.com/live neither on the SFR phone.
But if I share the connection with the other XA2, the other XA2’s players will play the station, although the internet access is finally also SFR.

If I swap the simcards and reverse the situation, the same happens:
The phone with the SFR simcard won’t play, but the other one to whom the connaction is shared from SFR, will play the station.

@adekker, can I do something about blocking ports? Is it possible they are not blocking for the phone which benefits sharing?

This bug sounds very strange. Have you checked what happens on the DNS side?
What about tether your Internet connection using SFR to your laptop?

On the laptop, it is working too.

DNS? I’d like to investigate deeper but I’m sorry, I don’t know what/how to check that.
Little hint? :blush:

You need a terminal prompt. From that you would type getent hosts live.radiogrenouille.com. You would get either IPv4 address(es) and/or IPv6 address(es) of stream.radiogrenouille.com and live.radiogrenouille.com (they are the same names for the same service). If you like, you can use devel-su to become root in order to be able to test can they be reached, by making ping -4 stream.radiogrenouille.com if you have IPv4 address or by making ping -6 stream.radiogrenouille.com for IPv6 address. (DNS domain name system, IPv4 and IPv6, and SailfishOS development (devel-su) concepts you may need to find by searching, but the getent command is a good start for understanding.)

2 Likes

Native player can also stream. In /home/defaultuser/Music/playlists folder make a playlist file, with a name, say Radios.pls with this contents (after a while Radios will appear in your playlist):

[playlist]
File1=http://live.radiogrenouille.com:80/live
Title1=Radio Grenouille
NumberOfEntries=1

More streams can be added 2, 3, 4 as you like, update the NumberOfEntries, consequently.

4 Likes

Hey,

I have a Sony Xperia 10 II and my ISP is RED By SFR and I can confirm that the music is not playing with the stock browser.

I have tried the radio with a iceraven (android) and the music work.

I would guess that the issue is in the web browser.

1 Like

Please try the following URL http://95.142.173.193:80/live . If that works and http://live.radiogrenouille.com:80/live does not, your IP does not provide you its IPv4 address in its DNS answer. This seems to be an issue with some operators switching to IPv6. Search this forum for “IPv6” and “CLAT” and “DNS64” to learn more. The latter two are present in Android(s), while not on SFOS.

1 Like

I can confirm what you are saying,

The ip work, but not the dns. Sadly, the CLAT patch for sailfishos does not fix the issue.

The browser understands DNS64/ It would get, for the above URL and IPv6 address http://[2001:4b98:dc0:51:216:3eff:fe2d:9ea] and go happily for it as is going for most of the sites we are using without taking care of IPv4 or IPv6. But is - in this case the site providing the streaming services providing those also with IPv6 and IPv4, or IPv4 only? (I do not know.) But according this diagram [2010-08-10 - project started on the n900! … ] CLAT is not even called since the browser is not an IPv4-only application? (Like the hotspot stack is.) How the IPv4/IPv6 enabled browser can guess that if one asks for a IPv6 address server that is actually an IPv4-one the user wants, and that it should go to CLAT instead to a direct connection? You are right: CLAT is not an answer to this problem (of browser wanted to access IPv4-only-sites, while the IP’s DNS tells only its IPv6 address).

1 Like

Thank you guys for your answers and @canne for the advices.

Both phones are connected through data to their respective operators.

Getent:
On both XA2, (not working SFR and working FREE), I get:

[root@XperiaXA2-DualSIM ~]# getent hosts live.radiogrenouille.com
2001:4b98:dc0:51:216:3eff:fe2d:9ea live.radiogrenouille.com

Ping -4, non working SFR:

[root@XperiaXA2-DualSIM ~]# ping -4 stream.radiogrenouille.com
PING stream.radiogrenouille.com (95.142.173.193): 56 data bytes
64 bytes from 95.142.173.193: seq=0 ttl=56 time=38.227 ms

Ping -4, working FREE:

[root@XperiaXA2-DualSIM ~]# ping -4 stream.radiogrenouille.com
PING stream.radiogrenouille.com (95.142.173.193): 56 data bytes
64 bytes from 95.142.173.193: seq=0 ttl=55 time=162.236 ms

Ping -6, non working SFR:

[root@XperiaXA2-DualSIM ~]# ping -6 stream.radiogrenouille.com
PING stream.radiogrenouille.com (2001:4b98:dc0:51:216:3eff:fe2d:9ea): 56 data bytes
64 bytes from 2001:4b98:dc0:51:216:3eff:fe2d:9ea: seq=0 ttl=53 time=42.363 ms

Ping -6, working FREE:

PING stream.radiogrenouille.com (2001:4b98:dc0:51:216:3eff:fe2d:9ea): 56 data bytes
ping: sendto: Network is unreachable

No IVP6 on the working phone. (!?)

As @pherjung suggested, I also tried traceroute:

Non working SFR:

[root@XperiaXA2-DualSIM ~]# traceroute live.radiogrenouille.com
traceroute to live.radiogrenouille.com (2001:4b98:dc0:51:216:3eff:fe2d:9ea), 30 hops max, 64 byte packets
1 * * *
2 fdff:8440:9999:2011::78 (fdff:8440:9999:2011::78) 35.808 ms 28.965 ms 24.525 ms
3 2a02-8400-1505-fbc3-0000-0000-0000-0001.rev.sfr.net (2a02:8400:1505:fbc3::1) 29.717 ms * *
4 fc00:0:0:101::34a (fc00:0:0:101::34a) 29.066 ms 30.315 ms fc00:0:0:101::34c (fc00:0:0:101::34c) 27.720 ms
5 fc00:0:0:101::34d (fc00:0:0:101::34d) 22.550 ms 23.078 ms 22.148 ms
6 * * *
7 fc00:0:0:101::3f1 (fc00:0:0:101::3f1) 30.042 ms * fc00:0:0:101::320 (fc00:0:0:101::320) 53.761 ms
8 fc00:0:0:101::3f1 (fc00:0:0:101::3f1) 41.301 ms fc00:0:0:101::588 (fc00:0:0:101::588) 36.655 ms gandi.par.franceix.net (2001:7f8:54::154) 30.950 ms
9 et18-1.core-2.csd5.gandi.net (2001:4b98:3:e600::37) 29.761 ms 2001:4b98:3:e600::3f (2001:4b98:3:e600::3f) 34.876 ms 30.567 ms
10 core-2.csd4.gandi.net (2001:4b98:3:e600::27) 30.952 ms 2001:4b98:3:e600::3f (2001:4b98:3:e600::3f) 31.254 ms et18-1.core-2.csd5.gandi.net (2001:4b98:3:e600::37) 36.767 ms
11 Et31-1.dcgw-1b.sd3.gandi.net (2001:4b98:dc2:1f::c301:2) 33.650 ms stream.radiogrenouille.com (2001:4b98:dc0:51:216:3eff:fe2d:9ea) 34.428 ms 33.505 ms

Working FREE:

[root@XperiaXA2-DualSIM ~]# traceroute live.radiogrenouille.com
traceroute to live.radiogrenouille.com (95.142.173.193), 30 hops max, 38 byte packets
1 * * *
2 192.168.7.14 (192.168.7.14) 758.158 ms 36.183 ms 39.549 ms
3 192.168.255.3 (192.168.255.3) 39.802 ms 39.208 ms 39.696 ms
4 194.149.185.80 (194.149.185.80) 39.112 ms 38.837 ms 41.312 ms
5 194.149.173.48 (194.149.173.48) 39.725 ms 37.161 ms 39.388 ms
6 magiconline.proxad.net (212.27.40.194) 75.746 ms 38.200 ms 40.011 ms
7 free.pa3-1.rt.hopus.net (37.77.38.50) 40.170 ms 35.510 ms 40.802 ms
8 gandi.pa3-1.hopus.net (37.77.38.5) 49.174 ms 37.944 ms 39.662 ms
9 et20-1.core-2.csd5.gandi.net (173.246.102.35) 39.405 ms et18-1.core-2.csd5.gandi.net (173.246.102.27) 41.516 ms 38.556 ms
10 et31-1.dcgw-1b.sd3.gandi.net (217.70.176.15) 40.221 ms 35.341 ms et31-1.dcgw-1r.sd3.gandi.net (217.70.176.18) 37.657 ms
11 stream.radiogrenouille.com (95.142.173.193) 37.485 ms 36.463 ms 39.503 ms

1 Like

:partying_face:
At least the IPv4 forcing workaround is working. Many thanks!

About tech point of view and ideal solutions, I don’t know…
But for sure I learned a bit about DNS and IPv4/6 basics.

But what I happily see is that I can listen to this radio into browser or in a media player.with:

http://95.142.173.193:80/live


Neat trick, thanks!

Looks clear that SFR DNS (with SFOS at least) is all IPv6 and the routing is set consequently. While the host live.radiogrenouille.com has an IPv6 address (pingable) it can only stream from IPv4. SFR is by no way blocking IPv4 traffic and with the IP-address (in numbers) you can reach the host and its streamer, by-passing the need for DNS64. Please note that if you use the Playlist.pls file, you need to replace live.radiogrenouille.com with 95.142.173.193 to make it work on your SFR phone. The same for Orange operator in France.

Free looks to be all IPv4 (on SFOS, at least, like we have used and would like to have) and no problem with it to reach the fine radio marseillais. Bonne Ă©coute !

Merci beaucoup for these clarifications!
Yes, I had replaced the name by the IP in the playlist.

So, is that one of the reasons leading people to the manual DNS setting question?

What I don’t understand is why is it working with Android with the same operator.
Does that mean Android is using it’s own DNS and DNS 64 servers?

Android has natively CLAT (thanks to N900…). If the browser is IPv4 only (I sincerely do not know and I couldn’t care less to know it), then CLAT is used despite the IPv6 address is used (see the diagram link above). Another possibility is that Mr. Google has called SFR and Orange and told them that he wants both IPv4 and IPv6 addresses, thank you. If Jolla Oy calls them, it will be “veuillez patienter, un conseiller va vous répondre…” - this is the fact people often forget, the power of Alphabet, Meta and Apple vs. a PME somewhat south from the Polar Circle… Instead of asking from them the impossible world-wide workability out of the box, let’s help them to improve with the community power!

1 Like