Nickname lost on connect

Submitted by Laser5000 on #1

Hi,

I sometimes have the problem that when a PC connects with a USB device, the nickname changes to the product name, e.g. “0x1665”. Is this a known bug, or is there a way to prevent it?

Because of this, I’ve already started using the “onChangeNickname” event, but of course I still need to allow certain users.

best regards

Mathias

Submitted by Michael on Thu, 2026/04/30 - 07:41

#2

What USB device is it?

Submitted by Laser5000 on Thu, 2026/04/30 - 16:21

#3

Hello Michael,

there are only USB Dongle. 

Is there something i could check?

In the config.ini the Nicknames Line:

DeviceNicknames=2D; Bitmap; Arch; 3D Holz+Stahlbau; Liste; ETZ408D5C163224E69079490393,0000,0000,24,2D Bitmap Arch;3D Holz+Stahlb;Liste;ETZ Dachausm;IFC,0951,1665,12,2D Bitmap;Arch;3D Holz+Stahlbau;IFC,0951,1666,25,2D Bitmap;Arch;3D Holz+Stahlbau;Liste;ETZ;Dachausm;IFC,0951,1665,31,2D Bitmap;Arch;3D Holz+Stahlbau;IFCtest408D5CE4B641E7C0E91906DA,0000,0000,24,2D Bitmap;Arch;3D Holz+Stahlbau;Liste;ETZ;Dachausm;IFC6CF049E316CF049E31FDEBE5149931384,0000,0000,24,2D Bitmap;Arch;3D Holz+Stahlb;Liste;ETZ;Dachausm;Balken*PBA;IFC50E549C695B3BE51398B009E,0000,0000,24,2D Bitmap;Arch;3D Holz+Stahlbau;Liste;ETZ;Dachausm;IFC,0930,6544,28,2D Bitmap Arch;3D Holz+Stahlb;Liste;ETZ;Dachausm;Balken*PBA;IFC,0951,1665,27,2D Bitmap;Arch;3D Holz+Stahlbau;Liste;ETZ;Dachausm;IFC1C1B0DDB013AC391C92A21F3,0000,0000,24

i see there are some not connected dongle with a serialnumber in the name: 408D5CE4B641E7C0E91906DA and 0000,0000,24 for example. At the moment just 4 Dongle connected. I could clean the config.ini and test it today.

 

Submitted by Michael on Thu, 2026/04/30 - 17:46

#4

I think i know what is happening.

The Virtualhere server is querying for details about the serial number from the device when you plug in the device. The device is not providing a serial number due to some problem in the firmware inside the device. Since the nickname cannot be matched on the serial number virtualhere will  show the ProductID as a placeholder for the nickname. Furthermore normally virtualhere would show the product name if there is no nickname, but no strings can be returned from the device at all so it defaults to the ProductID hex.

What server OS is the virtualhere server running on? Linux/Windows/Mac ? or  NAS?

In the server log it might say something like error getting string descriptor for serial or something like that. Have a look for that.

Anyway i think its a bug in the firmware inside the dongle not returning string values when queried. Does only one dongle do this or any of them?

 

Submitted by Laser5000 on Thu, 2026/04/30 - 18:40

#5

The Server is running on Windows. I could not find a problem in the server log.

But maybe you are right....
i logged the bind and unbind event since yesterday and see this:

30.04.2026  7:29:14,50;Bind;"0";"2D Bitmap;Arch;3D Holz+Stahlb;Liste;ETZ;Dachausm;Balken*PBA;IFC";"50E549C695B3BE51398B009E" 
30.04.2026  7:29:16,98;UnBind;"1";"2D Bitmap;Arch;3D Holz+Stahlb;Liste;ETZ;Dachausm;Balken*PBA;IFC" 
30.04.2026  7:29:18,27;Bind;"0";"2D Bitmap Arch;3D Holz+Stahlb;Liste;ETZ;Dachausm;Balken*PBA;IFC";"" 

this time no automatic renaming was happend but as you see at the end of the second "bind" no serial number is visible. On the client i see the same: a short time the dongle is binded, unbinded and finally binded. 


following log entry is from a binding with the "rename" problem:
30.04.2026 10:08:11,08;Bind;"0";"2D Bitmap;Arch;3DHolz+Stahl;Liste;ETZ;Dach.Balken+PBA;IFC+Rhino";"50E549C695A4BE51398D0044" 
30.04.2026 10:08:12,84;UnBind;"1";"2D Bitmap;Arch;3DHolz+Stahl;Liste;ETZ;Dach.Balken+PBA;IFC+Rhino" 
30.04.2026 10:08:14,13;Bind;"0";"";"" 
30.04.2026 10:08:23,66;UnBind;"0";"" 

