i have setup the Repository server and registered for Adobe as per requirments.
but still not able to find any file from adobe.
i have setup some recording for verification but i am not able to watch recording live(playback) neither it dump on Repository server.
Now i registered a new webDev (with authentication) server for Repository, its not working for me.
but when i registered without autentication , its working fine.
Even we check at our level, by pushing file from other server with authentication. its working fine again.
but from adobe, files were not dumped.
Please help, its the last thing for me to implement adobe screen sharing.
Well, in the back-end we just use curl, so you should try to access your repository via curl using the request you are registering.
curl -k -i
We let curl do the validation (I am pretty sure in this particular case curl returned an error). The problem is that since this an asynchronous operation currently there is no way to report an error back to you if, for any reason, accessing the repository doesn't succeed.
Not sure if it will help but today we've tried again to enabled Digest authentication and were successful.
The problem was that the repository URL we provided wasn't valid - by mistake the user:password part was before the "http://" and not after.
Try to validate that the URL you provide is according to the format:
We are using apache as the webdav server.
I think it would have been great if as a user i could call a specific server side method (like register repository) which would try to test the connection and return all the available information .
we had tried lowercase authentication but result is same. fail to connect.
can you please check the reason why we have had this issue from Adobe because
when we have tested our devWEB server from other server for dumping file it has no issues every thing going fine.
I have no idea why your WebDAV authentication would be failing. I am using it for my testing all the time; we definitely support it. I would strongly recommend you turn on as much verbose debugging on your WebDAV server as possible and identify your problem in that manner. The only suggestion I can think of is to try lower casing your authentication credentials (just in case).
As you mentioned in your previous post , we changed the repo to default http port with authentication , still the upload failed. This was the first time we got a connect from you server.
Then we disabled webdav authentication as well with default http port and we have the recording file now.
But , We cannot have webdav on internet without authentication.
Also please let us know why the uploaded failed with default http port and authentication? Though webdav authentication is working fine.
I had a look at our production logs. I have several suggestions:
1/ I see "lots" of register-repository calls. You only need to register-repository once; LCCS will store this information for any subsequent recording usage. I would suggest registering somewhere in the admin side of things. Perhaps you are already doing this and were just sending repeat requests because recordings did not work yet. But I thought it worth mentioning.
2/ You are using both the WebDAV authentication and a non-default port. While we support both of these use cases, I would revert to step-by-step approach until you build up to the full authentication and the port desired.
A/ default port and no authentication
B/ specific port and no authentication
C/ specific port and authentication
That said, I was able to both ping your WebDAV server and telnet to it on the default http (80) port.
Yes, when you stop recording, LCCS service should then publish a recording zip file to your WebDAV repository. You manage the repository via LCCS server-to-server APIs. The same way you use register-repository to register a WebDAV repository, you can validate the registration via repository-info call. It should return you the currently registered repository with your LCCS account.
As for debugging why publishing does not work I would start with your WebDAV server logs. Once I get into office I will check our production logs to see what is going on with your particular recording session.
When we stop the recording , it should be publish in our WebDAV server , right?
But we have nothing in webdav logs as well and no recording got uploaded there.
We are not even sure that if our reposiroty got registered or not , if you have it in your logs , can you please manually verify and confirm.
If you require our webDAV credentials , we have not problem in shring that as well.
We have verified our webdav server manually and its working fine.
It should not matter what port you are using as long as you have the port open and configured correctly.
As long as you have the right URL (ports included if not default) set through register-repository API, I think it should work.
Let me know if non-default port does not work for you.
We Figured out the problem,
Our WebDav server wasn't on the default http port.
When changing it to be on the default one the file is uploaded and contains a valid recording.
Before making the change, retrieving the repository information did contain the correct port information.
Do you only support the default http port ?
The playback still doesn't work but i have several things i want to validate.
Will post back in case we weren't able to make it work.
Thanks for your support.
Thanks for posting your logs. I looked into them and could not see anything wrong. I also tried to use your repository (as retrieved from our production logs) but I was unable to use it. It keeps bouncing me off with "operation not permitted" error. Here are all the logs I got from the attempt:
== Info: About to connect() to 184.xxx.xxx.xxx port zzzz (#0)
== Info: Trying 184.xxx.xxx.xxx... == Info: Operation not permitted
== Info: couldn't connect to host
== Info: Closing connection #0
I suggest you ensure your WebDAV server is working properly with requests coming from inside and outside your local network. I know you said you've tested that but I am not sure what else to suggest at this point. I was able to ping your IP, I was not able to telnet to the supposed telnet port. I was able to telnet to port 80 (default http port). Maybe a misconfiguration?
Hope this helps,
Thanks for the reference but our current problem is that we don't see any access to our servers and not authentication problem as in the other thread.
validated that the repository url is configured to the correct location
We are using apach2 with the webdav module, currently without authentication.
followed is a log from the execution of the sample Recording application.
After the execution i could see that a recording was created using the developer portal.
Is there a location in which the "recording upload request" is available? (will also help for future debugging)
If not, using the log bellow, can you tell if a request was made to our servers and what was the error ?
Thanks for the help,
Tue Aug 30 15:02:26 GMT+0300 2011 LCCS SDK Version : 2.0.0 Player Version : WIN 10,3,183,7
15:02:26 GMT+0300 requestInfo https://collaboration.adobelivecycle.com/XXXXXX/rectest?exx=eDpSZWMxOjp2Y2l0YW1lZXRpbmdzOjk6cmVjdGVzdDoxMDA6YThiZGZhNGNmYmYzMjg4MTU4ZDNjOGVmZWU5YTk1Nzk5MzIwNTcyZQ==&mode=xml&x=0.5586258294060826
15:02:27 GMT+0300 #TicketService# ticket received: g9sghendicr2
15:02:27 GMT+0300 Getting FMS at https://na2.collaboration.adobelivecycle.com/fms?ticket=g9sghendicr2&proto=rtmfp, attempt #1/3
15:02:28 GMT+0300 result: <fms>
15:02:28 GMT+0300 protocols: [object ProtocolPortPair],[object ProtocolPortPair]
15:02:28 GMT+0300 [attempt 1 of 2] Connecting to 0/1: rtmfp://fms1.acrobat.com/cocomo/na2-sdk-4d607b19-0246-47b2-8045-069bfc6a0c5d/rectest #startProtosConnect#
15:02:31 GMT+0300 tempNetStatusHandler 0/2,NetConnection.Connect.Success
15:02:31 GMT+0300 isTunneling? false
15:02:31 GMT+0300 is using RTMPS? false
15:02:31 GMT+0300 RECEIVED LOGIN AT SESSION
15:02:31 GMT+0300 .user descriptor from server [object]
15:02:31 GMT+0300 \\
15:02:31 GMT+0300 .role [number]= 100
15:02:31 GMT+0300 .affiliation [number]= 100
15:02:31 GMT+0300 .displayName [string]= Rec1
15:02:31 GMT+0300 .userID [string]= EXT-XXXXXX-9
15:02:32 GMT+0300 RECEIVENODES UserManager
15:02:32 GMT+0300 receiveAllSynchData UserManager
15:02:32 GMT+0300 RECEIVENODES FileManager
15:02:32 GMT+0300 receiveAllSynchData FileManager
15:02:32 GMT+0300 checkManagerSync:[object FileManager]
15:02:32 GMT+0300 RECEIVENODES AVManager
15:02:33 GMT+0300 receiveAllSynchData AVManager
15:02:33 GMT+0300 checkManagerSync:[object StreamManager]
15:02:33 GMT+0300 RECEIVENODES RoomManager
15:02:33 GMT+0300 receiveAllSynchData RoomManager
15:02:33 GMT+0300 checkManagerSync:[object RoomManager]
15:02:33 GMT+0300 checkManagerSync:[object UserManager]
15:02:34 GMT+0300 RECEIVENODES myCamera
15:02:34 GMT+0300 receiveAllSynchData myCamera
15:02:34 GMT+0300 RECEIVENODES simpleNote
15:02:34 GMT+0300 receiveAllSynchData simpleNote
15:02:34 GMT+0300 RECEIVENODES swb
15:02:34 GMT+0300 receiveAllSynchData swb
We had previously reported issues with how particular WebDAV servers work with our recording feature. This forum thread could prove useful in that regard: http://forums.adobe.com/thread/883194
Any logs from your end would be useful as well. Specifically, any WebDAV server logs.
We have been experiencing the same thing.
I have registered the repository and created several recording using the sample application (with and without archiveId), but no upload request have been made to our WebDav Server.
Looking at the developer portal i see all the recordings we've made.
Is there a way to debug this and see what is causing the error ? couldn't find any location in which logs are available for the upload / download process using the repository.
I validated that the repository information is correct (we aren't using a token and we've tried with and without Authentication) and that manual uploads are working.
Please let me know if additional information is required.