Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebPlayer not working properly, start button gives JS error #461

Closed
Power2All opened this issue Mar 6, 2018 · 40 comments
Closed

WebPlayer not working properly, start button gives JS error #461

Power2All opened this issue Mar 6, 2018 · 40 comments
Assignees
Milestone

Comments

@Power2All
Copy link

Play button on website is bugged.
Seems it tries to do a action, but it doesn't exist.
Disabled any blocking addons but nothing.
Here a screenshot of the log:

image

@Robbt
Copy link
Member

Robbt commented Mar 6, 2018

This hasn't happened to everyone, someone previously reported this but then closed it suggesting the problem was with their browser see #403 - I think it might be that the HTML5 player isn't working whereas the flash one does work. We should obviously do more testing to try to figure out why this doesn't consistently work for people.

@Robbt Robbt closed this as completed Mar 6, 2018
@Robbt Robbt reopened this Mar 6, 2018
@Robbt Robbt added the is: bug label Mar 6, 2018
@Power2All
Copy link
Author

jplayer should work fine.
I've been using it too for my own streaming purposes.
How to solve it, I'm not sure, since I use a different implementation on my own PHP projects, using Laravel.

@hairmare
Copy link
Member

hairmare commented Mar 6, 2018

IMO #249 might track this to some extent. The radio page player seems to use muses and has issues with some rare browser edge cases. The plan is to replace it with jPlayer in an effort to fix this while also consolidating our lib usage. It was unclear why legacy upstream decided to use multiple Javascript frameworks for this and the flash issues being reported only seem to affect muses and not jPlayer.

@Power2All
Copy link
Author

Power2All commented Mar 7, 2018

Alright.
Webplayer works fine on standard Chrome.
Opera's browser (latest and current one based off Chrome) doesn't work.
Chrome for Android doesn't play neither the stream, although it says it's playing.
Tested AAC, MP3 and OGG, but none is playing on mobile.

Would indeed be nice to switch to jplayer, which does work on all browsers.

@Robbt
Copy link
Member

Robbt commented Mar 18, 2018

I just noticed my station is running into this on all of the HTML5 browsers specifically firefox whereas it wasn't an issue before.

I noticed this error -
Cross-origin plugin content from http://hosted.muses.org/muses-hosted.swf must have a visible size larger than 400 x 300 pixels, or it will be blocked. Invisible content is always blocked.

As well as these -
4mrp.js?3:137 Uncaught TypeError: g.instance.playSound is not a function
at Function.g.play (mrp.js?3:137)
at MusesPlayer.play (player?stream=auto&title=Now Playing:172)
at HTMLSpanElement.onclick (player?stream=auto&title=Now Playing:383)

@wifiblog
Copy link

Hello,
All worked well on "Microsoft Edge 41" and "Opera" until I install Adobe Flash Player tonight, there is an error on the play button of the main page but not the player interface "listen" to the Dessou of "live".
After uninstalling "Flash Player Adobe", everything comes back normal.
I think "Flash Player" is not for nothing in this malfunction.
Hope this will help you.

PS: I am French, I use google translate to communicate.

@Power2All
Copy link
Author

This problem is still happening.

@Robbt
Copy link
Member

Robbt commented Jan 17, 2019

Yes, yes it is. The webplayer widget is pretty buggy and one thing we need to do is some solid testing to determine what OS & browsers it works on and where it fails. We might want to encourage an alternative browser as well and provide documentation for it. Many browsers can listen to icecast streams natively at this point and the best practice for embedded players on websites appears to be a permanent top banner vs. a widget only on a front page. That way people can browse the site and listen at the same time. I haven't invested the time yet into determine what the "solution" for this problem is.

@Power2All
Copy link
Author

@Robbt Wasn't jplayer not a solution to solve this ?
jplayer seems to work for all major browsers and even older ones with a flash fallback.

@frecuencialibre
Copy link
Contributor

@Power2All would you be interested in creating a PR that addresses this issue and probably also #249 ?

I ask because I think project maintainers are currently focused on other big release blockers, like getting LibreTime running on ubuntu 18 / debian 10 with updated packages that will fix a whole bunch of bugs. I personally am more focused on javascript than others and would love to help land this, but have a backlog of other issues i need to address first.

@Robbt
Copy link
Member

