Print

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

[TreeFrog77]

I've searched a bit, but haven't found a clear answer/help to this issue.

When I change a view on a client (say, select a different artist) and the client requests cover art from the server, the CPU usage on the server for "Media Center 12.exe" goes to 100% and just hangs for about 5 seconds.  While this is occurring, if I select a song to play on the client, it just hangs on waiting but does eventually play.  Meanwhile, the server will stay at 100% until all cover art for the particular view on the client has been served.

Watching the log on the server, I can see the requests for the cover art, but it just seems like the server is just heavily trying to do something during that time until it finally moves to the next request (seems like around five to ten seconds).

With 12.0.198 (I think that is what I moved from), I had no problems with using the library server and speed (and subsequent previous versions of 12 I have used).  I even have tried rebuilding thumbnails (or whatever that option is in this current version), but that didn't help.

Anyone else experiencing this?

[JimH]

Strange.

In MC Help, you can set up logging.  You could e-mail a log with a link to this thread to gateley at jriver.

[TreeFrog77]

Strange.

In MC Help, you can set up logging.  You could e-mail a log with a link to this thread to gateley at jriver.

Just did exactly that.

Just for everyone else, here is an example of what I'm seeing in the log:

Code: [Select]

0153781: 2108: Sharing Plugins: CLibraryServerHTTPWorker::StatusMessage: Received request for cover art: G:\Cyberdude's Documents\My Music\MP3s\Diana Krall - Gee Baby, Ain't I Good to you.mp3: Finish (25516 ms)
0153781: 2228: Reader: CHTTPResponseMessage::WritePreamble: Start
0153781: 2228: Reader: CHTTPResponseMessage::WritePreamble: Finish (0 ms)
0153781: 2188: Sharing Plugins: CLibraryServerHTTPWorker::StatusMessage: Received request for cover art: G:\Cyberdude's Documents\My Music\MP3s\Diana Krall - It Was a Beautiful Day in Augustyou Can Depend on Me.mp3: Start
0153781: 1744: Sharing Plugins: CLibraryServerHTTPWorker::StatusMessage: Received request for cover art: G:\Cyberdude's Documents\My Music\MP3s\Diana Krall - It Could Happen to you.mp3: Start
0153812: 2228: Reader: CLocalReader::Close: Start
0153812: 2228: Reader: CLocalReader::Close: Closing: F:\Documents and Settings\Aria\Local Settings\Temp\JRTemp\Thumbnails\493.dat
0153812: 2228: Reader: CLocalReader::Close: Finish (0 ms)
0153844: 2228: Sharing Plugins: CHTTPListenerWorker::HandleRequest: Finish (105016 ms)
0153844: 2228: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Finish (105016 ms)
0153719: 1636: Reader: CLocalReader::Close: Start
0153875: 1636: Reader: CLocalReader::Close: Closing: F:\Documents and Settings\Aria\Local Settings\Temp\JRTemp\Thumbnails\500.dat
0153890: 804: Sharing Plugins: CHTTPListenerWorker::HandleRequest: Start
0153890: 804: Sharing Plugins: CHTTPRequestMessage::ReadPreamble: Start
0158734: 2088: Reader: VHTTPMessage::Write: Start
0153875: 1636: Reader: CLocalReader::Close: Finish (156 ms)
0158765: 1636: Sharing Plugins: CHTTPListenerWorker::HandleRequest: Finish (59062 ms)
0158765: 1636: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Finish (59062 ms)
0153890: 804: Sharing Plugins: CHTTPRequestMessage::ReadPreamble: Failed to read rest of first line
0158781: 804: Sharing Plugins: CHTTPRequestMessage::ReadPreamble: Finish (4891 ms)
0158781: 804: Sharing Plugins: CHTTPListenerWorker::HandleRequest: Finish (4891 ms)
0158734: 2088: Sharing Plugins: CHTTPRequestMessage::WritePreamble: Start
0163687: 2088: Sharing Plugins: CHTTPRequestMessage::WritePreamble: Finish (4953 ms)
0163687: 2088: Reader: VHTTPMessage::Write: Wrote 0 of 0 bytes
0163687: 2088: Reader: VHTTPMessage::Write: Finish (4953 ms)
0163719: 2108: Reader: CLocalReader::OpenInternal: Start
0163719: 2108: Reader: CLocalReader::OpenInternal: Create: 0
0163719: 2108: Reader: CLocalReader::OpenInternal: Opening: F:\Documents and Settings\Aria\Local Settings\Temp\JRTemp\Thumbnails\505.dat
0163719: 2108: Reader: CLocalReader::OpenInternal: Finish (0 ms)
I'm really not that familiar with reading this, but you can see that one of those times was over 100,000 ms.... all the while MC is doing whatever it is doing during this period, the client just waits and waits and the server is at 100% CPU and non-responsive.

[hsc]

Hi,