In VirtualHere Client in the properties from the devices, i see just on 2 from 4 a serial number. Both dongle from the mentioned log lines does not have a serial number listet as "(none)". After a second manual rename, the name has remained correct so far...
 

Submitted by Michael on Thu, 2026/04/30 - 18:56

#6

Is the windows server machine a laptop? It might be powering down the usb devices. When virtualhere goes to query them they are asleep and return no values. The device should auto-wake and return its values. Try swapping USB Hubs if you have a spare one and plug the dongles into another hub and see if that helps.

Submitted by Laser5000 on Thu, 2026/04/30 - 19:05

#7

No it is a server. No powersaving Options activated on USB Devices. 

Just another question because i found a thread from 2014.... is there still a limit with the length of nicknames? We unfortunately had to assign very long names, and from the way the thread sounds, there seems to be a limit of 1024. That would mean a maximum of 16 dongles—and likely even fewer due to the additional characters in the configuration?

Submitted by Michael on Thu, 2026/04/30 - 19:31

#8

I checked that , from your post #3 and there is a limit of 63 characters in a nickname and it will be truncated to that length safely which it is doing already. Also there is no limit to nicknames for any number of devices anymore (the 1024 length limit is no longer there)

Submitted by Laser5000 on Thu, 2026/04/30 - 21:14

#9

i testet something after cleaning the config file (the lines with ,0951,1665,27 and no serialnumber in the name column are the right ones?):

after server restart every serial number is available.

after manual renaming a entry with the new name followed by the serialnumber is in the config file:
2D+Bitmap;Arch;3D Holz+Stahlb;Liste;ETZ;Dachausm;Balken*PBA;IFC50E549C695B3BE51398B009E,0000,0000,24

and still the old name:
2D Bitmap;Arch;3D Holz+Stahlb;Liste;ETZ;Dachausm;Balken*PBA;IFC,0951,1665,27

i think if this is happend with to much devices the server have problems on binding (sometimes). After restart the server just showed the old name.

Submitted by Michael on Fri, 2026/05/01 - 08:15

#10

Its a good idea to not edit the config.ini directly because the server wont pickup the change if its running and also the format is a bit complicated for the nickname fields. Its best to rename from the client only.

Submitted by Laser5000 on Fri, 2026/05/01 - 11:05

#11

That is clear, i stopped the Server before. Currently it is the only way i could do, because of the "empty" entries (0000,0000,24) after renaming with client, or i'm not right and this entries are the better ones? But as you said it is no good idea and just a work around, because of the Server restart every time.

Do you think we could find a solution for this Server or is it better to change to a Linux Server? 

Submitted by Michael on Fri, 2026/05/01 - 11:07

#12

The problem is the dongle not returning its string descriptors. You could try a linux server if you want and see if that helps. I suspect it probably wont.

 

Submitted by Michael on Fri, 2026/05/01 - 14:06

#14

Are you saying its ok on Linux? 

Submitted by Laser5000 on Wed, 2026/05/06 - 17:53

#15

Hi, yes... but i could not say if it is a linux or mainboard related issue.

The last two days have been going really well! Thank you so much for your support!

Submitted by Laser5000 on Fri, 2026/05/08 - 22:34

#16

I think we found just a little Bug (or Feature) ;-)

If a nickname is relatively long — e.g. 60 characters — and the server is restarted, the nickname appears together with the first characters of the serial number, so the device has to be renamed again. This works until the next restart.

It only works correctly if the nickname + serial number are <= 63 characters.

Our workaround: we pad the remaining part of the nickname with spaces. Then it works correctly.

Submitted by Michael on Mon, 2026/05/11 - 10:37

#17

Thanks, indeed that is a bug and it should be fixed in this build:

Linux:

https://www.virtualhere.com/sites/default/files/usbserver/test/vhusbdx86_64 (stop the current server systemctl stop virtualhere, copy over that new binary to /usr/local/sbin/vhusbdx86_64 and chmod +x /usr/local/sbin/vhusbdx86_64, and start the server again systemctl start virtualhere)

Windows:

https://www.virtualhere.com/sites/default/files/usbserver/test/vhusbdwin64.exe (stop and exit the current server then copy over this binary and start)