xenolightning
Problem with hotkeys and plug in known devices
Hi, first of all thanks for the application, is super helpful. After that, I have to say I have found some problems related with these issues that I will explain thoroughly... https://github.com/xenolightning/AudioSwitcher_v1/issues/1870 https://github.com/xenolightning/AudioSwitcher_v1/issues/1253
I am using Version 1.7.0.117
Every time that I connect my bluetooth device, after the Audio Switcher start, it seems that the application recognize it like a totally different device... and the device configured previously in the "Audio Switcher" as a favourite one disappeared and also the hot key associated....
The problem is when you try to configure the hotkey again, you can not. The application says "hotkey duplicated", but it is not even listed (because, for the application, "the new" device is not the same one than before...) and you can not just delete the old one to re-establish it again...
I've just reproduce the error:
- When you plug out the dongle while Audio Switcher is started and you plug in it again, everything is working perfectly. The configuration is still there.
- But if you unplug and after that you close the application (or just stopped from the beggining and plug out), when you restarted Audio Switcher and, after that, plug in the dongle again, the configuration of the wireless headset has gone (just the hotkey and the favorite star).
And to configure it again you have to delete all the hotkeys because the old one is not shown in the list... It would be helpful if we could see the hotkeys list, even if they were "disconnected". In this case, we could delete just one, instead of all of them.
Happens the same with my TV through the HDMI... if you plug in it late, you have to reconfigure again...
If you need more tests just let me know.
You are doing a really good work! Thanks in advance!
There's definitely issues in this space. Mostly caused by Windows thinking that plugging in the same usb device (or HDMI device) is a new device every time. There's a limitation of is possible in this space because of this.
I'll investigate the possibility is of listing disconnected hotkeys, it might be a good compromise to an annoying situation.
I'll update this issue after I know more.
It's weird, today I tried in a different PC with a clean installation of Version 1.7.0.117 and plug in the dongle after the application start, this time, everything work perfectly...
The test that I mentioned before, at the beggining of the issue, was over version v.1.7.0.117 but updated from any 1.6 version, I don't remember exactly which one. If it can be useful.
If I find something new I will updated it too :)
@xenolightning As a workaround, how about identifying a device by its "friendly name" ("Speakers", "SAMSUNG-0" for my TV, "Realtek Digital Output")?
@robhol That introduces another set of issues. What if there's two devices with the same name? Which one should it use?
This issue was more or less the driving factor why v2 has scripting support. It allows the user to more accurately select which device to set as the default.
Hi again, I've found another curiosity:
When you plug in the headset after start the application, with the right clic over "Audio Switcher", you can not choose the "new device" manually, because it is not listed, BUT you still can use the hot keys, to change from speaker to the headset :). And if you reboot everything is working again.
Then the problem seems not to be an internal issue, because de configuration is still there. It could be just a visualization problem, in addition to the problem with the hot keys not showed.
Yeah I think I inadvertently saw this the other day after installing Win10 on my main dev machine.
I believe it's happening when the device state changes, i.e active, unplugged, disabled etc.. They aren't being handled correctly by the UI to update the items in the list.
I'll confirm this, and raise another bug report.
"What if there's two devices with the same name? Which one should it use?" This is unlikely enough that going by the name would fix this problem 99% of the time. If two are found, just pick the first and hope for the best. In the screenshot below you can see multiple devices are detected and not one is even remotely close to the others. I'd think this is a very typical situation.
Pretty much the app has become useless since my USB headphones lose connection from time to time (wiggle the cable to get it back) so more often than not, my shortcut & favourite is inactive when I need it.
The other frustrating thing is the hotkey is still "taken", so your only choice is to clear ALL hotkeys and start again. This happens so frequently I can't count on having a nice setup of hotkeys, so I don't bother, and again, the app becomes useless.
Some kind of solution for either of these problems would help immensely.
@Domarius For the full names, you are right, they are almost unique on a system.
Here's where the fun part comes in, when devices disconnect & reconnect they create a "new" device; You can see this in the full name, where the number prefix is added to the interface. These have been reconnected and/or on different USB ports.
So let's say that you're USB device disconnects, when it reconnects, it's going to be prefixed, therefore a different name, and the same problem still exists.
You could use the "Short Name", but that's a problem because you have multiple Microphones; you could give them custom names, but the custom names get lost when you reconnect devices too.
The only true way to fix this, is provide a more detailed mechanism for selecting devices.
Are you talking about the number "4" in "Headset Earphone (4- Microsoft Lifechat LX-3000)"? Hm I never realised that.
In a few of my projects I've made use of the "levenshtein distance" algorithm to pick closest word matches - even better, perhaps you could just parse the name and ignore the part where you know the number will be, eg. Headset Earphone (4- Microsoft Lifechat LX-3000).
I feel like the most convenient fix for the user would be reverse engineering our own logic for when we choose a device manually, and automating that, eg. I know that Lifechat LX is my headset. I can spot it every time, so the computer should be able to as well, if we give it the right criteria.
Perhaps when creating a "device" in AutoHotkey, you give it "key words" that will always be in the device name that make it unique amongst other devices. Eg. the two phrases "Headset" and "Lifechat LX-3000" together is as good as a 100% chance of finding my headset. This is the same process I use as a human to find it. If the device is ever lost, AutoHotkey can rescan the device list and find a match to re-associate the USB device with the AutoHotKey "device".
Perhaps that's what you actually meant by "a more detailed mechanism"?
Yeah, you're on the same track with those ideas. Since the system id (guid), isn't useful in that scenario, it can't be used to identify the same device across connection boundaries.
"Fuzzy" string matching will probably cause more trouble than it's worth, it's somewhat unpredictable, which could produce some odd behaviour.
But certainly something like parsing out the numeric prefix in the interface name could work. This is probably best done as a "Name Identifier" generated by concatenating the two known strings (ignoring the numeric prefix) and hashing them. That should generate fairly consistent behaviour.
The problem still exists when there are two devices of the same name, as per my laptop at the moment:
Again going back to enabling the ability on a per user basis to manage the conditions. Which is in a "script", which properties can be checked. See https://github.com/xenolightning/AudioSwitcher_v1/issues/1969#issuecomment-187962465 for an example script (in Javascript)
The identifiers we have to work with are under the details tab in Device Manager, can check them out and see if anything jumps out.
Ah ok, so you can still try to match with given key words, just on more fields.
Looking forward to hearing about the updates :)
Potentially yeah, I'm not sure what there is there, and if anything of it be used.
RE: Contributing (before the ninja edit) 😛 You can raise another issue, or open a wiki topic. I'm fairly casual with contributions to the UI app.
The Api repository is more strict, as there are a lot of moving parts, and any pull request would require applicable unit tests.
Yeah my mistake :D I'm currently looking at freelancing, I only checked that AudioSwitcher actually runs off of donations after I posted. Jumped the gun. It'd be cool to work on otherwise. It's a super useful program, I still try and use it in between device losses. It's kinda something that should be built into the OS.
I just set up a gitter, can jump in there and continue the discussion if you like.
https://gitter.im/audioswitcher/Lobby
1.7.0.117 windows 10 The Shortcut key associated with device did not remove correctly as the remove of device.
When plug out a device and plugin, that would be a problem.
The program not only did not remember the shortcut key for the device, but also prevent to set up the same shortcut key for the device.
Hi, i am using Audio Switcher for some time now and its great! i was looking for a software that changes the audio device per Hotkey. there arent so many around and after almost giving uo i found you XD my problem was stated above (different device id on reconnect) and not being able to set the same hotkey sience the hotkey is still stored. so what i have to do is to click on delete all hotkeys and reset them... is there any way to just have all hotkeys schown and have them deleteable? that would be so great. thanks for your work!
Thanks for the reference! sorry i didnt find it myself. How is version 2 getting along? i am looking forward to it.
This problem severely reduces the functionality of the program but I can understand it might be tricky to fix conventionally. Why not have some sort of process which enables the user to quickly reset and reassign the hotkeys when a new device is plugged in? I mean, the hotkey facility of the program is it's main feature so if the hotkey is constantly lost then the program becomes much less user-friendly and efficient. So, why not "present" the hotkey programming in a much quicker and easier way? I'm thinking that when a new device is connected to the computer and it appears in the program, have a pop up which says "reassign hotkeys", then it will automatically scroll through all your devices to allow you to quickly assign the hotkeys with minimal amount of mouse dragging and clicking on each individual device. When the popup appears you can immediately enter hotkey for device 1, click next, enter hotkey for device 2, click next, enter hotkey for device 3.. and so on.. In 5 seconds all the hotkeys could be quickly reassigned. All that needs to be done is the "data input" area for hotkey section could be designed differently to make the assigning of hotkeys very quick and easy, so that it will counteract the problem of losing hotkeys as described in the original post above.
I agree, this is the next best thing and would make the program more useful again.
On Sun, 17 Dec 2017 at 01:35 Gorguruga [email protected] wrote:
This problem severely reduces the functionality of the program but I can understand it might be tricky to fix conventionally. Why not have some sort of process which enables the user to quickly reset and reassign the hotkeys when a new device is plugged in? I mean, the hotkey facility of the program is it's main feature so if the hotkey is constantly lost then the program becomes much less user-friendly and efficient. So, why not "present" the hotkey programming in a much quicker and easier way? I'm thinking that when a new device is connected to the computer and it appears in the program, have a pop up which says "reassign hotkeys", then it will automatically scroll through all your devices to allow you to quickly assign the hotkeys with minimal amount of mouse dragging and clicking on each individual device. When the popup appears you can immediately enter hotkey for device 1, click next, enter hotkey for device 2, click next, enter hotkey for device 3.. and so on.. In 5 seconds all the hotkeys could be quickly reassigned. All that needs to be done is the "data input" area for hotkey section could be designed differently to make the assigning of hotkeys very quick and easy, so that it will counteract the problem of losing hotkeys as described in the original post above.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/xenolightning/AudioSwitcher_v1/issues/2123#issuecomment-352190688, or mute the thread https://github.com/notifications/unsubscribe-auth/AHEXVWYKsG8n28Z_WRKNB1rrJCMH1pwGks5tA-NVgaJpZM4H0kz3 .