[1460+] MM4 performance with large library sucks
Moderator: Gurus
Re: [1350] MM4 performance with large library sucks
MM 1353 should improve this.
Best regards,
Peke
MediaMonkey Team lead QA/Tech Support guru
Admin of Free MediaMonkey addon Site HappyMonkeying
How to attach PICTURE/SCREENSHOTS to forum posts
Peke
MediaMonkey Team lead QA/Tech Support guru
Admin of Free MediaMonkey addon Site HappyMonkeying
How to attach PICTURE/SCREENSHOTS to forum posts
Re: [1350] MM4 performance with large library sucks
@ Devs thumbs up with the scanning!! It definitely much faster now Thanks
One of my other issues is still a problem, clicking on of of the nodes (and sub nodes) under music->location-> C:/D: etc. makes me wait for a few seconds making mm unusable for that time until that node has expanded.
One of my other issues is still a problem, clicking on of of the nodes (and sub nodes) under music->location-> C:/D: etc. makes me wait for a few seconds making mm unusable for that time until that node has expanded.
Re: [1350] MM4 performance with large library sucks
Expanding nodes is in general a little slow, but you're right, especially the location one.
Windows 7 Ultimate 64bit
AMD Phenom II x4 940 (3GHz)
ASRock A780
4GB DDR2 333
ATI Radeon HD 3200
Library on two disks : Western Digital Caviar 1.5TB - WDC 640GB
AMD Phenom II x4 940 (3GHz)
ASRock A780
4GB DDR2 333
ATI Radeon HD 3200
Library on two disks : Western Digital Caviar 1.5TB - WDC 640GB
Re: [1350] MM4 performance with large library sucks
We are looking for better Handling of location nodes. Firstly we have made things show in Real-time Fast and as number of tracks rise maintaining real-time and sorting proved difficult. We are investigating what and how things can improve without losing functionality/usage we all used too.
Best regards,
Peke
MediaMonkey Team lead QA/Tech Support guru
Admin of Free MediaMonkey addon Site HappyMonkeying
How to attach PICTURE/SCREENSHOTS to forum posts
Peke
MediaMonkey Team lead QA/Tech Support guru
Admin of Free MediaMonkey addon Site HappyMonkeying
How to attach PICTURE/SCREENSHOTS to forum posts
-
- Posts: 14163
- Joined: Sat Oct 25, 2003 7:57 am
- Location: (Texas)
- Contact:
Re: [1350] MM4 performance with large library sucks
peke windows / ms, has made some updates that cause realtime running of programs to be very slow, not sure what they did, but i'm getting faster times for programs running and or loading by using either above normal or normal prioritys anything higher is taking a chance if it is going to be what the setting is or slower then normal..
maybe that is messing with the nodes?
maybe that is messing with the nodes?
roving cowboy / keith hall. My skins http://www.mediamonkey.com/forum/viewto ... =9&t=16724 for some help check on Monkey's helpful messages at http://www.mediamonkey.com/forum/viewto ... 4008#44008 MY SYSTEMS.1.Jukebox WinXp pro sp 3 version 3.5 gigabyte mb. 281 GHz amd athlon x2 240 built by me.) 2.WinXP pro sp3, vers 2.5.5 and vers 3.5 backup storage, shuttle 32a mb,734 MHz amd athlon put together by me.) 3.Dell demension, winxp pro sp3, mm3.5 spare jukebox.) 4.WinXp pro sp3, vers 3.5, dad's computer bought from computer store. )5. Samsung Galaxy A51 5G Android ) 6. amd a8-5600 apu 3.60ghz mm version 4 windows 7 pro bought from computer store.
Re: [1350] MM4 performance with large library sucks
Location node is extremely slow and can cause MediaMonkey to hang all together here. Video node seems to be improved as pre-1355 it would hang a minute + as well on expanding.
Download MediaMonkey | License
Help: Knowledge Base | MediaMonkey for Windows 5 | MediaMonkey for Android
Lowlander (MediaMonkey user since 2003)
Help: Knowledge Base | MediaMonkey for Windows 5 | MediaMonkey for Android
Lowlander (MediaMonkey user since 2003)
Re: [1350] MM4 performance with large library sucks
Hi all, thanks for carrying on the topic/
Guess i'm no power user since i never had a clue about changing node while updating !
I reverted to MM3 and rescanned the 100k collection, in whatever node (most likely lib location) including 7k new entries. Took like 2hours. I don't notice any performance problem with mm3 on a i7/xp combo.
OTOH MM4 will have a hard time attracting users, even more so new ones if it ships as is, performance wise. Just my .02€...
Pardon my insisting on it, having posted several times about that, but making db file contiguous on drive has HUGE impact on overall experience. That works for MM3 as well as MM4. Here I'm talking overall browsing experience, not just scans and updates. Makes the thing so smooth you won't suspect a 100k collection. I mean WMP is slower with 1k ... The improvement is even more obvious with album arts on.
Wouldn't MM4 be a good time to look at db fragmentation ? Shouldn't be that hard to preallocate some space and prevent sparsing. NTFS has all windows needs for this. Not that it would make a difference here : my audio and db drive is vfat Maybe I'd put the db on an ntfs drive, then.
I'll wait until next release to reinstall and build a new db. Will keep an eye on performance. Thanks for the tip on node picking. Something tells me a LOT of "power users" would wish it was documented in plain sight somewhere
Rojer.
Guess i'm no power user since i never had a clue about changing node while updating !
I reverted to MM3 and rescanned the 100k collection, in whatever node (most likely lib location) including 7k new entries. Took like 2hours. I don't notice any performance problem with mm3 on a i7/xp combo.
OTOH MM4 will have a hard time attracting users, even more so new ones if it ships as is, performance wise. Just my .02€...
Pardon my insisting on it, having posted several times about that, but making db file contiguous on drive has HUGE impact on overall experience. That works for MM3 as well as MM4. Here I'm talking overall browsing experience, not just scans and updates. Makes the thing so smooth you won't suspect a 100k collection. I mean WMP is slower with 1k ... The improvement is even more obvious with album arts on.
Wouldn't MM4 be a good time to look at db fragmentation ? Shouldn't be that hard to preallocate some space and prevent sparsing. NTFS has all windows needs for this. Not that it would make a difference here : my audio and db drive is vfat Maybe I'd put the db on an ntfs drive, then.
I'll wait until next release to reinstall and build a new db. Will keep an eye on performance. Thanks for the tip on node picking. Something tells me a LOT of "power users" would wish it was documented in plain sight somewhere
Rojer.
Re: [1350] MM4 performance with large library sucks
Yes, the location node is way too slow. I checked the sql used and tweaked it a bit, making it twice as fast.
I also have some other ideas how to make it faster. I'll notify the devs with my findings
I also have some other ideas how to make it faster. I'll notify the devs with my findings
Advanced Duplicate Find & Fix Find More From Same - Custom Search. | Transfer PlayStat & Copy-Paste Tags/AlbumArt between any tracks.
Tagging Inconsistencies Do you think you have your tags in order? Think again...
Play History & Stats Node Like having your Last-FM account stored locally, but more advanced.
Case & Leading Zero Fixer Works on filenames too!
All My Scripts
Tagging Inconsistencies Do you think you have your tags in order? Think again...
Play History & Stats Node Like having your Last-FM account stored locally, but more advanced.
Case & Leading Zero Fixer Works on filenames too!
All My Scripts
Re: [1350] MM4 performance with large library sucks
Location node can take 2+ minutes on a clean install in the Video collection with 5 files in 1 folder.
Download MediaMonkey | License
Help: Knowledge Base | MediaMonkey for Windows 5 | MediaMonkey for Android
Lowlander (MediaMonkey user since 2003)
Help: Knowledge Base | MediaMonkey for Windows 5 | MediaMonkey for Android
Lowlander (MediaMonkey user since 2003)
Re: [1350] MM4 performance with large library sucks
I've stopped using mm4 for now, the speed of doing certain tasks is driving me crazy
Re: [13xx] MM4 performance with large library sucks
i am really disappointed with mm4 performance and at the moment it doesn't feel as if it is going to get better
with build 1361 location node feels a bit faster than previous builds, but scanning has gone backwards, it is slow again i cancelled my scanning after 7+ hours and it still wasn't finished, actually it was far from finished.... Right clicking a song and doing a search for the "same" lets mm hang for a bit, opening the tag window takes a few seconds before mm opens it up... Its all these small things that mm4 unusable for me, i stopped testing previous builds cause of that, with this build i decided to give it a try... what a disappointment.
with build 1361 location node feels a bit faster than previous builds, but scanning has gone backwards, it is slow again i cancelled my scanning after 7+ hours and it still wasn't finished, actually it was far from finished.... Right clicking a song and doing a search for the "same" lets mm hang for a bit, opening the tag window takes a few seconds before mm opens it up... Its all these small things that mm4 unusable for me, i stopped testing previous builds cause of that, with this build i decided to give it a try... what a disappointment.
Re: [13xx] MM4 performance with large library sucks
Yeah these things definitely need improvement BUT MM3 was slow at those things too so I don't expect MM4 to be any better than MM3 considering the added functionalities.
Windows 7 Ultimate 64bit
AMD Phenom II x4 940 (3GHz)
ASRock A780
4GB DDR2 333
ATI Radeon HD 3200
Library on two disks : Western Digital Caviar 1.5TB - WDC 640GB
AMD Phenom II x4 940 (3GHz)
ASRock A780
4GB DDR2 333
ATI Radeon HD 3200
Library on two disks : Western Digital Caviar 1.5TB - WDC 640GB
Re: [1350] MM4 performance with large library sucks
~2000 videos in 200 folders, -some with hundreds of videos-, and the speed feels absolutely normal; probably the same as with music.Lowlander wrote:Location node can take 2+ minutes on a clean install in the Video collection with 5 files in 1 folder.
MM5 (2606)and MM4 (1919) installed and running well on:
Debian 11 KDE, EndeavourOS KDE (wine 7.4 via playonlinux), Win10 64bit
Debian 11 KDE, EndeavourOS KDE (wine 7.4 via playonlinux), Win10 64bit
Re: [13xx] MM4 performance with large library sucks
Build 1362 is going to include additional performance improvements. Right now MM looks up an image everytime you select a file which _really_ slows things down with a video collection if it's stored on the network.
Also, keep in mind that you're using debug builds which are slower by nature. Once we get to the RC stage, we'll start creating 'normal' builds which will be faster.
-Rusty
Also, keep in mind that you're using debug builds which are slower by nature. Once we get to the RC stage, we'll start creating 'normal' builds which will be faster.
-Rusty
Re: [13xx] MM4 performance with large library sucks
Still no improvement here on my side at the moment im running mm3 for my music and mm4 portable just for my videos.
Would it be possible to have in future maybe 2 databases? One just for audio part and one for video? Is that too complicated? I am really trying my best to help the devs to solve the problem, running mm4 now with just a few files is fantastic but if i start to add my whole collection of music and movies it starts to slow down as hell
Would it be possible to have in future maybe 2 databases? One just for audio part and one for video? Is that too complicated? I am really trying my best to help the devs to solve the problem, running mm4 now with just a few files is fantastic but if i start to add my whole collection of music and movies it starts to slow down as hell