INTERACT FORUM
More => Old Versions => Media Center 11 (Development Ended) => Topic started by: JustinChase on April 01, 2004, 10:09:46 am
-
Whenever I scroll through a list of music, it takes quite a while to scroll 1 page (7 seconds to display 41 songs) If I go back up it's (nearly) instant, so it must be cached, but why so long on the first viewing? Thumbnails don't take that long to display ?
Yeah, I have a largeish library (7200 songs, and 30,000 pics), but not that big.
If I scan a list of things in Excel or Access, it's nearly an instant refresh as I page down. But MC takes forever by comparison.
I'm guessing it has something to do with the fact the the name is linked to a file located elsewhere, but there must be some way disassociate that link for the sake of viewing names. It just seems way too slow for what is being done. And I have a fast machine.
Any ideas?
-
We check to make sure that files exist the first time you look at them so the little red-x thing can work.
If your files are on a slow drive or network this may cause a little lag.
-
Network.
Any way to make this 'double-check' optional. I'd rather just show the files fast, and worry about whether they really exist or not later.
Anyone else?
Thanks for the quick response Matt!
-
The reason 'JustinChase' is slow, is because he is a running a 386-40 machine with 64k of memory. We just know he wants to get his money worth out of this computer.
-
The reason 'JustinChase' is slow, is because he is a running a 386-40 machine with 64k of memory. We just know he wants to get his money worth out of this computer.
Media Center Registered 10.0.103 -- C:\Program Files\J River\Media Center\
Microsoft Windows XP Workstation 5.1 Service Pack 1 (Build 2600)
Intel Pentium 4 2771 MHz MMX / Memory: Total - 523 MB, Free - 151 MB
Internet Explorer: 6.0.2800.1106 / ComCtl32.dll: 5.82 (xpsp1.020828-1920) / Shlwapi.dll: 6.00.2800.1400 / Shell32.dll: 6.00.2800.1233 (xpsp2.030604-1804) / wnaspi32.dll: 4.60 (1021) , ASPI for Win32 (95/NT) DLL, Copyright © 1989-1999 Adaptec, Inc. / Aspi32.sys: 4.60 (1021)
Ripping / Drive D: TOSHIBA DVD-ROM SD-R6112 Mode:ModeSecure Type:Auto Speed:Max
Digital playback: Yes / Use YADB: Yes / Get cover art: Yes / Calc replay gain: Yes / Copy volume: 32767
Eject after ripping: Yes / Play sound after ripping: No
Burning / Drive D: TOSHIBA DVD-ROM SD-R6112 Addr: 1:0:0 Speed:16 MaxSpeed:16 BurnProof:Yes
Test mode: No / Eject after writing: Yes / Direct decoding: Yes / Write CD-Text: Yes
Use playback settings: Yes / Normalization: None
-
Next build will check on a delay, so scrolling should be better.
Let us know.
-
Sweet,
[wrings hands together]
I can't wait..
-
It's better, but wierd.
Now it will show the page almost instantly, but theres still a few second lag from when I hit the page down before the page loads (quickly). I'm not sure where you built the lag, but maybe a longer lag would scroll faster/better.
It certainly looks like you're on the right path.
Thanks for this, a little better would be great, but if it's a pain, I can wait.
You guys rock!
-
Matt, the delay you guys implemented a week or so ago makes the first one or 2 page down screens display quite quickly, but after that, it still takes about 5 seconds to display the next page down. It used to take 7 seconds, so it's definately better, and thanks for that.
But (there's always a but), is there any way to either increase this delay you introduced, or perhaps, make scrolling have priority over checking against the database, no matter what. If I shift-click to the middle of the list, that view comes up pretty quick, but the next click is slow. If you could allow the display to draw without checking the database, we could scroll as fast as we want, and when we stop, the database checking can begin, until we try to scroll again, then checking will pause, until we stop scrolling.
Or maybe, the database checking can always be done in the background, i.e. it will check the entire list, whether or not it's visible, so when we go to scroll it's already been verified, again, it would need to stop checking if we scrolled before the check was finished, but once it's done, it's done.
Again, I have no programming experience, so maybe this is all hogwash (haven't heard/used that work in quite some time), but the fact that you were able to add this delay so quickly in the first place gives me hope that another little tweak will solve all my scrolling issues.
As a reminder, my entire database 7500 songs, 30,000 images are all stored on a LINUX server mapped in Windows.
Thanks
-
Matt, any idea if something more can be done with this, or 'not at this time' ?
Thanks