Can we talk about the slow linked player issue SC6000?

To cut a long story short, I have a largish but not massive database ~300k tracks, I never had an issue on my SC5000 but when I upgraded to the SC6000’s a couple of years ago I immediately started seeing an issue where by the linked deck would sometimes, not always take up to a minute to retrieve the list of tracks from the other player, it doesn’t always happen and is a little bit random.

This USB SSD is fine in the player its connected to and my Go and Prime 2. I spent weeks talking to support sending videos of the issue, troubleshooting etc, in the end I even sent my player back for support to look at but they cant find any issues. I have just kind of put up with it.

Fast forward a couple of years and I am increasingly seeing other people here and on Facebook mention the same problem, I guessing people music collections are growing to the point they are being affected.

Im 99% sure there is an obscure bug somewhere, is anyone else seeing this issue?

Here is the most recent FB post: Redirecting...

2 Likes

There’s a couple of considerations here: firstly, the Internet, especially the likes of social media etc, are great at storing old comments, very old comments and extremely old comments. Searching and finding someone’s comments about “I’m having this odd issue….” could be years old…. I’ve certainly gone searching for something, only to find results appearing from years ago.

Obviously, with InMusic releasing new firmware every few months, a problem that someone spouts off about on social media in June 2022, might not still be an issue for anyone in Jan 2023.

This also sprang to mind when you mentioned you changing from SC5000 to SC6000 - A possible consideration is the firmware, rather than the model.

Currently, the latest firmware doesn’t seem to have any speed search issues differing between local deck and network deck. There is someone chiming on about a very very niche local deck vs remote deck with regard to loading of 1 hour long files - but that’s a different issue.

You clearly don’t have an SC set. It’s an issue. Opening playlists is slower on the networked player.

4 Likes

Yes I have an SC set but I use a huge range of small ( <100 tracks ) playlists, rather than a few massive playlists. Most of my individual track. I use tags and search options to locate each next track.

They, and individual tracks, loaded a lot slower on the previous firmware

It’s about 10 seconds per 10000 tracks in a collection in my experience.

My link deck is now down to 70secs tor the first library query eg choosing a smart list.

It takes a few more user initiated queries for the linked deck database to be fully available.

Fun fact - leaving the linked deck on for some time does not shorten the time. It requires a few user queries to get it optimized for performance.

The drive does not have 70k tracks though.

The main collection is 75k from which I export about half of that to the performance drive.

2 Likes

FYI

This has been reported and confirmed as an issue by devs.

:point_up:t5:

2 Likes

We have been reporting slow database loading for years.

Here is just one example of someone else having this issue: Slow loading from hard drive

To this day I’m still experiencing slow database loading on a samsung T5, samsung T7, and a sandisk with my SC5000s. Adding to process of elimination, all 3 harddrives are managed on 3 different computers and all 3 have different databases. Same problems on all of them. I’ve also cut my library down to 30k. Sometimes it takes 2 minutes for the library to load (upon startup + sporadically hours into DJing).

1 Like

Its strange it only happens on the linked deck though, it is snappy on the main deck.

Have you tried an active USB 3.0 hub?

I find using a streaming service with no drive loaded to save anything (basically read-only mode) is the most reliable situation for Engine OS. Last week I tried briefly to play some tracks off a large drive that Tidal didn’t have mid-set and the players seemed almost possessed by an evil demon or something for like a minute. Slow, unpredictable, then started freezing up, and finally did load a track but without any waveforms. I don’t like waveforms, or at least the moving ones, but it was certainly not how it’s supposed to work. I’m curious if a read-only mode for drives would give similar improvement of reliability as streaming service read-only.

Guys, I remedied my problems with reading the library following a tip from a user here from the forum, I don’t remember who was @mufasa?

The tip is to leave the library in the “Play Order” view

I always used the “Artist” option myself and this was reading the network playlists a suffering, I even timed almost 5 minutes to read a simple playlist !!

After I started to leave this way, the reading browsing the playlists in network is very quick!

And there is even a certain logic if you see, because when you create the playlist in Engine Desktop, she see in “Play Order” format by default, and when you choose another viewing on the player, probably the player will have to do a processing of the whole The network library to show you in the configuration you want! I think the slow is there, because even doing it on the very player where the SSD is, internal or external, the reading is slow too!

Then take the test by loading the playlist in the “Play Order” view see if you solve your slow problem.

2 Likes

That’s indeed a viable workaround. It’s still being worked on. Opening networked smartlists is another issue.

3 Likes

It is still very much an issue, my linked player started to freeze on me yesterday during my set very frustrating, has anyone also experienced lag when using streaming services? I have found with beatport and tidal some tracks take ages to load (as in 1-2 minutes) or just fail to load at all my ssd is no where near full so not sure if it’s a wifi issue or a caching issue

1 Like

From an SQL point of view it makes sense what @djleh82 is saying, when you add an ‘order by’ to a query, or build column sorting into a report page, performance of the query does take a massive hit. Or at least it does in my workspace.

2 Likes

The thing is it works fine on the player with the drive connected so it should be possible to get it to work properly on the linked player it wont be a bandwidth issue at 100mb/1gb network speeds it must be a bug/issue with the way it is shared across players.

Keep reporting this issue so the powers that be can perhaps bump it up the list.

Not sure what is causing it.

The playorder method is a workaround but if you try to perform a search you are back to slow result.

Playorder workaround also requires manually saving the sort order / resorting any time I add a track to a playlist.

Observations

  1. It only happens when you initially select a drive as source on the linked player. If you switch drives you are back to initial state again.

  2. Selecting a drive and giving it time does not speed things up. One has to do a search for the process to initiate.

Not sure if the 100mb ethernet speed is the bottle neck, if the linked player has to download the host m.db when a query is sent from the linked player. My mdb file is almost 1Gb in size.

Google tells me 1GB file over 100Mbs Ethernet takes about 1mins 25secs which approx the same amount of time I’m getting before the linked player is able to perform properly.

3 Likes

Yes I guess that would make sense but the player shouldn’t really have to download the whole database, I guess it just needs to be optimised or the way it is handled reworked/tweaked. My m.db is approx 1200meg one way to speed it up could be if you have a drive/usb or sd card in the linked unit it could cache a copy there on start up and just sync changes.

1 Like

How long does it take you to get a search result on the linked drive initially?

Have you timed it?

select drive,

let it show the initial playlist tree (usually fast)

Then type a search and time it.

Just tried it now on V3.3.0 it took 70 seconds on the linked player. For reference I have a decent Samsung NVME drive in a USB 3.2 enclosure.