I have the same problem with 12.0.222 (see http://yabb.jriver.com/interact/index.php?topic=40455.0),

Regards,
Horst

[TreeFrog77]

Hi,

I have the same problem with 12.0.222 (see http://yabb.jriver.com/interact/index.php?topic=40455.0),

Regards,
Horst

Dang... I always try to be a good forum citizen and I must not have noticed that post.  My apologies to the forum for the dupe post (albeit I guess just confirming problem still exists in 12.0.226).

[John Gateley]

Could y'all try rebuilding all thumbnails (Tools->Options->Tree and View settings) to see if that improves the situation?

j

[TreeFrog77]

Could y'all try rebuilding all thumbnails (Tools->Options->Tree and View settings) to see if that improves the situation?

j

Just tried that.  Went to "Tools > Options > Tree and View Settings", then "Erase All Thumbnails", then "Build Missing Thumbnails".

Took about 20 minutes and stepped through every file in the library.  Once finished, browsed the server a bit, everything working fine there.  Started a client, connected fine, started the browsing/playing test and exact same behavior as before... CPU 100% / hung (albeit music does eventually play, if the client doesn't decide to timeout on the selected song and try another in the current view).

EDIT/NOTE: Just want to be clear that once the server has fulfilled the cover art requests for the current view on the client, behavior returns to normal.  So, say, if I select an artist with 20 tracks in view, it will (very slowly) spit out one piece of cover art at a time for all 20 and once the client has them all (or already had them/didn't request any more), you are free to change tracks at will, so long as you don't change views (and, thus, initiate another request to the server for more cover art).  Response from server is immediate and as expected at that point.

[John Gateley]

How powerful is your machine? Do you have conversion on the fly enabled?

j

[TreeFrog77]

It's only a Sempron, running Win 2000, but only with essential services (it doesn't even have a monitor attached... just a file server and running my home automation software).  I built this machine specifically for this purpose.  Media Center and Homeseer are the only two services that machine provides.  It has been running Windows Media Player for the library (along with Homeseer) for years before MC ever came into the picture.  I keep Win 2000 on this machine for no other reason that I like to keep that machine as lean and mean as possible.  It has been rock solid for the few years since I've built it.

I'm also not really sure how that would make a difference in this case, considering it's been running MC without problems for six months (including 11 before 12) -- this version is what caused this issue (and I can't see why servicing a small JPG over HTTP would take 10-30 seconds, even on an old Pentium III).  I literally had been listening to music, decided to move from .198 to .226... updated both the server and clients and bam... the problem started.

Being a programmer myself, I almost think there has to be some form of an endless loop or leaky process somewhere in the code that would be new and involving cover art.  It also could be very possible that this delay is just not as "noticeable" on a faster machine.

No conversion is enabled.  As I said, once it gets the covert art, it flips between tracks on the client immediately (even with MC's nice fade between).  In addition, the server itself is always is responsive (even with my home automation software is communicating with it) UNLESS it is serving covert art through the library server.  I have various keypads around the house that can select playlists, change tracks, etc through Homeseer and MC performs the task immediately (again, so long as I don't have a client somewhere requesting cover art).

MC has to best one of the best pieces of software I have ever bought, and, thus the reason it's so important I need it working it's best.  Just wanted to back up the fact that even though I'm having a few little bumps, this software rocks my world! ... literally, I suppose ;-)

[John Gateley]

Being a programmer myself, I almost think there has to be some form of an endless loop or leaky process somewhere in the code that would be new and involving cover art.  It also could be very possible that this delay is just not as "noticeable" on a faster machine.

How long does it take to do a typical thumbnail from cover art? Does 3 seconds sound about right?

j

[TreeFrog77]

How long does it take to do a typical thumbnail from cover art? Does 3 seconds sound about right?

j

It's somewhat unpredictable.  I just selected a new artist and watch the library server logs and once it took over 30 seconds for the next log line to appear and other times, only a few seconds (or even spit out a few at a time).

I also notice that it seems to develop a "backlog" of requests.  For instance, I can quickly switch from Artist A, to Artist B, to Artist C on the client and even many minutes later it is still throwing in a request for cover art from Artist A even though there have already been log entries for requests for covert art for Artist B and C (like the server just finally got around to letting that request in and/or finally serving the art, even though the client changed views a long time ago).

In the time I've taken to type this, it is still serving cover art for Artist C, trying to catch up to where the client currently is viewing.

[John Gateley]

It sounds like it's rebuilding the thumbnails for cover art, even though it doesn't need to. I'll take a closer look and let you know...

j

[John Gateley]

I fixed something that may help this (though it may not). Check your e-mail...

j

[TreeFrog77]

It would appear that this issue is now resolved.

I tried 12.0.234 and thumbnails populated very fast (almost faster than I could scroll to keep up).  I did experience the mapping problem (m01p://), but just noticed 12.0.237 fixed that.  Installed that version and everything seems great.

Only been trying it for a few minutes now, so if I notice the problem pop up again, I'll post something new.

Thanks for your hard work.