PDA

View Full Version : BBC iPlayer - RTMP for non-BBC streams



George_C
2018-12-12, 20:44
Hello again bpa,

Background
I posted earlier in the old thread that the fix you offered a year or so ago, to stream [Egyptian Radio & Television Union] ERTU audio to the Squeezebox Radio didn't work anymore. I was wrong, but a strange issue persists.

Let me explain.

The stream in question is the Local European service of Radio Cairo (and similar streams from ERTU: egradio.eg).

The URL is:

rtmp://liveRadio.onlinehorizons.net/ElBernamegElOrobi -W http://lr.onlinehorizons.net/player.swf -p http://lr.onlinehorizons.net/ElBernamegElOrobi.html -v -y livestream -B 10

The URL processed by the BBC iPlayer plugin and entered as a favorite in LMS is

rtmp://liveRadio.onlinehorizons.net:1935?streamname=bGl2Z XN0cmVhbQ==&app=RWxCZXJuYW1lZ0VsT3JvYmk=&live=MQ== &swfurl=aHR0cDovL2xyLm9ubGluZWhvcml6b25zLm5ldC9wbG F5ZXIuc3dm&tcurl=cnRtcDovL2xpdmVSYWRpby5vbmxpbmVob 3Jpem9ucy5uZXQvRWxCZXJuYW1lZ0VsT3JvYmk=&pageurl=aH R0cDovL2xyLm9ubGluZWhvcml6b25zLm5ldC9FbEJlcm5hbWVn RWxPcm9iaS5odG1s&.mp3

As bpa explained, the BBCiPlayer "uses base64 encoding of the various params so it can be internally passed transparently" hence the conversion.

The next part of the solution was to replace the rtmp.pm file in the plugin with a modified version bpa provided which supports the pageurl parameter (not used for BBC streams).

The strange problem
The result then as now, is that bpa's solution would not work right away. When I tried to play on an SB radio, I'd get 'Connection reset by remote host' on the Radio display, and on the LMS display, it would stop trying to play after a few seconds.

But then and only by chance, I found out that if I synchronized my two SBs to play together, I could start the stream on either of them and the playback would work on both. I could then turn off the player I didn't need to keep on. This I found to be a very strange workaround.

System Information
Additional details:

My Logitech Media Server (LMS) Version 7.7.2 is installed on a QNAP 212P running QTS version 4.3.3.0724. QTS is based on Linux

From LMS Settings (Information Tab)
Operating system: SSOTS 4.x (QNAP TurboStation) - EN - utf8
Platform Architecture: armv5tel-linux
Perl Version: 5.10.0 - armv5tel-linux-thread-multi
Database Version: DBD::SQLite 1.34_01 (sqlite 3.7.7.1)
Total Players Recognized: 2

The two identical Squeezebox Radios (Upstairs and Downstairs) are as follows:

Downstairs
Player Model: Squeezebox Radio
Firmware: 7.7.3-r16676
Player IP Address: 192.168.1.158
Player MAC Address: 00:04:20:2b:13:b5


Upstairs
Player Model: Squeezebox Radio
Firmware: 7.7.3-r16676
Player IP Address: 192.168.1.157
Player MAC Address: 00:04:20:27:29:4e

Two additional Points:

The streams at egradio.eg are very unreliable. They are offline days on in a row and come back to life without explanation. Indeed, there reliability is getting worse. Some of them seem permanently dead. As to the “European Program”, it is the third down on the right at http://egradio.eg/our_extentions/egplayer/.
I know my LMS (v 7.7.2 ) is out of date. It even says that 7.7.6 is available to download. But my version of LMS is QNAP specific and was downloaded the QNAP App store. There may be upgrade paths but I haven’t explored them.


Any help would be appreciated.

gc

bpa
2018-12-13, 02:36
Since the station played OK for long time and then it stoipped - it implies omsehting has changed either on your end, in the network or at the radio end.

The original URL I gave you plays OK on my system with 1.6.1 with the updated RTMP.pm file.

The rtmp:// URL you use for LMS seems to have many additional spaces - for example at the streamname param between the "Z" and "X" "streamname=bGl2Z XN0cmVhbQ"

Please double check that these spaces are not in your LMS favorite.

The stream plays OK and but has a delay at the start. This maybe netwrok related.

Since it plays OK on my system all I can suspect is your QNAP or network. LMS version in this case may not be significant and the armv5te processor is very weak but since you are using Radio it too shoudl not be a problem.

So I think the problem is in the network either your end or the station end - "connection reset by local host" usually means data lost on network conjnection which is not good on a TCP/IP connection. I think syncing two radios together is a weird way of gaining time to setup connection.

I don't think it will help but you could try increasing the WebUI Settings/Advanced/Network/Radio Station Timeout to say 15 secs.

Also check that you have not changed or added new functionality (e.g. new QNAP apps, new LMS plugins, news players, added streaming TV) to QNAP/LMS/network which may be taking resources away from the BBCiPlayerplugin or reduced network availability to plugin.

bpa
2018-12-17, 03:30
Having found an issue with BBCiPlayer plugin - it may be related to your problem ( which I think is complicated by the unreliability of the radio statoin as it is not working for me today)

Do you have any messages in server.log which starts with the following text
"Error: Select task failed calling"

George_C
2018-12-29, 08:55
Since the station played OK for long time and then it stoipped - it implies omsehting has changed either on your end, in the network or at the radio end.

The original URL I gave you plays OK on my system with 1.6.1 with the updated RTMP.pm file.

Actually, nothing new. I found this strange workaround requiring the syncing of two radio players a year or so ago after you first solved my rtmp problem, then got busy with other stuff and did not listen to that station for a while, and forgot about the workaround. In October of this year, I received a Security advisory from QNAP that they "identified an attack that possibly exploits known vulnerabilities in earlier QTS versions", and recommending that users install Malware Remover 3.3.0 app on their NAS. I installed it and ran it, and it removed a file, but I couldn't tell what. I falsely assumed that it was related to your previous mod to the BBCiPlayer. So later when I tried again playing that Radio Cairo rtmp stream and it failed I made the wrong connection, and asked your help again. In effect nothing had changed; the remaining problem was the same, namely the weird need to sync both radio players for either one to play.


The rtmp:// URL you use for LMS seems to have many additional spaces - for example at the streamname param between the "Z" and "X" "streamname=bGl2Z XN0cmVhbQ"

Please double check that these spaces are not in your LMS favorite.

Indeed there were spaces. I removed them and that made no difference. For the record, while I refer here to a single ERTU radio station, I had in fact created favorites in my LMS to several of the other ERTU stations (in Arabic) that all behave in the same manner.


So I think the problem is in the network either your end or the station end - "connection reset by local host" usually means data lost on network conjnection which is not good on a TCP/IP connection. I think syncing two radios together is a weird way of gaining time to setup connection.

I don't think it will help but you could try increasing the WebUI Settings/Advanced/Network/Radio Station Timeout to say 15 secs.

It is already set at 15 secs


Also check that you have not changed or added new functionality (e.g. new QNAP apps, new LMS plugins, news players, added streaming TV) to QNAP/LMS/network which may be taking resources away from the BBCiPlayerplugin or reduced network availability to plugin.

I can't think of anything.


Having found an issue with BBCiPlayer plugin - it may be related to your problem ( which I think is complicated by the unreliability of the radio statoin as it is not working for me today)

Do you have any messages in server.log which starts with the following text
"Error: Select task failed calling"

I don't see that error message. From my monitoring of the station, the stream appears to have been relatively stable for the last week, i.e. since December 23.

Once again thank you, and Happy New Year.

gc