Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

Recording archiveIDs with mixed case cause playback issues

Avatar

Level 4

A mixed case ( lower case + upper case ) archiveID for a recorded session has caused me to see my playback to start from zero seconds no matter where on the timeline I "seek" the recording.

Recording AND Playback sets an archive id as such:

x002F_<more_lower_case_text_here>_player_s_17463_t_2011-08-17T11_05_00-04_00.zip  <-- note the upper case "T" in the time stamp

BUT theare 2 problems,

1) In my webdav my recordings are coming back mixed case ( most come back with all characters lower case), as such:

Screen shot 2011-08-17 at 11.21.02 AM.png

2) (Most likely caused by 1st problem) During playback in SessionManagerPlayback.as::subscribeCollection ( lines 156 - 181 ) there's code that never gets executed:

Where you see the "// this is really a seek" never gets executed because "collName" var returns a string "<more_lower_case_text_here>_player_s_17463_t_2011-08-17t11_05_00-04_00/AVManager" where the "upper case T" is now lower case too! which causes the "seekTime" to be "NaN" since look up in _offsetTable[collName] doesn't return a valid number.

Anyone else seeing this? Anyone else can reproduce this ?

Let me know if you need more info

Thanks,

Alex G.

PS. I'm gonna test a temporary solution of lower casing the archiveIDs before my app sets it in the ArchiveManager, but I'd like to know whether I'm crazy or we can expect a bug fix in the future

1 Accepted Solution

Avatar

Correct answer by
Level 4

Hi Alex,

I can reproduce.  I will put it onto our bug queue.  As you mentioned earlier, one should use all lower cased archiveIDs until this is resolved.

Thanks,

Nikola

View solution in original post

5 Replies

Avatar

Level 4

Hi Alex,

I think I mentioned it in a separate thread (and it is included in our ReleaseNotes) , but all pre-release (Aug 4th) recordings will NOT work with LCCS 2.0 (I know, I know).

Could you verify that recordings that experience a mixed-case issue have been made with the latest LCCS 2.0 release?  Their timestamps suggest they are old recordings (pre-release from July).  Furthermore, I believe that all recordings will be PUT to your WebDAV store in all lower-cased names by the LCCS service.  I am not 100% sure on this; I would need to double-check the code.

Hope this helps,

Nikola

Avatar

Level 4

Hey Nikola,

Yes, all the recordinds in questions I'm doing myself and I've been testing since I've integrated with LCCS swc v2.0.0. I expect the sessions recored with LCCS swc 1.5.0 or lower to fail.

Glad you pointed this out though, because it seems everything recorded with LCCS v1.5.0 respected the mixed case archiveID; since integration with LCCS swc v2.0.0 we are now only receiving files that are lower case only ( which we don't expect ).

Alex G.

Avatar

Level 4

Hi Alex,

OK, I think I have misunderstood your initial posting.  Let me see if I have it right.

You have a mixed case archiveID, recording works fine and you end up with an all lower cased recording file on your WebDAV.  You now try to playback this recording, it loads up fine, it even plays back fine, but whenever you try to seek within it you are sent to zero time.  Do I have this right?

I will try to reproduce myself to confirm.

Thanks as always,

Nikola

Avatar

Level 4

That's exactly what's happening. Great let me know what you find

Avatar

Correct answer by
Level 4

Hi Alex,

I can reproduce.  I will put it onto our bug queue.  As you mentioned earlier, one should use all lower cased archiveIDs until this is resolved.

Thanks,

Nikola