Hi Nigel,I guess the point I was confused on is that the server-side script also uses the dev credentials to generate an authToken, but I guess on the server side it creates a unique "session" ID, whereas from the client-side it does not. (Request: PLEASE INCLUDE THIS FACT IN THE NEXT DOCS. This will save someone a lot of time.)It really is a big help to hear that server-side authentication solves that problem.Originally we were going to develop the whole CSR app client-side, and port over relev...

Thanks for your input, that helps.Yes, setting the "Allow Duplicate User IDs" room setting does seems to have done the trick. Mostly.But I have to say, I didn't quite believe it until I saw the duplicate UserIDs for myself.I thought that because unique user names were being generated ("Daniel Lebor [n]"), that the UserIDs would necessarily be unique as well, which is why for the longest time I thought that the Zombie error must be a bug of some sort triggered by the weird Room Console error some...

So I tried modifying the CSR app so that it not only logged into each room session sequentially*, but instantiated the AdobeHSAuthenticator instances sequentially as well. Same results. As you can see from the screenshots, as each CSR app logs in, it ejects the CSR whom is already logged into the prelobby and lobby rooms. So the LCCS service is not creating new credentials for separate authenticator sessions. The debug trace I got from the app on the far left when it was kicked out was:### CSR r...

So I did as you suggested: changed the MXML instantiation of AdobeHSAuthenticator to actionscript instantiation, to occur every time a new session is started. But it doesn't work. The exact same thing happened.And I think I've nailed down the problem, because I finally have figured the predictability of the situation. Mostly. (But not the solution.)So what I did was:Process:1a) I log in to the LCCS app with the Room Console. Then The Room Console user enters/logs into the prelobby.1b) Then I log...

The customer app on the left is completely separate than the CSR app on the right. So the customer app logging back into the prelobby should not be triggering a Zombie Error in both Customer app AND the CSR app, as described above. And the Customer app logs in and out of rooms sequentially, there are no simultanteous connections. Nor should LCCS be promoting the user in the Customer app to HOST when no dev credentials are located in the customer app whatsoever, it simply should not happen.As for...

Here's another weird thing it's doing now which it didn't used to. When the connections hold, and I don't get thrown out of rooms as previously described, this now comes up:When the customer is logged into the CSR room, and the CSR removes the user from the room, the same login function used to logout and into other rooms is used to log the user back into the prelobby room. Except, now when the user logs back into the lobby, he is connected as a HOST, and not a Guest or VIEWER. This used to log ...

And now I'm getting this:Tried it again and the Room Console logged in fine, but that was the first time I'd ever gotten that particular error from the room console...Joseph BaldersonFlex & Flash Platform Developerhttp://joeflash.ca

Okay, I think I finally caught it in the act, so to speak. With logs.First I added some event hooks and visual indicators for the connection status to the rooms in the CSR app:grey = not synchronized/disconnected;green = synchronized/connected;red = an error event.(see screenshots below)I did figure out that the user was indeed getting refused re-entry because of the ENDED state of the room, which was solved when I followed your suggestion and used csrUserManager.removeUser(customerUserID);But t...

It could be that in using STATE_ENDED, the room lands up getting "stuck" in status ended mode when the CSR is booted from the room by the Room Console bug (assuming that's what it is), which could prevent the user from logging back in. But, as you've indicated, the CSR should not be getting booted from the room on account of a "monthly limit" reached in the first place. I'll look into changing that to userManager.removeUser() as per your suggestion tomorrow when I'm back at work and see if it ma...

No worries about the code, just offering in case it helps you debug your Room Console.I'll add a few things to make the debug trace a little more descriptive in indicating events received, and I'll post it tomorrow when I'm in front of my machine again.Thanks again very much for all your help.Joseph BaldersonFlex & Flash Platform Developerhttp://joeflash.ca