Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.

Recording Archive is not dump on Repository.

Avatar

Level 2

hi,

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.

thanks,

vishal sood

18 Replies

Avatar

Former Community Member

Hi,

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.

Thanks,

Eyal.

Avatar

Level 4

Hi,

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.

Thanks,

Nikola

Avatar

Former Community Member

Hi,

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,

Eyal.

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>

  <origin>fms1.acrobat.com</origin>

  <proto_ports>rtmfp:1935,rtmps:443</proto_ports>

  <retry_attempts>2</retry_attempts>

</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

Avatar

Level 4

Hi Eyal,

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,

Nikola

Avatar

Former Community Member

Hi Nikola,

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.

Regards,

Eyal.

Avatar

Level 4

Hi Eyal,

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.

Thanks,

Nikola

Avatar

Former Community Member

Yeah, for instance I have a webdav (not telling you where running on

port 4502. Doesn't seem to matter, as long as I specify that in

register-repository.

nigel

Avatar

Level 2

Hi Nikola,

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.

Thanks

Vishal

Avatar

Level 4

Hi Vishal,

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.

Thanks,

Nikola

Avatar

Level 4

Hi Vishal,

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.

Thanks,

Nikola

Avatar

Level 2

hi Nikola,

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.

Thanks

Pankaj

Avatar

Level 4

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).

Thanks,

Nikola

Avatar

Level 2

hi Nikola,

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.

Thanks,

Vishal Sood

Avatar

Former Community Member

Hi,

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:

http://USERNAME:PASS@REPOSITORY_URL

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 .

Regards,

Eyal.

Avatar

Employee

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.

Avatar

Level 4

Hi Vishal,

Any luck with your WebDAV?  Are you sure there are no logs on your WebDAV for authentication use case?  Did you use wireshark or any other tool to sniff out the packets coming to your server?

Thanks,

Nikola

Avatar

Level 4

Hi Vishal,

I just tried your WebDAV server and was able to publish a recording of mine using authentication.  Do let me know if you have been successful as well.

Looking forward to closing this thread

Thanks,

Nikola

Avatar

Level 2

Hi Nikola,

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.

thanks,

vishal sood