You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Setup: DroidCam Windows Client version 6.5.2 running on Windows 10
Describe the bug
In the windows client menu bar, select DroidCam -> Settings
In the "general" tab, look for "JPG Save Folder"
Select a folder whose path has a space in it, for example: D:\Alessandro Antonelli\Immagini\DroidCam
Click "Save"
Close the client app
Expected behavior
After reopening the Windows client app, the "JPG Save Folder" path is still the same chosen above.
Actual behavior
After reopening the Windows client app, the "JPG Save Folder" path is truncated to the first space, in my case: D:\Alessandro
This leads to the entire "Save to JPG" feature not working, with the image not saved at all anywhere, without any error message or notice given to the user.
Additional context
Settings are stored in file C:\ProgramData\droidcam-settings. Saving to the file seems to work fine: when changing the setting and closing the app, the setting file contains the right folder path. The bug seems caused by how the windows client reads the settings file at the next startup.
The text was updated successfully, but these errors were encountered:
Setup: DroidCam Windows Client version 6.5.2 running on Windows 10
Describe the bug
D:\Alessandro Antonelli\Immagini\DroidCam
Expected behavior
After reopening the Windows client app, the "JPG Save Folder" path is still the same chosen above.
Actual behavior
After reopening the Windows client app, the "JPG Save Folder" path is truncated to the first space, in my case:
D:\Alessandro
This leads to the entire "Save to JPG" feature not working, with the image not saved at all anywhere, without any error message or notice given to the user.
Additional context
Settings are stored in file
C:\ProgramData\droidcam-settings
. Saving to the file seems to work fine: when changing the setting and closing the app, the setting file contains the right folder path. The bug seems caused by how the windows client reads the settings file at the next startup.The text was updated successfully, but these errors were encountered: