Jump to:
| Project: | CDN2 Video |
| Version: | 6.x-1.1 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | acstewart |
| Status: | closed (fixed) |
Issue Summary
We're doing some testing with the CDN2 module (we do have an approved paid account with workhabit) and are having some trouble getting videos to display on a site thats hosted on a development server that's not web accessible (but can of course access the web). The URL of the development site that we provided CDN2 is the same URL of the intranet site, so there's no issues there.
I should point out that when we uploaded videos, it worked fine, but then when we view the video from the front end, it still says "Your video is still processing. Once it is complete it will be displayed here." even after a few hours of waiting.
Can anyone shed some light on this? Would it be a problem with the player, or the workhabit service (maybe an intended effect for security reasons?). I've tried contacting workhabit directly, but don't seem to be getting anywhere yet.
Comments
#1
The CDN2 module has an xmlrpc callback method that is required to be on the net. Basically when you finish uploading a video the transcoding server will start the transcode(or put it in the queue), once it is finished it will hit the URL you provided WH with which lets drupal know the video was Finished transcoding, and it will give the final information about it(URL, meta data).
Im not sure if there is a workaround for you, other than putting a public facing xmlrpc that forwards the information to your intranet drupal server.
#2
Hey Kyle, thanks for the prompt response!
I'm no API/systems developers, but couldn't:
- on submission of the video, the CDN2 network returns some unique/encrypted identifier response code that is stored on the drupal sites end.
- when the video is viewed (and until the video has finished transcoding), the drupal site requests the URL/metadata (and caches these) from CDN2 using the unqiue identifier?
There's probably flaws in that logic, but I'm sure it can be worked around. The fact that CDN2 requires a site to be publically accessible is a real nail in the coffin imho, i.e. what about sites that are public but have htacesss password protection in place (maybe because they aren't ready to go live yet)?
Thanks again for the prompt response!
- Alex
#3
Typically we recommend that people disable htaccess for the xmlrpc.php callback. It's authenticated using a different mechanism, so it is still secure.
We've been discussing offering a "polling" mode for drupal sites that for whatever reason can't support xmlrpc (either because they're behind a firewall, have an internal IP, or are a dev site that's different than production). Currently that requires some changes to our backend that we're evaluating the performance impact of.
We'll keep you posted.
#4
#5
I'm reopening this bug as we have a solution for this. The module will be making requests on cron to the backend for fetching of data.
We are doing it this way to prevent a latency in requesting metadata from slowing down the response to browsers, as that will cause a performance issue.
#6
Thanks for the update acstewart. Have these changes been committed to the cvs yet or if not, when you do you expect them to be. Thanks!
#7
alexkb: Not yet.. I'll post a note here once we get something in place for it.
#8
Solution has been committed to HEAD
Expect this in the next release, and if you need it now, as always, wiat for the dev snapshot to be generated or checkout from cvs.
#9
Automatically closed -- issue fixed for 2 weeks with no activity.