Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[flac.rules]

When MC has a lot to do, the UI can hang up totally, this is especially the case with a remote library, when building thumbnails because new videos are added, when a computer is restored from sleep and network connectivity is not properly established after the sleep, and it seems to be a bigger problem in theatre view. Some parts of the gram give some kind of indication that something is happening, but more often than not the entire UI hangs up. I think some effort should be made to prevent this from happening, it is very annoying, and MC is by far the worst program I have when it comes to this. Playing music seems to have a high priority, and rarely stops if the program doesn't hang totally which is good, but the UI not "hangin" shoudl also be a priority IMHO (although of course not as high as the music continuing to play), I hope some progress can be made on this.

[glynor]

You should read through the Troubleshooting Guide. That kind of behavior is not normal for everyday usage:
http://wiki.jriver.com/index.php/Troubleshooting_Guide

There are a few common causes of UI non-responsiveness:
* Interference by an Anti-Virus or security application
* Storing your Library on a slow disk (the database, not the media files)
* The Missing Files indicator when a large portion of your media files are on a very slow disk (like a NAS)
* Resource intensive background tools running (like thumbnail building or audio analysis) can also cause slowdowns while running. You can run these tools yourself overnight and get the background work done to improve responsiveness.

Troubleshooting all of this stuff is covered in the guide.

[Hendrik]

Unfortunately, its not about "priority", but general design. Whenever you do any file operation, the UI can hang, unless you move the file operation onto a separate worker thread and only give feedback back to the UI.
This is done with many operations, but unfortunately not with all. If you find a common operation you do, which has a reproducible hang, it might be helpful to outline what you are doing exactly (exact steps), and we can try to find this specific one and see how much re-design it would be to move it to a worker thread as well  (its not always all that easy). Just going blindly through the sources of MC and trying to find such things is not going to be very fruitful, so if you encounter such things often, try to reproduce them and note how you did so.

[flac.rules]

You should read through the Troubleshooting Guide. That kind of behavior is not normal for everyday usage:
http://wiki.jriver.com/index.php/Troubleshooting_Guide

There are a few common causes of UI non-responsiveness:
* Interference by an Anti-Virus or security application
* Storing your Library on a slow disk (the database, not the media files)
* The Missing Files indicator when a large portion of your media files are on a very slow disk (like a NAS)
* Resource intensive background tools running (like thumbnail building or audio analysis) can also cause slowdowns while running. You can run these tools yourself overnight and get the background work done to improve responsiveness.

Troubleshooting all of this stuff is covered in the guide.

I have troubleshooted all this, it is helpful for some problems, but doesn't solve it, for instance, you do add new videos from time to time, the whole UI become unresponsive to buid a thumbnail is not ok. Having the library on a library server should work without problems. Some thing just takes more than zero time for the program to perform, and the program should be able to handle this without the UI hanging up.

[flac.rules]

Unfortunately, its not about "priority", but general design. Whenever you do any file operation, the UI can hang, unless you move the file operation onto a separate worker thread and only give feedback back to the UI.
This is done with many operations, but unfortunately not with all. If you find a common operation you do, which has a reproducible hang, it might be helpful to outline what you are doing exactly (exact steps), and we can try to find this specific one and see how much re-design it would be to move it to a worker thread as well  (its not always all that easy). Just going blindly through the sources of MC and trying to find such things is not going to be very fruitful, so if you encounter such things often, try to reproduce them and note how you did so.

Ok, maybe design is more covering word than priority, but the point is the same.

It is easier to give concrete examples when behavior is "non-ideal" from the user, since that is more consistent, but examples are:

Theatre view is very sluggish and can hang totally when you add several large video files and have to use the view straight afterwards.
Theatre view can be slow to update when changing songs
Theatre view can hang up after a computer goes into sleep and back again, probably because of dropped connectivity for a short while.

All this is when running a library on a library server, which seems to increas the changes of UI hickups greatly.
 

[Hendrik]

I thought you were talking about hangs?  Sluggish behavior when a background task is running is probably just a sign of not enough processing power. We already run background tasks on a lower priority than the UI, but everything else is left to the OS and its allocation of resources to different tasks. Its rather hard to make processing a full video run "slower" without it taking much too long to ever finish and annoying users that way, so we reduce its priority and let the OS schedule the available CPU time accordingly.

[mwillems]

The following activities routinely hang MC's UI for me:

1) Putting a CD in the drive (UI completely non-responsive for between five and thirty seconds every time)
2) Loading, unloading, or otherwise changing a library in library manager (hangs as long as it takes, which can be a bit)
3) Stopping live TV playback (networked tuner, hangs for ten to thirty seconds everytime, sometimes indefinitely)
4) Allowing a client machine in Theater View to sleep and then wake up causes a hang for me, especially on machines connected with WiFi (probably related to reestablishing the network connection).

#1 seems to hang UI on other programs too, so that may be unavoidable, although some programs seem to handle it much better than others.  It makes sense why #2 might prevent interaction with the rest of the program, but if you click outside the box, everything goes white and you lose all progress indicators.  

[flac.rules]

I thought you were talking about hangs?  Sluggish behavior when a background task is running is probably just a sign of not enough processing power. We already run background tasks on a lower priority than the UI, but everything else is left to the OS and its allocation of resources to different tasks. Its rather hard to make processing a full video run "slower" without it taking much too long to ever finish and annoying users that way, so we reduce its priority and let the OS schedule the available CPU time accordingly.

All the examples specifically says that the UI hangs? And yes, I am talking about the UI hanging. Not enough processing power for what? Drawing the UI in no way taking more than one CPU-core of power, using the others for processing the video is more than enough for doing the work. And even if it couldn't, it much better that it doesn't finish when in theatre view, than making the UI sluggish or hanging it up totally, having the info from the video-file isn't that extremely critical.

[flac.rules]

2) Loading, unloading, or otherwise changing a library in library manager (hangs as long as it takes, which can be a bit)

4) Allowing a client machine in Theater View to sleep and then wake up causes a hang for me, especially on machines connected with WiFi (probably related to reestablishing the network connection).

2) Yes, good point, this totally stops the UI, and can take a while
4) Yes, as mentioned, I have the same problem.

[mwillems]

All the examples specifically says that the UI hangs? And yes, I am talking about the UI hanging. Not enough processing power for what? Drawing the UI in no way taking more than one CPU-core of power, using the others for processing the video is more than enough for doing the work. And even if it couldn't, it much better that it doesn't finish when in theatre view, than making the UI sluggish or hanging it up totally, having the info from the video-file isn't that extremely critical.

A "hang" is a term of art that refers to being in a "this program is not responding," type state, not just moving slowly.  Several of your items are just sluggish UI, which isn't the same as a hang (and is probably a CPU limitation of your server or client)

[flac.rules]

A "hang" is a term of art that refers to being in a "this program is not responding," type state, not just moving slowly.  Several of your items are just sluggish UI, which isn't the same as a hang (and is probably a CPU limitation of your server or client)

All of them is the UI freezing totally, as stated. A few of the items can manifest as sluggish UI also, but I specifically stated that it hangs also.

[glynor]

The following activities routinely hang MC's UI for me:

1) Putting a CD in the drive (UI completely non-responsive for between five and thirty seconds every time)
2) Loading, unloading, or otherwise changing a library in library manager (hangs as long as it takes, which can be a bit)

These I see. #1 in particular I know is a Windows limitation. MC could do better with #2, though. I get hangs fairly frequently when changing Libraries.  I know it is doing something pretty difficult.  It would probably be better if it just explicitly restarted the entire application (rather than trying, and sometimes failing, to do it in-place).

3) Stopping live TV playback (networked tuner, hangs for ten to thirty seconds everytime, sometimes indefinitely)
4) Allowing a client machine in Theater View to sleep and then wake up causes a hang for me, especially on machines connected with WiFi (probably related to reestablishing the network connection).

These I haven't had an opportunity to see (I'm not using MC for Live TV playback yet, and my network clients don't sleep with MC running).

Theatre view is very sluggish and can hang totally when you add several large video files and have to use the view straight afterwards.
Theatre view can be slow to update when changing songs

These I do not see, at all.

When MC imports new files, the UI does sometimes "blip" as it is re-draws the view, but this lasts less than 1 second, even if a ton of new files have been imported. Of course, if you're trying to do audio-analysis or thumbnailing when importing, and the server is resource limited, then this could cause pain. I don't see it happen, though.

