[BUG] MediaBay extraordinarily slow on NAS

As I’m moving a lot I do a lot of work on my laptop. It has only a small built-in HD so I offloaded all of my sample libraries on my NAS. I point MediaBay to it to index all my sample libraries. But when I open the MediaBay, it takes AGES to display the MediaBay window.


  • Every time I open the MediaBay window, it takes about 30-40 seconds to display the window
  • My list of libraries is big, when I scroll down the list to select a specific folder, the scrolling locks the window completely for another 30 seconds.
  • Clicking on a folder lists the samples quickly. I can click on any sample and it almost starts playing immediately, very fast. Also large files of 100MB and more are displayed quickly and instantly played back. Meaning my network speed is OK.
  • The portions of the folder list it loaded are then fast for scrolling. I can scroll up no problem, but when I scroll further down, it again takes ages to load for the first time.
  • When I close MediaBay and open it again, all this mumbo jambo starts again, taking the window 30-40 seconds to display. Then taking a long time scrolling in the list.

Conclusion: Some network code or how MediaBay handles its local library cache is not right. It’s OK for MB to scan folders in the background, but not blocking all of Nuendo. MB should display instantly. It has an index of all the folders locally, right? So it can look up folders and files locally, no need to freeze the whole computer. Or is there a setting?

Here’s what I mean:

Actually, this is a database engine-problem.
For obvious licencing reasons, Mediabay uses a free database engine, which is highly unadequate for handling large databases on networked folders.
As long as you use Mediabay locally, there isn’t much problem, but mounting drives slows it down to an annoying level.

I love Mediabay, although it lacks a lot of features, and sometimes it is a PITA to work with.
So, for Q&D jobs, we use Mediabay mounted locally.
The problem is, that after adding a Library, we need to update Mediabay for each room.
For dropping & cutting SFX into bigger projects, we use Basehead, which blows SoundMiner out of the water without blinking.


Isn’t the database itself saved in a local folder? I cannot find a database file anywhere on my NAS. Reading the database file itself from the local HD should be super fast. The database doesn’t need to go running around on the NAS at all. Nuendo looks at the mounted drive, reads the necessary files, indexes them and writes the metadata into the local database file. Then only reads from this local file. I don’t understand what’s slow about this. I’m sure there’s a solution to the problem, open source database or not?

Also, once I waited through all the scrolling, it’s fast afterwards. As long as I don’t close MediaBay. That means there must be a way of getting this to work fast by loading it in advance or something.

I really like MediaBay because it does 90% of the most needed tasks when looking for external samples, it’s built-in, so I don’t have to buy another tool.

btw: that’s what i meant in the other post. Nuendo HAS all those features, they’re just implemented in a way to kill the user one paper cut at a time. When in fact they could work wonderfully and beat all compoeitors out of the water.

That’s what I meant in my other posts with trust.
I don’t see the point using a database system that is slow as hell on network drives. Although we all have local copies of sound effects here and media bay is not fast but fast enough for my work, I really don’t see why a software company would chose to implement a slow database that certainly does not do the job for larger facilities. Why don’t they just increase the price and do things properly?

Why do they implement a new noise reduction in Wavelab that is far worse than the one they had before?

The Pro labelled products should be more expensive but working without compromises.

Local copies, yes, on a network drive :wink: Not over the internet. MediaBay being slow over a VPN over internet I would understand, but a network drive that provides data at 120MB/s should work fine. As I said I don’t have a harddisk big enough in my mobile laptop rig that can hold all my samples and I use my NAS for other things, too, like backup, media, project archive… I don’t want to add an external USB3 hard drive to add to the complexity. A NAS or big network drives in a company are not something exotic anymore.

Yet, even Native Instruments ignores NAS drives. You cannot install their products on a NAS. You can move Kontakt libs to a NAS after installation, but Kontakt is so painfully slow over network, too. Probably they also didn’t know how to implement their database in a proper way. There are a TON of open source free databases out there, some of them being used in big data facilities and proven to be fast for number crunshing and web commerce, processing thousands of orders in seconds. That’s certainly enough power for MediaBay and Kontakt.

I can only repeat … We have about 7 TB of Sound efefcts stored on NAS servers (Synology’s mostly) and have zero problems as long as the database is stored locally. We do have speed problems when we Mount the databases to the Shared Folders.


This is how long it takes to search our drives:

OK I didn’t get that you can specify the location of your database. Where can you do that? I haven’t actively chosen a place to store my database.

Update: I just read that you can create volume databases on external drives. I didn’t do that. I went to my NAS in the network drives section in the “Define Locations”, browsed to my sound effects library, selected the folder and clicked on Add, to add this location to the Locations Dropdown for quicker access. That’s all I did. So the database should be local?

I noticed that when I just browse to the network drive and search, it’s quite fast. But when I open my library folder that contains my libraries, this list of folders brings MediaBay to a halt. I think displaying the directory tree might be slow or something.

Chris I hear you and yes that is killing us here as well when we need to administrate The library.
This MIGHT be a mac only issue as I have not heard about this issue from any PC users.

So the mediabay issue are two fold.

Storing databases on network drives is extremely slow for all users.

Navigating the locations folder tree in the left side panel is SUPER slow. As soon as the folds have been found and indexed and added to favourites it’s fast in everyday use. It is the scrolling and opening of folders of the location tree that is super slow. This part might be mac only.

So my bug report stays. The library is stored locally and should be fast. There is no reason for a simple “folder list” to freeze the whole computer for several seconds. Something is fishy here and I think it should be fixed.

I tried it on PC and there it’s fast so it might be a Mac only issue. I backup tons of data to the NAS, in Finder and other file browser tools I can access and list the folder structure in no time, but MediaBay seems to have problems scanning through the amount of folders. I don’t know why it first wants to scan all directories every time I open the window, it seems it should be able to do that in a background thread or cache the directory list. But it locks up Nuendo and almost my entire machine as long as it’s building the directory tree.

I thought that’s why there is the manual option to re-scan directories. So it doesn’t constantly roam around on the harddisk. I think this could be optimized not to unnecessarily read all folders and sub-folders with every window open, only when the user re-scans deliberately.

I just tested Basehead on Mac and it seems it has the same issue with displaying large directory trees over network. When I go to the browse tab to browse directories live, when I scroll down the folder list, it needs to reload stuff and it takes a few seconds. It’s still faster than MediaBay and in Basehead it only happens when I actually browse the directories. When I just open the database search and search in it, it’s fast, no lag.