Robbt commented Jan 19, 2019

Yeah this has been on the back of my mind gnawing at me because I'm sure it results in people not listening to my station when they run into the broken widget so I plan on fixing it eventually if someone else doesn't step up first.

@Robbt
Copy link
Member

Robbt commented Oct 9, 2019

So this is something that someone moderately familiar with javascript and modern HTML5 audio players could help by replacing the flash/javascript hybrid based one we are currently using, it should be able to play a Icecast stream. The widget code is setup here - https://github.com/LibreTime/libretime/blob/master/airtime_mvc/application/views/scripts/embed/player.phtml and at https://github.com/LibreTime/libretime/blob/master/airtime_mvc/application/controllers/EmbedController.php and are using players located here https://github.com/LibreTime/libretime/tree/master/airtime_mvc/public/js/airtime/player.

What someone who happens to want to help fix this for Hacktoberfest could do is at the minimum test it out on different browsers and/or put together a PR to use something else or avoid the Muse based swf one since that should never be used with any modern browser that all support playback via HTML5 (I think)

@Power2All
Copy link
Author

I would say, look at jPlayer.
It support icecast, and supports MP3 and AAC codecs, but it also depends on what browser.

@wifiblog
Copy link

Hello,
with flash install:
Dashboard / stream-player => works
embed / player? stream = auto & style = premium => does not work
May be more attentively watch the Dashboard player to improve the player present in embed ..... what do you think?

I am french, I use google translate, sorry for my english.

@wifiblog
Copy link

I made this reader quickly:
https://panel.radio2jeunes.fr/embed/player2?stream=auto&style=premium

In your test, tell me what you think.

Url modified sources for testing:
https://panel.radio2jeunes.fr/sources.zip

@Robbt
Copy link
Member

Robbt commented Oct 17, 2019

Thanks @wifiblog do you know how to open up a pull request via github so we can accredit you with the modification ? Or do you just want someone else to do the work of testing and integrating it with the codebase. Either way we thank you for your contribution.

@wifiblog
Copy link

I'm sorry I do not know how to do with github, but the code still needs to be reworked, it is not finished in my imble opinion.
I want to learn how to do github for accreditation (I will try), but it is urgent that our radios work, so do the best.
I remain available for any questions.

I remind you that I use google translate, I speak only French.

@Power2All
Copy link
Author

I'm sorry I do not know how to do with github, but the code still needs to be reworked, it is not finished in my imble opinion.
I want to learn how to do github for accreditation (I will try), but it is urgent that our radios work, so do the best.
I remain available for any questions.

I remind you that I use google translate, I speak only French.

Pourriez-vous m'envoyer autrement les modifications que vous avez apportées aux fichiers, je pourrais alors faire un effort pour vous et vous faire crédit également.
J'avais prévu de changer de lecteur avec jPlayer moi-même un peu plus tard, mais je ne l'ai pas encore contourné.
Si vous aimez bien sûr, sinon, je vous laisse le découvrir vous-même.

Cela se fait également via Google Translate. ;)

@wifiblog
Copy link

@wifiblog
Copy link

if that's what you're missing:
https://github.com/wifiblog/html5player-libretime

@Power2All
Copy link
Author

Power2All commented Oct 18, 2019

Drupal is pissing me off

@Power2All Are you using LibreTime + Drupal? We're hoping to bring some folks together to work on integration. https://discourse.libretime.org/t/any-interest-in-libretime-available-as-a-saas-with-hosting-and-support/121/23?u=gusaus

I am using Drupal at my job, but I don't like it's structure.
Personally I use OctoberCMS for my websites right now, which I think is much better.

I'm more of a Symfony + Laravel fan, so to speak.
I might make a integration with OctoberCMS as a module sometime later.

@caveman99
Copy link
Contributor

Wifiblog put the changes on https://github.com/wifiblog/playerHtml5-Libretime which worked for me on the public radio website with one minor change. I am porting the fix to the player inside the login area and can provide a PR afterwards if neccessary. CAVEAT: Modern browser securtity checks will require an icecast2 with SSL support for this to work. But this change is neccessary anyways. Fix for this is to use icecast from the Xeph repository instead of the ubuntu stock version and modify the icecast.xml accordingly. (Ref: https://mediarealm.com.au/articles/icecast-https-ssl-setup-lets-encrypt/ )

