My setup: 2 x SC6000 and a non-Denon mixer. I used Tidal almost exclusively these days. One of the SC6000 has an internal SSD and they are connected via ethernet LAN cable, via a basic switch. When I startup the players, they both use the internal SSD and then I connect to Tidal.
If I download a Tidal track on PlayerA, the analysis is not there on PlayerB (i.e. no Key or BPM detection). If I then download a track on PlayerB, the analysis is not there on PlayerA.
Only PlayerA has an SSD.
If I reboot both SC6000s, and look at the Tidal playlist, both players display the track key - but only for those tracks that were originally analysed by PlayerA (WITH the SSD).
So it seems as if they can’t share an SSD.
Other symptoms: sometimes if I download a track on a player, the analysis is gone when I browse out of the playlist to another. Then when I try to download and analyse again, the SC6000 just has a dash “-” where the key should be - even though minutes earlier it analysed it successfully!
I have tried wiping the Engine DB on the SSD completely and starting from scratch, but this did not help. I am using the latest firmware, 2.2.
Has anyone else seen this behaviour? Is it because I use Tidal? Are there issues with SC6000s sharing an SSD? (It used to work perfectly before I upgraded to 2.x)
I have now connected both players directly to each other using ethernet LAN cable, bypassing the switch/hub thing. Both players then connect to Tidal using Wifi.
When the SC6000s boot up, I first select the internal SSD option on both. Then I connect to Tidal. All ok so far.
Next I open a Tidal playlist on PlayerA (SSD) and can see that the track analysis is there (e.g. Key). Then I open the same Tidal playlist on PlayerB (no SSD) but there is no track analysis.
PlayerB can “see” the SSD and claims to be connected to it, yet can’t see the track analysis data. If I download a track on PlayerB the analysis is not saved, i.e. PlayerA cannot see it.
So the direct connection makes no difference unfortunately.
Ok, you have at least eliminated one possible issue. I vaguely remember somebody posting similar issues but search did not shown any similar topics so I cannot be sure, hopefuly somebody else remembers.
Next thing I would do to troubleshoot is regarding storage: can you take out the SSD out of the player and put it in a USB enclosure?
Cable should be fine as PlayerB can “see” the drive on PlayerA when they first boot up. Also, if I turn off PlayerA, I then get an error message on PlayerB to say the drive is not accessible.
If everything worked without issue before you upgraded to 2.2, perhaps you can reload the previous firmware and see if that still holds true. Also, does Instant Doubles work when the players are connected to each other bypassing the hub?
So as an update, I thought I had cracked it. I noticed that “PlayerA” which has the SSD, was labelled as Player 2 in the settings. I wondered if perhaps the SSD had to be in Player 1, so I updated the settings to swap around players 1 and 2 (SSD in player 1, which I have been calling “PlayerA”).
(I still have the players connected directly to each other by ethernet cable, WIfi for Tidal)
I played for about 20 minutes and it was working! Both players analysed new tracks from Tidal and both players could read each others analysis, key detection, etc. I was buzzing!
But then it stopped working. PlayerA (SSD) would download a track and analyse it but PlayerB (no SSD) could not longer see the analysis. Arrrgh! This means the cable, WIfi, labelling of players makes no difference - back to square one.
I thought I would reboot PlayerB (no SSD) to see if it started to work again. Upon rebooting, it couldn’t even “see” the SSD in PlayerA. Checked the cable, all good. So I rebooted it again. This time, it can see the SSD!
I then went back to my Tidal playlist on PlayerB and all the analysis & key information is there.
I switched out the internal SSD and put a good quality USB 3.0 stick into one of the USB ports. This has the same behaviour.
The player without the USB stick does not seem to be able to write data to the stick. It can see track analysis which is done by the player with the stick, so it can read data. To confirm this, when I download another track to the player without the stick, it forgets the analysis done on the first track.
When I boot up the players, they can both “see” the USB stick and I select that as the source first, then log into Tidal.
I have clicked in and out of the playlists to refresh them each time. I also ran the update to 2.2.1 this morning on the off chance, but no luck.
So I think I can rule out the SSD, the ethernet cable and the switch. The only thing remains is the SC6000 / EngineOS itself.
The problem with analysis stuff not showing up when playing off drives over network link is an old issue InMusic knows about that still hasn’t been resolved, and the issue with Wifi & streaming crapping out is tied to utilizing a drive to save analysis info that I also mentioned way back. The two problems might be related, but the current solution to the former is to reboot until the analysis seems to be working & sharing, and the solution to the latter is to never have a source drive available when using streaming source services like Tidal. If on the latter you temporarily use a drive to get a track, eject the drive immediately before going back to using a streaming source like Tidal again on that unit. A more near-term and universal stop-gap for both issues would probably be an option to simply force the units to treat the drives that are connected in read-only mode.
Likely placebo effect, as it appears all the recent public firmwares have had these issues. Over enough time, you should see they will seem to come and go randomly. If you think that assessment is wrong, and it’s certainly possible considering I took a year off from DJing and still am not back to as frequently as before and so I might have missed a version, you might want to touch base with InMusic and tell them something about 2.3.2 uniquely appeared to fix these issues that prior and subsequent versions still suffer.