INTERACT FORUM
More => Old Versions => JRiver Media Center 24 for Windows => Topic started by: mirdle on April 18, 2018, 08:01:41 am
-
I've got way too many files, but v. 23 had done a good job with usually being very responsive with search results.
I upgraded to 24, same library same layouts same setting etc, but now there is a consistent 5+ second delay after every query in the search bar. This delay doesn't exist on 23.
Any ideas?
-
Switched from MC23 32bit to MC24 64bit as it was announced that 64bit now has all the features. Search is definitely much slower. Search also crashed MC and after restarting MC ctrl+f stopped working.
-
Switched from MC23 32bit to MC24 64bit as it was announced that 64bit now has all the features. Search is definitely much slower. Search also crashed MC and after restarting MC ctrl+f stopped working.
I've also seen this! today
-
I'm still having the same problem.
I did a little experimentation.
I uninstalled all versions of JRiver.
I did a clean install of JRiver 24 64 bit version on Windows 10.
I restored my library (library only, no settings) and search was fast again.
I added a DLNA renderer and starting playing to it. Search was still fast.
I imported some files from a single folder. Search was still fast.
Then, about 20 minutes later, I tried searching again and the same problem as before -- at least a 5 or 6 second delay after every query.
-
Without doubt there is a distinct and frustrating Search lag when using the new fangled MC24 64bit.
-
Hmmm, not seeing any type of delay here. I'm typing something into the search bar and within a second the results appear.
If you're using Windows 10, Windows Defender *could* be interfering with MC this way, not sure.
-
I disabled Windows Defender real time virus protection and saw no improvement.
-
i have no delay in search, whether on start up or after any amount of time
there must be something going on, it's hard to test though. if anyone has ideas i'll try
-
Uninstalled 64bit and installed 32bit version. CTRL+F worked until I restored library and MC restarted. 32bit version search was as slow as 64bit. MC23 (32bit) remains snappy... In virus checker I have same exclusions for MC24 and MC23
Could it be that backup/restoration process somehow corrupts the database? Everyone here who says everything is fine are beta team members so they probably have made jump to MC24 with earlier version.
-
I tried to reproduce this in the debugger, but search on my library seems really fast. If anyone has any more clues please share.
-
Are we talking about the Search box top right, or the new one under the Tag pane bottom left - or are they the same?
-
Suggestions are coming as fast as usual but view is not updated at usual speed
-
Are we talking about the Search box top right, or the new one under the Tag pane bottom left - or are they the same?
Top right. I don't see another search box.
-
Any complex calculated fields or large numbers of user fields?
Some library stats might be interesting too, I'm just fine with ~500,000 files and a couple of calculated fields.
-
Any complex calculated fields or large numbers of user fields?
Some library stats might be interesting too, I'm just fine with ~500,000 files and a couple of calculated fields.
MC23 with "same" database and views behaves as fast as used to. Getting also crashes when doing search in MC24. Turned Logging on to possible get some information about the issue
-
Sure, but that's not particularly helpful in narrowing down the problem :)
There's obviously something unique about the setups of those with the issue, & this needs to be isolated before it can be debugged.
Remember that MC is a massive codebase with large numbers of options that are different system to system.
Another idea:
Have you checked with any antivirus programs completely uninstalled?
The location, filenames & signature of MC changes with each new version, and antivirus programs sometimes take time to 'trust' a new app.
-
Strange... today the search is fast again, and I don't recall making any changes at all!
Could it have been performing a background function all this time?
-
Thumbnailing or audio analysis?
Also, see the point I made about antivirus above :)
-
MC 24 is extremely slow in removing files from a playlist, or deleting files completely. (I use a playlist for editing my library, identifying and removing missing files.) It is also very slow in opening a playlist from the tree. Building thumbnails is not enabled.
My library contains almost 900 K audio files, stored primarily in an NAS, with several additional external drives.
There seems to be some background process running. After completing a function, the program seems to hang for up to 15-20 seconds before returning to a stable state.
Is it possible that playlists are not designed for the uses I apply?
Per prior suggestions, I eliminated Bit Defender, installed Windows Defender and created exceptions for MC and for file associations. I'd appreciate any suggestions.
-
Did you uninstall Bit Defender? Disabling it isn't enough.
Background processes will take some time until they're done. Thumbnails, for example. You can see what is happening under Reporter.
-
I should have said it was removed entirely (Revo Uninstaller), not eliminated. Poor choice of words. Bit Defender has been removed completely.
It's still exhibiting that behavior, particularly with playlists. Is there something unique with the Playlists that makes them such problems? I've double checked thumbnails restore, which is not running, can't find any other settings that might affect performance.
Am I using Playlists for a purpose it wasn't designed for?
-
Well the search delay has returned. A few more library files have been added (no immediate delay after they were added), but I haven't messed with anything else the last few days.
It's almost like it is struggling to display the album thumbnails.
-
I'm seeing delay too... Although I don't really think that's it...
Say I'm typing the word search in the search bar, it's more like the delay is broken, so, it searches for s, then se, then sea, and so on. Feels odd.
-
I can't see any real difference :(
A thought though (Based upon the previous chap's post): Could it be evaluating smartlists / playlists somehow differently when the search is being triggered?
I use views not playlists, and 900k files in playlists / smartlists is rather a lot.
-
Suggestions come at usually fast speed for me but actual view update/refresh is much slower than in MC23. Also getting crashes when pressing one of the suggestion. Sent one dump for Matt but somehow file MC creates is not usable (size of file is unusual small).
I'm using Windows Security Essentials for Win7 64bit with exclusions (And yes, I have also uninstalled it and it didn't make any difference.
EDITED
-
The crash dump is useful for us because we have the symbols, just not useful for you. :)
-
The crash dump is useful for us because we have the symbols, just not useful for you. :)
I used wrong choice of words. Crash dump which MC creates in this case is for some reason too small so you won't be able to load the symbols with it.
-
To marko's point, not all 900 K files are in the playlist. A smaller subset, say 300 K files, were on the playlist. I see a marked difference between behavior when I delete files from the main library view (I only maintain a single library) and when I try to access/try to delete files from the Playlist in question. The latter is extremely slow to the point of unusability. The former is quite fast.
I've worked around the issue by adapting one of the Custom fields to that use, but am curious about the difference in response time between the main library and the Playlist.
-
To marko's point, not all 900 K files are in the playlist. A smaller subset, say 300 K files, were on the playlist. I see a marked difference between behavior when I delete files from the main library view (I only maintain a single library) and when I try to access/try to delete files from the Playlist in question. The latter is extremely slow to the point of unusability. The former is quite fast.
I just loaded a test library of 152,081 files.
I added all the files to a playlist, then selected a bunch of the files from the playlist (about half) and deleted and it was really fast.
Not sure what you might be seeing.
-
Matt - I had previously created a Playlist called 'H Drive Reconstruction'. I populated it with missing files and the files I was restoring from the cloud, then when a missing file was restored, I deleted the originally missing files and removed their replacements from the Playlist. That left me with a list of missing files I still needed to restore.
Now, when I'm working in the main library and go to the tree to open the Playlist, MC hangs for 2-3 minutes (sometimes indefinitely), and if/when it reopens and I try to remove a restored file from the Playlist, it hangs for up to 3-4 minutes before completing the action. Ditto, when I try to delete the missing original from the Library.
If I take the same action to delete missing files that have been restored in the main library, the deletion occurs in a matter of 2-3 seconds.
As I said, I've figured out a workaround (a little clunky) but wonder why there's such a difference in response time.
-
Would you be willing to send a library backup to matt at jriver dot com along with instructions on how to reproduce the slowdown (you gave a little, but in more detail)?
Thanks!
-
Any solution to this issue? I'm having the same problem with 24.0.19 (64 bit).