@paddatrapper
Copy link
Contributor

Requiring Icecast 2 from external repos will break many installations and prevent us from getting LibreTime into Debian/Ubuntu. Stock Icecast can still work behind a reverse proxy that handles SSL.

There is good news though - From version 2.4.4-2 (uploaded in November 2019), SSL support is compiled into Icecast in Debian/Ubuntu (Debian Bullseye and Ubuntu 20.04).

@caveman99
Copy link
Contributor

Well, in modern browsers the web player that is bundled is not working. So there's nothing much to break. Maybe add documentation how to change over on the (for now) default Ubuntu 18 and happily use the distro icecast on Ubuntu 20.

@Robbt
Copy link
Member

Robbt commented Jul 22, 2020

So this would be great to figure out and put a fix into the core. If it requires an external repo for supported distros then perhaps it would be good to add some tested instructions to docs that we can add to release notes.

I think that there are some upstream changes require to PropelORM before we can support Ubuntu 20.04 due to php changes. So we will have to do some other work to take advantage of that.

valerio-bozzolan added a commit to BorderRadio/libretime that referenced this issue Nov 28, 2020
@zklosko
Copy link
Member

zklosko commented Dec 14, 2020

I think I found the problem (using console.log(playerhtml5_audio.src):

Screen Shot 2020-12-14 at 12 58 25 PM

The variable is pointing to a stream source of 127.0.0.1:8000/airtime_128, or localhost. If you aren't testing the microsite on the computer or VM itself Libretime is installed on, you're going to get the error. It needs to be changed to /airtime_128. If only there was a way we could port forward the 8000 port to the 80 port on /streams/airtime_128...

I also commented out code on the line the error occurred on because it would add ?randnumstring to the end of the source URL. I'm not sure if the rand num functions there were needed in the first place...

playerhtml5_audio.src = this.settings.url; //+'?'+Math.floor(Math.random() * Math.floor(100000));

@paddatrapper
Copy link
Contributor

@zklosko moved that discussion to #1133 as it is unrelated and caused somewhere else

@k-apc
Copy link

k-apc commented Dec 17, 2020

I fixed it locally by changing forceHTTPS from true to false at /usr/share/airtime/php/airtime_mvc/application/views/scripts/embed/player.phtml and then swapping from Default Streaming to Custom / 3rd Party Streamingat https://example.org/preference/stream-setting so it uses the fqdn instead of 127.0.0.1.

I would say we can add a parameter to the installer (sudo bash install -fiap) to specify either if it's a development instance or a live/production one. If dev it should just set forceHTTPStofalse` as above and that's it. If it's a production instance a fqdn should be provided, and the installer should deploy ssl certs using certbot both for the Icecast2 server and Libretime's vhost.

@zklosko
Copy link
Member

zklosko commented Dec 31, 2020

After making changes suggested by @k-apc, the problem is still persistent on new installs. It appears the stream settings are not being read in correctly from the config file (the config file is being written correctly).

@k-apc
Copy link

k-apc commented Dec 31, 2020

hi @zklosko,

thanks for trying it out! I'm sure this works at least on Debian Buster (10) when using a fqdn.

diff --git a/airtime_mvc/application/forms/StreamSetting.php b/airtime_mvc/application/forms/StreamSetting.php
index fe4c2bcc6..e41869712 100644
--- a/airtime_mvc/application/forms/StreamSetting.php
+++ b/airtime_mvc/application/forms/StreamSetting.php
@@ -83,7 +83,7 @@ class Application_Form_StreamSetting extends Zend_Form
         $custom = Application_Model_Preference::getUsingCustomStreamSettings();
         $customSettings = new Zend_Form_Element_Radio('customStreamSettings');
         $customSettings->setLabel(_('Streaming Server:'));
-        $customSettings->setMultiOptions(array(_("Default Streaming"), _("Custom / 3rd Party Streaming")));
+        $customSettings->setMultiOptions(array(_("Localhost / Development Server"), _("Public / Production Server")));
         $customSettings->setValue(!empty($custom) ? $custom : 0);
         $this->addElement($customSettings);
     }
