Many of our recordings have this message:
Looks like our transcription service is experiencing a problem. Please try
again.
Clicking the try again link does nothing.
What causes this issue and how is it resolved>?
@JohnM12 Sorry, that error message should not appear frequently.
Was your broadcast entirely in English?
Was each meeting hosted from the same device + network?
Yes, all in English and from the same device and network.
Does this happen when there are too many transcription errors?
We have 1 user that has this recording on all of her recordings, another that is about 66% of the time, others don't seem to get this error at all. We are all on the same network and using the same model of laptop computer.
@JohnM12 It can happen infrequently, but should not be happening all the time.
Would you be able to test a new GoToMeeting recording now, from the same network?
If not, could you test a new recording from a different network?
@JohnM12 We are interested to confirm that the Transcripts functionality is working for new recordings on your account. If not, then we'd like to fully document your work environment through a call to our Support group.
Sorry for the delay. I've been looking for a common denominator with this issue. Some of our presenters are on-site (corporate network), others at remote sites (private internet service with corporate VPN connection), some use headsets, some use speaker mic's... lots of variable indeed, yet none of these pointed back to the error message that we are seeing.
Then this morning I believe that I found this issue... the length of the session\recording. What I found is that any meeting equal to or over 175 minutes displays the message as seen in my original post. Meetings less than 175 minutes all have the transcription displayed:
So, is there a know time limit and, if so, is it the recording time (not including pauses in the recording) or the total meeting time?
Thanks
@JohnM12 Thanks, John. We have a ticket up for this issue now, and expect a full resolution soon. When complete, we will update this thread with more info.
@JohnM12 It should be the actual recording time / file size in our database that causes the issue.