libusb lets you find a device by it's vendor and product ID. But what if I have several devices with the same VID and PID attached, and want to get a handle to one of them by knowing it's serial number? There is a libusb_open_device_with_vid_pid, but no libusb_open_device_with_serial or similar. Would I have to crawl though the full device list (libusb_get_device_list) or is there a more convenient way?
I think crawling through the device list is the only way here. You could copy the code from libusb_open_device_with_vid_pid, as that is precisely what this function does.
Related
I want to understand which favorite playlist is currently playing on my Sonos speaker.
I've tried the following options:
There's no favorite ID in playbackMetadata and in playbackStatus. So, matching with favorite ID doesn't work
There's containerId in playbackMetadata, which sort of gives information about provider-specific playlist identifiers. Yet, there's no same identifiers in getFavorites response. So, matching containerId won't work either.
Tried loadingFavorite (both with and without playOnComplete set), then getting playbackMetadata in order to build a mapping of favorite ID to containerId. No luck either. Even with 2s delay between two calls to give some space for favorite to be loaded, playlistMetadata returns old containerId (or it might be new, only it doesn't get changed for a new favorite).
Is there a straightforward option? Or not that straightforward, but working?
It is not possible, at least at the UPnP level. When a Favorite is submitted for playback, nothing is included that would allow tracking it back to its origin.
Concise:
Is there a way (with YouTrack-API or somehow) to change issue ID. Say from s-5 to s-30?
Full story:
We created YouTrack project to track scientific equipment, which we produce. One device - one issue. With custom fields, we created, it is VERY convenient way to handle "device stories".
The only problem we have, is that devices have their own id numbers. If we could change issue ID so, that it corresponds to device IDs, it would be very helpful. Especially helpful, when we reference a device from other issues and other projects, and to have links with real device ids, etc.
Currently it's not possible. There's quite an old feature request on this: https://youtrack.jetbrains.com/issue/JT-11067.
I am building an app which requires a user to be uniquely identified on the server without him logging in.
I have already evaluated the App Specific Hardware ID but that seems to be dependent on the hardware config of the machine and if the user even changes a network device, it will change.
Can the EasClientDeviceInformation class along with the Id property be used for this purpose?
Thanks,
Rajeev
From the MSDN article on the EasClientDeviceInformation.Id, the Id is a:
GUID truncated from the first 16 bytes of the SHA256 hash of the MachineID, User SID, and Package Family Name where the MachineID uses the SID of the local users group.
This means that the Id should be unique for each user account and machine combination. However, I imagine a cloned OS will have the same EasClientDeviceInformation.Id. If this is not a concern for your app, then it should be enough to use by itself.
The ASHWID, if you only use the components that shouldn't change, could be another option for you. MSDN has a detailed article on how to use it.
You should definitely ignore the audio, network and Bluetooth components, as I've found they get removed if you do something as trivial as turning on airplane mode, or unplug a headset.
How unique is MPMediaItemPropertyPersistentID? Will it even work when synching the list of IDs to another device connected to the same iTunes Account?
I want to implement a iCloud synchronized playlist solution which stores the IDs as a list and I need to know if this will be possible.
As per the documentation (emphasis mine)...
The value of the MPMediaItemPropertyPersistentID identifier persists
across application launches and across syncs that do not change the
sync status of the media item. The value is not guaranteed to
persist across a sync/unsync/sync cycle.
As such, given that it won't even persist on this basis I'd be surprised if it persisted across devices in a sufficiently robust manner, if at all.
In my understanding this is not possible. I think this ID is persistent only for each device. It is no unique identifier for a specific song in the iTunes Store. It is only a ID for your own synced songs.
As you read the documentation, you'll see how fragile this ID could be.
"The value is not guaranteed to persist across a sync/unsync/sync cycle."
So if you sync your song database with iTunes and maybe delete a song from your iOS device and the sync again and put it back to your device, you may not get the same ID again for this song. And for sure not across other devices.
So I think, what you're trying to do will not work, until you get a worldwide identical Identifier for each song of the iTunes catalogue or your own iTunes catalogue on the Mac (where the Mac has to handle the IDs).
The other answers are a little big vague, so here is an answer from my own experiences and tests:
1) You can't use MPMediaItemPropertyPersistentID to get an ID that is equal between devices.
2) The MPMediaItemPropertyPersistentID will change when the device is synced with another iTunes library or all music is removed from the device and then synced again.
The ID get's created and stored by iTunes when the song is synced on the device. If it's unsynced, the ID get's deleted.
In case somebody else lands here, like me, using a Google search:
I confirmed what middaparka said above after an iOS upgrade of my device, when my music app tried to use persistentIDs from before the upgrade. The IDs had changed, and I ended up (unwittingly) listening to many songs from my library that I don't normally listen to...
So I took middaparka's advice and constructed a persistentKey by exclusive-oring the hashes from title, artistName, albumTitle and duration. Building the persistentKey during Core Database initialization will be save time later, by avoiding multiple string comparisons when fetching items in "normal operating code."
The persistentKey strategy worked properly for songs. However, when I made a hash for albums from title, artist and releaseYear, I ended up with one collision.
I had two self-titled albums by different artists released in 1976. When the hashes for the album title and the artist were exclusive-ored, they cancelled each other out. I ended up using the hash for the duration instead of the artist, and that worked.
I may end up refining the algorithm for generating the persistentKeys later...
Could anyone explain to me in simple programmatic terms how these RSA key dongles work? I know Blizzard has them for WoW and paypal as well as some of the trading sites.
Thanks!
The fob has a clock and a serial number that is used as a seed for a PRNG. When you hit the "show me a code" button, the fob displays a number that is the product of that timestamp and the serial number run through the PRNG. The server knows your fob's serial number and time, and does the same operation. If your codes match, you're authenticated.
You can calculate the previous/next N values on the server end to account for clock skew.
Programmatic terms aren't necessary. Just imagine two pieces of hardware (your dongle and something at the company) that generate the same numbers at the same regularly scheduled intervals. It would be virtually impossible to guess what the number is due to some proprietary algorithms, so if the number you type in (or is automatically sent by the dongle) matches the number at the server, your identity is validated.
At least with the dongle I have, you also have to supply a pin known only by you and the server. So, in order to be authenticated you need both something physical and something in your head. That combination is pretty hard to fake. Even if someone gets the dongle, unless they know your pin it's worthless. And if they know your pin, that information is worthless without the dongle.
Security Now! episode 103 talks about how they work. (That link is to the show notes, but there's a link at the top of the page to the audio podcast.)
Basically, the key fob is synchronized with a server and they're both seeded to generate the same sequence of pseudo-random numbers. The server knows it's you if you input the right number at the right time.