Sorry for the late reply.
We "solved" this problem by contacting the server vendors of all our production instances.
They provided us the list of configured ItemIds.
We removed the use of BrowsePaths, using only ItemId.

We realised another problem:
opclabs.com/forum/feature-requests-product-improvement-ideas/3640-opcda-memory-leak

This time we have created a reduced application of our own, which only includes the plugin using quickOPC.
If necessary, we can provide you it.

Hello.

We have done some tests:
1 - We created a Console Application:
- hard-coded OPCDA client configuration fields (the same as we use in our application on that machine)
- reading/subscribing nodes using the browsepath


2 - We created a one-shot Console Application that recursively uses BrowseNodes and generates a CSV with the nodeIds of the leaves.
This way we can try to read the signals using ItemId.


RESULTS:
1 - Working locally on a simulated server the exception occurred randomly very few times.
Working on the production server on the machine it happens more often, but sometimes it actually reads a few signals before throwing the exception and stopping forever ( Translation of browse path to item ID is not implemented with OPC NET API. ) .


2 - The Console worked, but the BrowseNodes takes a really long time (sometimes exceeding 20 minutes of timeout), we stopped it manually after 12 hours.
With the CSV result, we tried reading the same signals using the ItemId instead of the BrowsePath: with the ItemId everything works, very quickly.


Even the .NET Framework version with QuickOPC 5.63.246 took time before it received data using BrowsePath on this server (5/6 minutes maximum), but then it worked fine.

There might be a correlation between the exceptions using browsePaths and the long server browsing timeouts obtained with the new version of QuickOPC?

I hope to be helpful

Hello, we have encountered a problem in the translation from BrowsePath to ItemId when creating a DAItemDescriptor using only the BrowsePath.
We have a .NET Framework application that was recently migrated to .NET6.
In this step, we upgraded QuickOPC from 5.63.246 to 5.71.334.
On 94 machines with different server types, we did not encounter any problems.
On 3 machines (those using BrowsePath) we encountered the following error message (Both Subscription and Read):
Translation of browse path to item ID is not implemented with OPC NET API.

As a further test, we tried various direct Browse types (e.g. BrowseOne, BrowseAccessPaths) we encountered the same error.
By browsing the ParentNode and using the Child with the same name, we are able to extract the ItemId and create the DAItemDescriptor using it.
But this creates performance issue.

Do you have any advice on this?