2019.1 Recent Files list not updating correctly

[isaac_hedberg]

We have multiple computers running Revit 2019.1, where the recent files list (both home screen and file menu) are not updating the projects after applying the patch.  It worked great on 2019 prior to the .1 patch.  We don't use worksets on our projects, so this is not a central file vs. local file issue. 

Any ideas for fixes are appreciated!

Ike

Title edited for clarity by @Viveka_CD

[SJT-72]

Any news on this issue from Autodesk? Can they confirm they are intending to issue a fix for this issue? Not entirely sure why it was changed as it used to work perfectly prior to updates.

[philip_simon]

I have the same issue.  The .ini file is updating fine, but my recent files list is empty.  The splash menu is inconsistent - sometimes it shows recent files, sometimes sample files.  Screenshot attached.

[Viveka_CD]

Hi @philip_simon

Please try the workarounds mentioned in this article: and let me know if this helps!

https://knowledge.autodesk.com/support/revit-products/troubleshooting/caas/sfdcarticles/sfdcarticles...

Regards,

[Viveka_CD]

Hi @philip_simon

If the workarounds do not solve your issue please send us a diagnostic data set for further investigation.

Please post a journal and a screencast of what you are experiencing and see the below article on how to extract a data-set for further diagnosis.
Revit - Collecting and sending diagnostic data to Autodesk Technical Support

Regards,

[SJT-72]

Many thanks for the response.

The suggested workaround of editing the .ini file appears to work, however this is not a realistic solution to the problem and only appears to work until the list is full again  (at which point I assume we would have to edit the .ini file again).

We currently run 8 Revit workstations in the office, and as such this is not a practical solution as the problem is common across all of the workstations. I appreciate that the suggestion is simply a workaround, but can you please confirm when a permanent solution to this issue is likely to be rolled out?

As office policy we do not allow users to manually edit files such as .ini files (not sure of many practices / IT departments that would allow this).

Regards

[Viveka_CD]

Hi @SJT-72

You are very welcome!

Glad to hear that the response worked for you. Please keep an eye on the article I've mentioned in the previous post for further updates.

Regards,

[philip_simon]

I'm not suggesting that the .ini should be edited, nor is it a workaround.
The point is that the .ini file should drive the recent files menu, and that's not working. That suggests to me that it's not a user setting, but software coding in this version that's the issue.

Thanks

Phil Simon

[philip_simon]

Sorry, read the other reply first. I'll try this workaround. I'm working in 2017 at the moment, but will let you know if it works.

Thanks!

Phil Simon

[Viveka_CD]

@philip_simon

Great! I'll look forward to your reply.

Regards,

[Anonymous]

Hi, any news on this issue?

Has it been solved in 2019.2?

[Mark_Engwirda]

I just did some quick testing and on first impressions look like it has!

[Anonymous]

Thank you, I'll do the update and testing.

[RobDraw]

I had issues updating stemming from the recent files list. It may or may not have had anything to do with the original installation. There are two locations that have recent files lists that needed to be deleted. See this thread for more details:

https://forums.autodesk.com/t5/revit-architecture-forum/2019-2-file-tab-very-slow-to-respond/m-p/856...

[RobDraw]

---

@SJT-72 wrote:

only appears to work until the list is full again  (at which point I assume we would have to edit the .ini file again).

---

Yes, true. I just reached that point. Just a bit annoying. Hopefully, an update will fix it.

[greg_benson-shettle]

The ini fix works for a while and as already high lighted it later fails, I was hoping the January  2019.2 update might fix this but it doesn't appear to have addressed this issue.

[Anonymous]

The problem hasn't been fixed in 2019.2.  

[SJT-72]

Do we know if this issue has been fixed in update 2019.2.1?

[philip_simon]

Apparently.  The problem has stopped occurring, but I'm not sure why.

[philip_simon]

Sorry for the long delay.  The problem went away at some point - perhaps 2.1 solved it, maybe it's some sort of a stack structure issue which just took several iterations to work out, but it's working fine now, with no action on my part.  Thanks for your help!  Problem solved.

[Viveka_CD]

@philip_simon  Thanks for getting back to us!

Regards,