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
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.
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?
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.)
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):
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.
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).
[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
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.