Again, I'd strongly recommend you go through the guide. Assuming you have thumbnailing and audio-analysis turned off in Auto-Import, or have a decent CPU in the server, then I'd be willing to bet you a beer that something on your machine(s) is causing the UI responsiveness issues you're describing. I'm totally guessing, but both of those sound like issues that could be caused by high-latency access to the Library files on disk.  This could happen if:
* The machine serving the Library has the Library itself stored on a slow disk.
* The client machines have their cached copy of the Library stored on a slow disk (if you've redirected the AppData directories for your user account).
* Anti-Virus is interfering with MC's ability to access the Library.

[flac.rules]

When MC imports new files, the UI does sometimes "blip" as it is re-draws the view, but this lasts less than 1 second, even if a ton of new files have been imported. Of course, if you're trying to do audio-analysis or thumbnailing when importing, and the server is resource limited, then this could cause pain. I don't see it happen, though.

Again, I'd strongly recommend you go through the guide. Assuming you have thumbnailing and audio-analysis turned off in Auto-Import, or have a decent CPU in the server, then I'd be willing to bet you a beer that something on your machine(s) is causing the UI responsiveness issues you're describing. I'm totally guessing, but both of those sound like issues that could be caused by high-latency access to the Library files on disk.  This could happen if:
* The machine serving the Library has the Library itself stored on a slow disk.
* The client machines have their cached copy of the Library stored on a slow disk (if you've redirected the AppData directories for your user account).
* Anti-Virus is interfering with MC's ability to access the Library.

As i said, I have follwed the guide, it doesnt solve it. I am talking about video files.When they are added and you go into theatre view straight afterwards it seems to be reading video files to get som info.

All machines are newer desktop quad.core CPUs, and all librarys are on SSDs.

Have you tried adding several large video files to the library server library, and then accessing the library eith a client in theatre view shortly thereafter?

[glynor]

Yes. Every day.

[glynor]

Turn off Analyze Audio for videos in Auto-Import if you want to access them immediately without issue. Assuming you do have the library caches on SSDs, and you have excluded the Library locations properly in your AV application (or run without, if you want, I suppose), then this is the most likely cause. There is a delay before the clients get synced, but this does not impact performance.

Analyzing audio, as is explained in the Background Tools sub-article, requires time and CPU power, and can certainly impact performance. Perhaps there is more they can do here, but they are somewhat hamstrung by the third-party decoding filters used (depending on the file type in question at any given moment).

[flac.rules]

Turn off Analyze Audio for videos in Auto-Import if you want to access them immediately without issue. Assuming you do have the library caches on SSDs, and you have excluded the Library locations properly in your AV application (or run without, if you want, I suppose), then this is the most likely cause. There is a delay before the clients get synced, but this does not impact performance.

Analyzing audio, as is explained in the Background Tools sub-article, requires time and CPU power, and can certainly impact performance. Perhaps there is more they can do here, but they are somewhat hamstrung by the third-party decoding filters used (depending on the file type in question at any given moment).

Thanks for the tip, however, I feel this is a sidetrack. Turning of audio analysis is a workaround, with a pretty bid downside, and only impacts one of many situations. Even though MC is a bvery fast program for most of its tasks, there will ALWAYS be some tasks that is not finished instantly, and when that happens, the UI should as far as possible still be functional, I shouldnt need to turn of analysis just to get a smooth UI, that is the whole point of the thread, the priority should be playing content - > keeping the UI running nice and smooth -> everything else. Especially with things like analyzing audio which takes some time anyway.

[JimH]

The UI is probably not the problem.  The network is.

Try using local files and you will probably see the difference.

[flac.rules]

The UI is probably not the problem.  The network is.

Try using local files and you will probably see the difference.

As I said, it shouldn't make a difference (for the UI), although MC is very fast, it will never be fast enough that all operations takes zero time, and when an operation takes less then zero time, the UI should be fully functional. Besides, storing files locally is not a functional option.

[flac.rules]

I would like to bump this, I am not after solutions to concrete problems, mye point is the following:

There will ALWAYS be operations that takes some time in the program, solving one or two of the things taking time does not change this.
 The UI should be fully functional in all these instances.

[Listener]

I would like to bump this, I am not after solutions to concrete problems, mye point is the following:

There will ALWAYS be operations that takes some time in the program, solving one or two of the things taking time does not change this.
 The UI should be fully functional in all these instances.

You have shared your generalized wisdom several times.  You are lecturing the JRiver crew who have detailed knowledge of what's needed to make a first rate media player with all sorts of functionality.  They do the work; we users just kibitz.

If you use a tool like Process Explorer on Windows, you'll see that MC already uses threads to isolate audio playback from the UI.  In addition, there are background threads for other things.

Anytime you split off an asynchronous activity, you have to deal with status monitoring, notification and completion actions.  Those are real world considerations.  Do them badly and the UI will be far worse.

Since you are not after a solution to a concrete problem, you have made your point.

[glynor]

Yeah. There are a few concrete places where MC could do better, and I think we've outlined a few in this thread.  Generalizations like that, though, usually aren't very helpful. All planes also shouldn't crash, but sometimes they do.

They make substantial efforts (far above other competing similar applications) to make sure the UI remains responsive at all times. For the vast majority of operations, it does. It certainly does way better than Windows Media Player or iTunes, especially with a large Library size.

Media Center is software written by humans. Like humans, it is not perfect. And it runs on top of other software, like Windows or OSX, which is also written by imperfect humans. And the OS uses drivers written by imperfect humans, to control firmware written by imperfect humans, to make hardware chips designed by imperfect humans do things that often involve electrons acting at quantum scales where we have an imperfect understanding of the laws of physics.  It is crap the whole way down.

Specific examples of repeatable steps that cause the UI to freeze, may be helpful where it is possible to make changes to correct it. Sweeping generalizations like the one in your "bump" are both obvious and completely non-actionable.

[flac.rules]

You have shared your generalized wisdom several times.  You are lecturing the JRiver crew who have detailed knowledge of what's needed to make a first rate media player with all sorts of functionality.  They do the work; we users just kibitz.

If you use a tool like Process Explorer on Windows, you'll see that MC already uses threads to isolate audio playback from the UI.  In addition, there are background threads for other things.

Anytime you split off an asynchronous activity, you have to deal with status monitoring, notification and completion actions.  Those are real world considerations.  Do them badly and the UI will be far worse.

Since you are not after a solution to a concrete problem, you have made your point.

Yeah, the crew has more knowledge than me on the program and I am also sure it's not extremely simple to fix, but I don't quite see your point? Should users not give feedback on what they think should be improved in the program? (I don't know what "kitbitz" means, so I could be misunderstanding you)

I have listed sever concrete instances in the thread where this happens. The concrete problem is the UI hanging up on certain time-consuming tasks, especially if network traffic/server/client is involved.

[flac.rules]

Yeah. There are a few concrete places where MC could do better, and I think we've outlined a few in this thread.  Generalizations like that, though, usually aren't very helpful. All planes also shouldn't crash, but sometimes they do.

They make substantial efforts (far above other competing similar applications) to make sure the UI remains responsive at all times. For the vast majority of operations, it does. It certainly does way better than Windows Media Player or iTunes, especially with a large Library size.

Media Center is software written by humans. Like humans, it is not perfect. And it runs on top of other software, like Windows or OSX, which is also written by imperfect humans. And the OS uses drivers written by imperfect humans, to control firmware written by imperfect humans, to make hardware chips designed by imperfect humans do things that often involve electrons acting at quantum scales where we have an imperfect understanding of the laws of physics.  It is crap the whole way down.

Specific examples of repeatable steps that cause the UI to freeze, may be helpful where it is possible to make changes to correct it. Sweeping generalizations like the one in your "bump" are both obvious and completely non-actionable.

I am not suggestiong MC should be perfect, I have concrete suggestions on how the program could improve. And while MC is very fast at handlign large libreries, I do not share the view that is far above other applications when it comes to UI-responsivness, in fact from my perspective, it is below average, most operations are fast, and faster than the competition, but UI-hang-up happens more often. I have tried several media-programs in which I have never seen the UI totally frozen like can happen in MC.

I have given specific examples in the thread. The specific examples caused suggestions for work-arounds, many of which goes at the expense of functionality. I can give more examples of situations that can hang the UI:

Manually syncing back changes to the server from the client can hang up the client
Not exactly the same type of hangup but when going into the "hanheld"-options the window stand there for å couple of seconds without updating.

I think the same as JimH, the network is the (main) problem, in that some operations take a longer time on a network server/client setup, but I don't think that should hang up the UI, if it works locally, the UI should be responsive even if the same operation takes a longer time over a network.

[Listener]

Yeah, the crew has more knowledge than me on the program and I am also sure it's not extremely simple to fix, but I don't quite see your point? Should users not give feedback on what they think should be improved in the program? (I don't know what "kitbitz" means, so I could be misunderstanding you)

I have listed sever concrete instances in the thread where this happens. The concrete problem is the UI hanging up on certain time-consuming tasks, especially if network traffic/server/client is involved.

In your last post, you said

"I would like to bump this, I am not after solutions to concrete problems, mye point is the following:

There will ALWAYS be operations that takes some time in the program, solving one or two of the things taking time does not change this.
 The UI should be fully functional in all these instances."

You said that you didn't have a concrete problem.  You have shared your philosophy.  Give it a rest.

[flac.rules]

In your last post, you said

"I would like to bump this, I am not after solutions to concrete problems, mye point is the following:

There will ALWAYS be operations that takes some time in the program, solving one or two of the things taking time does not change this.
 The UI should be fully functional in all these instances."

You said that you didn't have a concrete problem.  You have shared your philosophy.  Give it a rest.

Ok, I guess that was somewhat unclear, what I am saying is that (although they can be helpful), workarounds like "use local files", "disable this functions" doesn't really address the point I am trying to make. And that was mainly what was in the thread when it came to concrete feedback concerning the problems listed. That is why I bumped it, to try to get it back on track.

[glynor]

I do not share the view that is far above other applications when it comes to UI-responsivness, in fact from my perspective, it is below average, most operations are fast, and faster than the competition, but UI-hang-up happens more often. I have tried several media-programs in which I have never seen the UI totally frozen like can happen in MC.

As I've repeated several times in this thread: That is because there is something wrong with your installation.

There are limited instances where this happens in MC. If you are seeing periodic hangs of the UI during normal operation, this is not normal. I have a ton of installations of MC running on a variety of hardware and virtual environments. MC is immensely more responsive than other similar applications. Either you are doing something extreme with your setup, you have overly complex views (possibly with extensive, possibly pointless, searches), you have an anti-virus application interfering, or there is something broken in your installation, hardware, or network environment. Or, you are ridiculously sensitive to it, and other applications must drive you completely batty.

If you would like to investigate this, I'm still willing to help, but you have to put in some work and actually explain what you've tried from the guides I've referenced repeatedly in this thread. What performance benchmarks do you have? Where are things stored? What happens when you test with local files? If you want to actually solve the issue, instead of complaining and insisting that JRiver fix vaguely defined things that may or may not exist, then... Let me know.

Up until now, your attitude has been "I'm sure there's absolutely nothing wrong with my stuff, your stuff is broken, fix it."  That's not a good way to get help. I guarantee that the stuff I've said above isn't just because I don't use it heavily and haven't noticed. I've had, and fixed, many responsiveness problems in the past with MC. That's why I wrote the guide.

[flac.rules]

As I've repeated several times in this thread: That is because there is something wrong with your installation.

There are limited instances where this happens in MC. If you are seeing periodic hangs of the UI during normal operation, this is not normal. I have a ton of installations of MC running on a variety of hardware and virtual environments. MC is immensely more responsive than other similar applications. Either you are doing something extreme with your setup, you have overly complex views (possibly with extensive, possibly pointless, searches), you have an anti-virus application interfering, or there is something broken in your installation, hardware, or network environment. Or, you are ridiculously sensitive to it, and other applications must drive you completely batty.

If you would like to investigate this, I'm still willing to help, but you have to put in some work and actually explain what you've tried from the guides I've referenced repeatedly in this thread. What performance benchmarks do you have? Where are things stored? What happens when you test with local files? If you want to actually solve the issue, instead of complaining and insisting that JRiver fix vaguely defined things that may or may not exist, then... Let me know.

Up until now, your attitude has been "I'm sure there's absolutely nothing wrong with my stuff, your stuff is broken, fix it."  That's not a good way to get help. I guarantee that the stuff I've said above isn't just because I don't use it heavily and haven't noticed. I've had, and fixed, many responsiveness problems in the past with MC. That's why I wrote the guide.

I have explained what I have tried of your suggestions earlier in the thread. I have tried every one of the suggestions:

I have excluded the AV
All installs are on SSDs (clients and servers)
The library is not on a slow disk.
I have run through the entire troubleshooting guide.

The slowest client has a Jmark score of about 2700, Server machine has a score of about 4000. The files are stored on the same computer as the one running the JR server. Let me know if you benchmarks from the other clients.

Couldn't you say the same the other way? Its just that "your stuff" is the program and "my stuff" is my computer?

I seem to be rubbing people the wrong way somehow, and for that I apologize, I am not trying to be neither rude nor unhelpful, and as far as I can tell I am answering the questions popping up to the best of my knowledge. Let me assure you that I am trying as best as I can.

The library sync hangup mentioned earlier might be a "false case" though, i was getting it after the "checking library for changes stage", but there seems like the actually is a new dialog box then "sending changes", however it sometimes doesn't show, maybe in connection with changing windows focus or pressing some keys.

But can I ask you a question: When it comes to the specific case of background tasks (analyse audio, build thumbnails) do you disagree that the program should ideally handle this without UI-hiccups? I know its a bit on the side of the problems being discussed, but I am wondering if we see this very differently.

[mwillems]

But can I ask you a question: When it comes to the specific case of background tasks (analyse audio, build thumbnails) do you disagree that the program should ideally handle this without UI-hiccups? I know its a bit on the side of the problems being discussed, but I am wondering if we see this very differently.

I think the issue that most of us don't see UI interruptions when audio analysis or thumbnail building are going on.  I certainly don't, even when adding or analyzing large numbers of files.  Most of the "workarounds" suggested above are diagnostic troubleshooting steps designed to see where the issue is in your setup.  The suggestion to turn off analysis on import was based on a theory that your server (machine doing the importing) lacked the power to do the analysis and keep the UI responsive at the same time.  But based on those JRMarks, it looks like you're not CPU bottlenecked, which means that: as glynor said, either something in your network or your software configuration is borked.

The only times I see hangs are in the four cases I listed at the top of the thread.  I never see hangs (on clients or server) when adding new media.  I might see a half second flicker once in a while when I'm actively browsing a view as it's being updated, but I mean that literally.  It's just enough of a pause that I notice it, but not so long that I wonder what happened.  And it's not even close to every time.  For comparison, my server is running in a virtual machine with a JRMark lower than yours, and I don't have these issues.

Think of it another way: no one here seems to be seeing the kind of UI hangs/sluggishness you're describing.  If the devs can't reproduce the issue it means one of two things:1) they don't have enough information to fix a hypothetical actual problem with the software or 2) there is no actual problem with the software and it's an issue local to your setup.  

Either way, providing more information, is the answer to your problem. Start with:

1) How is your network configured? (wired or wireless, do the clients have direct access to the files, or is the server being forced to serve the files as well as the library)
2) Do you only see this in theater view, or in standard view as well
3) Do the machines in question have video cards or only integrated graphics (if integrated, what kind)
4) Have you checked your 3d graphical settings in Options and tried different settings?
5) What specific steps did you take to deal with your Anti-Virus

[glynor]

Couldn't you say the same the other way? Its just that "your stuff" is the program and "my stuff" is my computer?

No, because I don't work for JRiver. I have no skin in this game. I'm just telling you what I've found based on extensive experience.

I think the issue that most of us don't see UI interruptions when audio analysis or thumbnail building are going on.  I certainly don't, even when adding or analyzing large numbers of files.

Nor do I. Performance is impacted slightly, of course, if I'm analyzing a bunch of files, but not to the point where I'd call it frozen or sluggish at all. I regularly use MC for other tasks while analyzing and importing huge sets of files.

Audio analysis during import can certainly impact responsiveness, depending on your particular setup. It is designed to be low process priority, but not to an extreme (otherwise it would take forever). It is a balance between using resources, and completing quickly (otherwise, the impact is just stretched out and bothers you for longer). Hendrik (who does work on the code) explained this above.

The biggest single factors are CPU, disk throughput, and RAM. A lot also depends on the Views you've structured in your Library. I don't have enough information about your setup to diagnose the cause, but a pretty decent wild guess would be that you're mostly limited by disk throughput because your storage medium for your files is on a slow NAS, and you haven't disabled the option described in the guide that checks for file availability. Or maybe you've moved the thumbnail cache storage off to a slow disk? Everything you've described sounds like a storage bottleneck.

Your media storage might also be just too slow to use for audio analysis during import without impacting responsiveness. If this is the case, you can either turn it off, or change your staging area to a faster disk so that the analysis and initial import happens on a fast disk, and then you move the files to the very slow storage afterwards.

But there are a wide variety of possible causes. I'm guessing in the dark.