diff --git a/airtime_mvc/application/views/scripts/embed/player.phtml b/airtime_mvc/application/views/scripts/embed/player.phtml
index 6b4b2cfb4..d46131306 100644
--- a/airtime_mvc/application/views/scripts/embed/player.phtml
+++ b/airtime_mvc/application/views/scripts/embed/player.phtml
@@ -21,7 +21,7 @@
             this.settings = {
                 'elementId': id_element,    // leave alone
                 'autoplay': false,          // or true (only works on some browsers)
-                'forceHTTPS': true,         // or true if the stream is in SSL (beware of the listening port, usually 8000)
+                'forceHTTPS': false,         // or true if the stream is in SSL (beware of the listening port, usually 8000)
                 'replacePort':false,        // false for disabled or '8000' as the usual start port, forces to specify replacePortTo.
                 'replacePortTo':''          // either '' to use the default port of the browser (80/http, 443/https) or '8443' to force the port of the stream.
             };

after that I just need to go to http://example.org/preference/stream-setting and change Localhost / Development Server to Public / Production Server.

I'm working on what I proposed to do on here and submit a better patch instead of just this workaround.

Hope it helps and happy new year!

@zklosko
Copy link
Member

zklosko commented Jan 1, 2021

Happy new year!

I'm confident the issue is with reading/setting the database with initial stream values. The defaultdata.sql file sets the default host in the database to 127.0.0.1 (localhost), the config file is being set correctly in the setup wizard. However, the setup wizard doesn't appear to be updating the database when it is being run.

It's a tale of two functions: getStreamData() fetches from the database and doesn't work out of the box whereas getDefaults() reads from the config file and does work out of the box.

Database at init:

 s1_enable                       | true                       | boolean
 s1_output                       | icecast                    | string
 s1_type                         | ogg                        | string
 s1_bitrate                      | 128                        | integer
 s1_host                         | 127.0.0.1                  | string
 s1_port                         | 8000                       | integer
 s1_user                         |                            | string
 s1_admin_user                   | admin                      | string
 s1_mount                        | airtime_128                | string
 s1_url                          | https://libretime.org      | string
 s1_description                  | LibreTime Radio! Stream #1 | string
 s1_genre                        | genre                      | string

@hairmare I know you're good with PHP. Hoping you can take a look at it.

@k-apc
Copy link

k-apc commented Jan 1, 2021

Looks like we are seeing two different things. I trust @zklosko about it being related to the database, but I know for sure that changing forceHTTPS from true to false( airtime_mvc/application/views/scripts/embed/player.phtml) and switching Default Streaming to Custom / 3rd Party Streaming at http://example.org/preference/stream-setting makes it work.

Also, even if fixing the getStreamData() function does the settings trick, the player won't work unless icecast has tls/ssl certs in place because https is hardcoded at airtime_mvc/application/views/scripts/embed/player.phtml

ps. I added INSERT INTO cc_pref("keystr", "valstr") VALUES('using_custom_stream_settings', '1'); to defaultdata.sql but even though it inserts the correct value into the database and shows the Custom / 3rd Party Streaming active at http://example.org/preference/stream-setting the player still tries to connect to 127.0.0.1, so I needed to switch it to Default Streaming and back to Custom / 3rd Party Streaming for it to work.

@zklosko
Copy link
Member

zklosko commented Jan 1, 2021

switching Default Streaming to Custom / 3rd Party Streaming at http://example.org/preference/stream-setting makes it work.

Exactly. Toggling that option or saving the form causes a database write, which inserts the correct values.

changing forceHTTPS from true to false

This is also a problem. IMO, it would be easier to get everything to work on unsecured HTTP to allow simple on-network access for those deploying that way and encourage the use of a reverse proxy for users who plan on exposing their Libretime instance to the internet. Issues have been had with NGINX; do Lighttp or Caddy work? Something we definitely need to work on.

@paddatrapper
Copy link
Contributor

Fixed in #1145. Integration with config file tracked in #1147

@zklosko
Copy link
Member

zklosko commented Jan 1, 2021

The mount point in models/StreamSettings.php still needs to be fixed. It's currently configured for Airtime Pro usage.

@paddatrapper paddatrapper reopened this Jan 1, 2021
@zklosko
Copy link
Member

zklosko commented Jan 1, 2021

@paddatrapper #1148

@paddatrapper
Copy link
Contributor

Fixed in #1148

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants