Hello it’s me!!
I can access the external plugin ![]()
I wanted to integrate Spotify:
Is there no way to have a single selector (uuid)?
Hello it’s me!!
I can access the external plugin ![]()
I wanted to integrate Spotify:
I’ll take a look
@pierre-gilles, Claude says the problem is with the core. Here’s his analysis. You can take a look
The Diagnosis
When the front POSTs the discovered device to /api/v1/device, it doesn't send a selector. The core then generates it in a Sequelize beforeValidate hook:
server/utils/addSelector.js:11-17
function addSelector(item) {
if (item.selector) {
item.selector = slugify(item.selector);
} else if (item.name) {
item.selector = slugify(item.name); // <-- here
}
}
So selector = slugify(device.name), without any deduplication, even though the column is unique: true (server/models/device.js:32-36). The UNIQUE constraint is skipped, Sequelize throws a SequelizeUniqueConstraintError, and errorMiddleware.js:42-49 turns it into a 409 on the selector attribute — exactly what the forum member sees.
His Spotify Connect device is named « MacBook Pro de … » → selector macbook-pro-de-..., which already exists for him (probably another device with the same name: a Chromecast, an AirPlay, a device from another integration, or a previously added and renamed Spotify).
What This Implies
The problem isn't in the Spotify plugin: our external_id are unique (ext:<selector-integration>:spotify:<deviceId>), the Spotify device's external_id never collides. This is a core limitation: the selector is derived from the name, and two devices with the same name cannot be created.
Note that the core already does better elsewhere — externalIntegration.buildSelector.js:25 loops to find a free candidate:
while ((await db.Service.findOne({ where: { selector: candidate } })) !== null) {
This logic has simply never been applied to devices.
@Will_71 You’re right, we should handle this case
I’ll handle it in a PR
It’s fixed here:
The fix is live in 4.84.4: