Quick question here. You *ARE* using the RoboHelp Server? Because if you aren't, FlashHelp Pro will do you about as much good as a diesel engine does for a go-kart.
Helpful and Handy Links
Rick -- yes we are using RoboServer 8.
Have you tried opening a sample project and adding some FlashHelp Pro outputs to that to see if the same problem occurs?
You will find the samples at
C:\Program Files\Adobe\Adobe RoboHelp 8\RoboHTML\Samples\en_US
C:\Program Files\Adobe\Adobe Technical Communication Suite 2\Adobe RoboHelp 8\RoboHTML\Samples\en_US
See www.grainge.org for RoboHelp and Authoring tips
Peter -- yes, I have a test project and have tested it in there, and I created a new Master Template Project from scratch and entered components in piece by piece. Meaning, I created a CSS, then Master Pages, then setup the resource manager, then windows, then conditional tags. There were no issues until I started adding FlashHelp Pro layouts. After the 4th one is added there is a huge impact on the system. The more we add the slower it gets to the point that the whole computer becomes non-responsive for up to 7-8 minutes or longer in some cases.
This is frustrating my new RH authors and though I'm used to RH being slow, this is way abnormal. Never seen this before at previous clients. Nor come to think of it, in previous versions. I was using RH7 and RH Server 7 at my last client with 6 Pro outputs and don't remember this being an issue.
Any suggestions would be extremely helpful, I think our last nerve is being tested here.
I can't create it but what you have set up is not the same as I suggested. You have set up everything you want and then added the layouts. What we need to do is establish that it is the layouts alone, not the layouts plus something else in what you have set up where that something alone does not impact. That would lead you to your conclusion but it could be wrong.
Please just open a sample project and add some layouts, nothing else. If that does slow things up, I'm not sure what we will do but at least we will know it is the layouts alone.
See www.grainge.org for RoboHelp and Authoring tips
Egads! Yes, I'm coming at it from the other direction. When I get into the office tomorrow I will try it from your direction and see if the same thing occurs. After some other issues that we've had in install RoboServer 8 and RoboSource Control, I've got a funny funny feeling this is a security issue somewhere. This bank's computer security is locked down tighter than Fort Knox.
Also, I have determined in the last few days that we do not have access to write to certain parts on our laptops. Most notably is the Program Files. I learned this when I tried to create a Master Project Template, and then when I tried that "workaround" that Julian (I think) mentioned on your site for slowness. You know the one to copy the missing DLL file to the RoboHelp folder. That gave me a big "Access Denied error."
I will test tomorrow and report back, cause now it's just the point of the thing.
Peter -- ok, I have recreated the error in a sample project. It started getting slow at the 5th FlashHelp Pro and with each one after it got slower and slower. We have 14 positions here so I need an output per role (position). Now this is not as non-functional as our Project, but with topics, layout files, and glossary that may account for "white out conditions" we see too.
This part is not an answer but a question re why you are doing this. Each author is going to be working on one project, unless source control is involved and there has been no mention of that. So the template needs only one layout. That layout may need different paths but surely the authors can set that given instructions?
Turning back to doing this the way you want, given it is a template project, can you send it to me? See my contact page on my site.
See www.grainge.org for RoboHelp and Authoring tips
Peter -- I'm about to rotate home, but when I get back I will send you the template that I'm talking about. So to clarify some things.
1) Yes we are using source control (we have just set this up -- as in this week set it up). There are 3 authors. The other 2 have never used RH until now. Please note: The slowness issues were seen prior to adding them to RoboSource so I didn't want to confuse this issue by throwing in RSOC.
2) All projects are going to have at least 10 FlashHelp Pro layouts because each one publishes to a different area (defined by roles), pulls it's own defined TOC, and selects content based on the appropiate conditionalized tags, etc...
3) The users wanted all the FHP layouts defined in the master project template so that they didn't have to remember the server name nor possibly forget a role nor take the time to duplicate and setup all the layouts when we could just as easily put them in the Master Project Template where all they have to do is enter their user name and password. I think they find a lot to remember as is and there's no reason that these layouts shouldn't already be there for them.
The slowness was originally seen in the master project. I narrowed it down to the mulitple FHP layouts when I was accessing that pod which created a white out screen and slowed the whole computer down. (Task manager taps at 100% when I just click in that pod to modify or publish any layout, printed or FHP).
Since I was creating the master project template based off the original project (to save me time duplicating Master Pages, CSS, windows, etc...) I simply imported things in pieces saving the FHP layouts for last. I was able to moved around quite quickly until the 4th FHP layout was setup. This may be an incorrect assumption, however, we are all experiencing the same issue of what I have termed "white out conditions".
I hope that makes sense, but if not, let me know.
I wonder if you could pull an end-around, and avoid using the WYSIWYG for generating these multiple layouts.
For example, you could set up each project to have only one or two layouts (Printed Doc & HTML Help?) for editing purposes, and then work with replacement flat files and command-line generation and publishing in a scheduled batch.
- Create each layout (Flash1.ssl, Flash2.ssl, etc.). (Just for the heck of it, don't use spaces or special characters.)
- Create an rhlayout.apj that lists all the layouts.
- Create your command-line batch commands.
- Add all .ssl files and the .apj to each project (in Win Explorer or using some Sync tool).
- Run your command-line batch commands.
- Swap the default rhlayout.apj file back in and remove the extra .ssl files (in Win Explorer).
These replacement files could be added to source control (under a folder named Layouts or such like), and thereby be easily accessible. You'd also need the default rhlayout.apj file available, to swap back before opening the project for edits. You could use a combination of
[It doesn't say in the RH8 help, but I believe you need to run each layout once before it will be recognized by the rhcl.exe program, although that might have been fixed with one of the patches. Anyone out there know about this?]
Yes, it sounds kludgy, but once you set things up, I think you'd be under a lot less stress. It should be easy enough to test this, using a sample project and a few layouts.
Leon -- wow. I had to read that a few times. I think I get what you're saying. We are still trying to troubleshoot it at this point, but if isn't resolved shortly I'll test the workaround. My biggest issue with that is I have authors who've never used RH and this, I think, would overwhelm them. But I'm up for less stress and working versus more troubleshooting.
This process would actually all take place outside their sphere of influence, and would be invisible to them. That is, after you've added the other SSL files and replaced the rhlayout.apj, generated the output, then taken out the SSL files and replaced the rhlayout.apj with the default (this could all be automated), they would still only see the two basic SSL layouts that they left the day before.
Well, this has been a long hard road to resolving the issue, but I believe we have the issue defined, but not a solution per se.
There were actually 3 issues that I originally though all stemmed from too many WebHelp Pro or FlashHelp Pro layouts in the SSL Pod.
1) Moving around RoboHelp and SSL pod was slow and/or caused white screens.
2) Opening the Project was slow which I originally thought was due to issue #1.
3) Typing content had a delayed effect on the screen of up to 15 seconds.
Preliminary findings indicate that too many URLs (3 or more) in the SSL Pod cause a lag time and white screens in the SSL pod, as well as a huge lag time in the project, to include occasional lag time in typing. Opening the project may take up to 15 minutes (more computer had a remote connection). These are 3 separate issues, not one as originally believed.
NOTE: We are using RoboSource Control, however, that does not seem to be a factor in any of the issues. The issue and solutions were tested outside of RSOC and again after being added to RSOC. Results were the same as described below.
1) SSL Pod Lag time is caused by having too many URLs in the SSL Pod (NOTE: Linking from the Topic to internal and external sites does not cause any lag time, nor does linking to the RH Server from the topic). The number of layouts did not have an impact on the system rather slowness appears only when there are 3 or more URLs identified with the layouts (SSL Pod). This also impacts the rest of the project causing a lag time:
a. in opening topics
b. creating new topics
c. moving topics
d. adding folders
e. deleting folders
Removing the URLs removes the lag time and white screen issue.
a. Why is the URL causing the lag time in the SSL Pod?
b. Why is the URL causing a slow down in the rest of the project?
c. Why is the same URL in the SSL Pod causing a lag time, but not when entered into a topic? This may be answered due to the fact that the links are coming from an HTM file versus the plbsrvs.sss file. The plbsrvs.sss file tells RoboHelp where to publish, as well as what to include in the end user view and how it should look.
Temporary workaround: Have only 1 URL in the SSL pod. Publishing Online Help requires manual intervention as each layout will need to be published one by one and the area changed per role. This has some inherent risk as it is easy to over look the second publishing screen where you must change the area tp publish to the correct role. If the area is not changed to match the audience you run the risk of overwriting one role with that of another role.
Permanent Solution: We need a long term solution so that each layout is set up with its own URL so that it will publish to the correct area and allow for batch publishing. It is unclear whether the lag time is caused by RoboHelp or because of the connection / permissions / security settings from RoboHelp to the RoboServer.
2) Opening the project may take up to 15 minutes. Even after the URLs were deleting as described in #1 above, the project was still slow to open. After initial testing with an off-site connection using VPN it was determined that the CPD file (cache file) being cleared every time the project was opened and the Resource Manager (central repository of images) being mapped to a share network drive were causing the slowness.
a. Deleting the CPD file every time a project is opened slows RH because it has to delete the contents of the file then rebuild the project index so that RH knows what topics, images, etc… are in the project. The CPD file should not be cleared every time a project is opened. This file should only be deleted when needed.
b. After clearing this option, the project opened faster, but still took up to 5 minutes to open. It was determined that the Resource Manager looking for images on the Share Drive was slowing RH. When remapped to a local drive, the project opened as expected in less that 2 minutes.
a. Uncheck the option to rebuild the CPD file every time a project is opened.
b. Map the Resource Manager to a local drive.
3) Lag time in typing is intermittent. However, during testing I could create the issue on several occasions. On one instance I noticed that a message was being generated in the lower left footer of the screen in RH. When I duplicated the issue I managed to take a camera shot of the statement as it flashed by. It said Repagination…
Outstanding Question: why is it repaginating? The issue is present if the project is not in source control and being accessed off-site via VPN. The issue went away if the project is:
a. out of source control with no internet connection
b. out of source control with internet connection
c. in source control being accessed off-site via VPN
d. in source control on site
I cannot consistently duplicate this issue. Since it is intermittent, we will continue to monitor the issue and do research about repagination in RoboHelp to see if something has been identified on the Adobe site that is not related to FrameMaker. We do not have FrameMaker. As long as this issue does not become consistent this is probably not worth troubleshooting at this time.
If anyone has any suggestions on how to add URLs the the SSL pod and not slow the project down while working in it, please let me know. We have 15 roles for this project and it would be nice to batch generate when necessary. This cannot be done unless I can add a URL to every WebHelp Pro layout. NOTE: I have not had this issue in previous versions, so near as I can tell this is a RH8 issue.
Peter -- thank you for your help and suggestions in troubleshooting this (these) issues.
What happens if you set up multiple SSL layouts that dump their generated WebHelp (Pro) output to a different folder on your local drive or a server (& not have RH try to do the publishing to a URL)? If that fixes the slowdown, then you could do a batch FTP script to publish each of the outputs to their proper web location - in effect, just take RH out of the FTP business (because, frankly, it's probably not a very good FTP client).
Just my 0.02 worth ;>)
I am having this same issue. I am using the RoboHelp Server 8, RoboHelp 8. I only have a few single source layouts in the POD. The defaults plus around 3 more. RoboHelp slows down so much that selecting a different SSL at times takes 45 seconds or more. RH Projects with the SSLs take a very long time to open. Not sure what the resolution is here, but thought I would chime in and say I have the same problem. Not certain if it is the connection to the RHS or not.
Jeff -- that's an interesting idea. We do output each layout to a different folder so it might work. I prefer not to do that as it could be confusing to the 2 new writers I have, but more importantly trying to communicate that to a hand off team or to a future writer that has little to no experience with RH would be tricky at best. I will give it a go and then let you know what happens.
JC -- Once I played with the URLs in the SSL pod it seems that 3 is the magic number. Anything over 2 seem to slow. 3 or more and the lag time reutrns. You might try Jeff's suggestion and see if that works. If it does let me know. I'm going to talk with my IT department first to see if it is a RH to RHS connection or security issue and if not I'll submit this as a bug to Adobe because this has not been an issue in previous versions.
I will update this post if IT comes back with a solution or if I hear back from Adobe.
UPDATE: One author had issues typing again. After some quick verification that the project did not have too many URLs, we figured out that the Resource Manager pod was looking for Images on a Shared Drive on the network. Which, as far as I can tell, is the purpose of the Resource Manager. We remapped that pod to a local drive and that fixed the lag time when typing.
Later we remapped it back to the network drive and everything was fine. Our conclusion is that mapping to a central repository of images and multimedia may create a problem with using resources and spinning all the time. In this case, we think something may have been occuring on the server where the images reside causing the tempory conflict and slow down.
I submitted a bug request for the URL issues in the SSL Pod. Click here RoboHelp Wish Form/Bug Reporting Form and feel free to submit a bug too.
Errrr...no. "looking for Images on a Shared Drive on the network...is the purpose of the Resource Manager," while possibly correct, is probably not best practice.
The Resource Manager is only designed to apply to the user's local machine (that is, for any projects on that user's machine, whether part of a merged help system or not). You can, of course, sync the files between users (using an automated instance of a synchronizing tool, or using a source control product); as long as the files you'll eventually be accessing are on your local machine, RH won't be coughing up hair balls. You could even create an entirely separate project that contains all the resources (bypassing the Resource Manager function entirely), and access those files in the same sync'ing manner as just described.
When you refer to URLs in the SSL Pod, I take it you are referring to publish locations. I just set up a project with five locations and it has no problems.
The thing I do notice throughout this thread is that things work just fine when everything is local and go belly up once the network comes into play. Also as this is not a previously reported problem, whilst it doesn't help you, guess where my thinking is headed.
See www.grainge.org for RoboHelp and Authoring tips
Not certain where this is headed. However, there is clearly something going on. I am testing RHServer and am an Admin on the Server. I have nothing on a network saved other than file shares to place the AIR App install files and comments. The SSL Pod, when open, for some reason is so ridiculously slow to even select another SSL output. I am not certain what is going on, but there is not wrong with my network.
Can we take a step back here so that we are all singing from the same hymn sheet. Where are the RoboHelp and RoboHelp Server installed? What output types are you creating and where. I ask these questions because AirHelp is not supported on the RoboHelp Server. Also presumably RoboHelp 8 did not used to be this slow. What has changed that may have caused this slowness (e.g. installed applications).
The RoboColum(n) @robocolumn Colum McAndrew
I think Chunkee is simply saying that all that is on the network are the AIR update files which do need to be on a server. The rest of this thread has nothing to do with AIR as an output.
MeWrite has had this problem since installing RH8, it is not a change in how RH8 is behaving.
See www.grainge.org for RoboHelp and Authoring tips
The AIR Application Update Files (AIR installer files) along with comments are on a shared internal network drive. That is for the application format only. I DO HAVE RHServer, on a server. Since the current version of RHServer is not compatible with AIR Browswer help, the browser help is on an IIS virtual directory. It is published via a shared folder to place the contents so they can be accessed via a browser. The RHServer, with its limitations, has FlashHelp Pro and WebHelp Pro versions of the same content. I am building a presentation on which way to go for our company. I was just invited to the RH9/RHS9 testing.
I am not certain what is causing the lag. Our network is gigabit and throughput is very fast as all of this is local and not somewhere in the orient.
AIRHelp Application - Stored on a Shared Network Folder for commenting and placement of the updates when created.
AIRHelp Browser- Stored on an IIS Server virtual directory and accessed via a Browser to view.
RHServer on Windows Server 2008 32bit
FlashHelp Pro and WebHelp Pro Versions are on there.
I have 2 additional SSLs in the SSL Pod. Selecting each of these takes a bit of time and can be a large delay if several topic tabs are open. The targets and source files are stored on my local PC. No source control as of yet. However, if we choose Flare we will probably go with TFS or Subversion.
Not certain as which way we will go. I have used both, and both have their problems. The new features of the RH9/RHS9 seem hopeful as some of them were the caveats that were pushing me toward Flare and Madcaps solution.
Thats it in a nutshell.
I apologize if I implied that. These are all created from new.
Sorry for the lag time in updating this post. Been quite busy testing versus writing.
JC is experiencing the same problem I am. This has nothing to do with local versus network near as I can tell.
We are using RoboSource to store the projects because we are remote and working on the same project. There are no issues adding projects and checking them in or out.
We are publishing to RoboServer 8 because we are publishing a WebHelp Pro format.
The issue is/seems to be that when we add in the publishing box more than 3 URLs. I have no problems in RH until there is more than one Server URL in the SSL Publishing box. They are all the same server, just the areas are different. In RH7 I had 9 Pro formats with 9 URLs pointing to the same server, just different folders (i.e., Areas in RH8) and experienced no issues with the slowness that I am with RH8.
I have an open ticket to Adobe who is escalating to tier 2. I will update after I talk with them.
JC -- thanks for letting me know about RH9, I got an email the other day, just haven't had time to go check that out, I guess that will be tonight's home work :-D
Update -- this issue is still unresolved and with RH9 out I have no doubt that this issue will go unresolved for RH8.
We have found that having 25 SSLs makes publishing a nightmare. It takes more than 10 minutes to generate the WebHelp Pro OR FlashHelp Pro. Batch generation is impossible. Single publishing takes 20-30 minutes and that is after 10 minutes to generate the project.
Our workaround was to delete all the URLs, not the layouts, just the server path so that there is only 1. Since we cannot batch generate anyway, we simply go into the layout we want to publish and change the area. Irratating at worse, but at least RH has stopped freezing up, crashing and becoming non-responsive.