module.js (line 1)
Script node data failure
When trying to do the same using a teacher's account I just see an endless spinning wheel, the recording never gets unpublished.
We're using Moodle V 2.9.2 and BigBlueButton 0.9.
Any hints are highly appreciated!
I don't see a problem in the code. Take a look to this video. It shows the publish/unpublish actions done by both an Administrator and a Teacher.
There are two parts in this video. In the first part both actions (publish and unpublish) are executed by both users (Administrator and Teacher) using our (Blindside Networks) private infrastructure. There is a delay when executing the action because the way we queue the actions. But still the action is executed.
In the second part I am using test-install (the server that comes pre-configured by default) and the actions are executed immediately. There is no queue for the requests because it is a single server.
Because the response you are getting you may want to activate the console and see if there is another error triggered.
Also, you may want to add this two lines:
error_log('Took ' . $this->info['total_time'] . ' seconds to send a request to ' . $this->info['url']); error_log($this->info['http_code']);
To the file
In the line 3182
$this->info = curl_getinfo($curl);
This way you can see in the logs if the Bigbluebutton server is responding correctly to the requests.
Thank you so much for looking into this issue!
I will troubleshoot using your recommended steps and will report back here.
Here are my first findings:
If I, as a global admin, go into the BigBlueButtonBN activity and click on the unpublish icon on any recording, the wheel starts spinning in an endless loop. The console shows the following:
Action: unpublish module.js:1
unpublish requested module.js:1
I've inserted the additional curl logging into filelib.php and now see that the server is repeatedly polling the BBB API. I've attached an excerpt of the error log to this post. This seems to repeat itself indefinitely.
When I open the following request directly in the browser:
I get the following response:
followed by the meeting's details, including the recording id. Do you have any idea what could have gone wrong here?
Thank you very much.
If you are getting up to this point, the plugin is working as expected.
Action: unpublish module.js:1
unpublish requested module.js:1
The client is pooling the recording and it will keep doing that until the status of the recording changes.
>I get the following response:
>followed by the meeting's details, including the recording id. Do you have any idea what could have gone wrong here?
Well, yeah, this is exactly what I would need to see. What is the status of the recording is it published or unpublished? It must be still published each time you pull the information. If that is the case the unpublish request is not being processed in the BBB server. No idea why.
In your webserver logs, is there a URL like this
before the getRecordings are sent?
What happens if you execute manually the publishRecording request and then the getRecordings request? does the status change?
Since you are not sending all the information I am kind of blind trying to help you. You are going to need to figure out on your own what is happening with the requests.
It is simple, it must be an publishRecording request and then one or multiple getRecordings request(s). And the status must be changed after a few seconds. If that is not happening then the problem is in the BBB server.
Thank you very much Jesus, I appreciate it. If you need any further info from my side let me know, I'll be happy to assist.
Can you please try these versions and let me know if they work for you? I try them out and they worked for me, but I want to make sure.
Many thanks for the updated plugins. I've installed them, purged moodle's as well as my browser's cache but unfortunately the issues remain, However, I had another look at the log files and it looks like that the issue is probably caused by our BBB server.
In the moodle log I see that the following URL gets called first:
...followed by the endless getRecordings polls. I then executed the above mentioned link manually and got:
Following that, I've executed the getRecordings URL manually as well:
and strangely the recording was still published:
So as you pointed out earlier, I suppose that our BBB server doesn't process the unpublish request for some reason? I've had a look in bbb-web.log on the BBB server, however I couldn't find anything that indicates an error. Do you have any idea where I should start looking? For your reference, I have attached the XML responses of the publishRecordingss and getRecordings API calls. If you need any further info please let me know and I'll gladly provide them to you.
Thank you very much for your assistance.
My apologies, I've just figured it out, it turned out to be a permissions issue on our BBB server:
The owner/group of the folder /var/bigbluebutton/unpublished was set to root instead of tomcat7. So as outlined here:
...the following command fixed the permissions issues and I can now unpublish/publish individual recordings without any problems:
chown -R tomcat7:tomcat7 /var/bigbluebutton/published /var/bigbluebutton/unpublished /var/bigbluebutton/recording/raw
Sorry, I should have checked this first. My troubleshooting efforts were focused too much on the Moodle side, but thanks to your guidance I figured it out. Thank you very much!
While we're at it, I might have discovered another small bug in the recordingsBN plugin. Basically in the recordings list of the recordingsbn resource, under the recording date the time zone always refers to the user's local time-zone. E.g If the recording was created on October 5, 2015 at 6 PM GMT +1 a user in a different time-zone will see his own GMT offset and time-zone name, even though the recording was not created in that time-zone , e.g October 5, 2015 6PM GMT +2. Would you prefer that I open a new thread here or shall I open a new issue directly on github?
I am glad you came up with a solution.
I am going to check it out and look how to fix it for the next update, which I am hoping is going to be the stable one.
For cases like this that we know for sure it is a bug in the plugin, you can better open an issue in the tracking system.