Print

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

[notzippy]

Hi

Im 'trial'ing a version 12.0.380 streaming video UPnP to a dsm-320 every once in a while the Media Center application hogs the processor (or starts one or two JRWorker threads which combined kill the processor) and audio will stop, 10-20 seconds then the video will stop and the audio plays the missing part. Occurs at least 5 times during a 40min show. Very annoying. Uncheked the auto re-encode audio function, used standard DSM-320 settings.
The file is 350MB
resolution: 624X352
BitRate:1068
Codec:XVid MPEG-4
audio: 2channel (48K) MP3

These shows stream without an issue using TVersity but I really like the all in one (Video/audio/image) enviorment of MC.

Any ideas on how to begin to trouble shoot this would be greatly appreciated, this is a show stopper for me if it cannot be resolved.

Thanks
z

[Matt]

JRWorker is used to analyze or thumbnail videos.  Both are one-time actions, but can be resource intensive depending on the filters used for decoding.

[notzippy]

Understandable but should they suddenly launch when the server is sitting in the tray ?
If so is there a way to force the generation of all thumb nails so that this occurs when I am not watching TV ?

I have 1358 Videos, 4839 images and 5622 mp3's in the database currently (Which is fantastic ! BTW)
Is there another reason why the Media Center might suddenly peek ? Is there some logging I can enable to check what it is doing ? I have anti-virus software installed but I told it to ignore Media Center and JRWorker.

z

[rjm]

Go to Tools\Options\Tree & View\Thumbnails and select "Build missing thumbnails".

When complete no additional thumbnails will be built until you add new media to your library.

The only CPU hogs that I am aware of in MC are:
- building thumbnails (especially heavy for video)
- analyzing audio
- ripping
- converting Format

I think we have dealt with the first one, and the last three only run if you manually start them.

[Matt]

Understandable but should they suddenly launch when the server is sitting in the tray ?
If so is there a way to force the generation of all thumb nails so that this occurs when I am not watching TV ?

I have 1358 Videos, 4839 images and 5622 mp3's in the database currently (Which is fantastic ! BTW)
Is there another reason why the Media Center might suddenly peek ? Is there some logging I can enable to check what it is doing ? I have anti-virus software installed but I told it to ignore Media Center and JRWorker.

z

You could build all thumbnails overnight.  Look in Options > Tree & View > Thumbnails...

Thumbnails are only built when you're in a view that's using them.

Otherwise, could auto-import be finding new videos being downloaded?

There is logging under Help > Logging, so that might help us figure it out as well.

Thanks.

[ RJM beat me to the punch, so sorry for the duplicate information ]

[notzippy]

So i tried all above, still noticing a delay. So i turned on the logging (and turned off antivirus software).
(One bit of info that I didnt mention is that the shows are on an external (USB 2.0) drive. not sure if this is critical or not...)
Here is a portion of a the log file, the issue definitely occurred somewhere in the log but it is rather large, this section may be relevant as the times seem rather long 3500 ms at one point, where most of the other times are less then 200ms...

Code: [Select]

0151047: 3208: Sharing Plugins: CHTTPListenerWorker::HandleRequest: Finish (156 ms)
0151047: 3208: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Finish (156 ms)
0151047: 5668: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Start
0151047: 5668: Sharing Plugins: CHTTPListenerWorker::HandleRequest: Start
0151047: 5668: Sharing Plugins: CHTTPRequestMessage::ReadPreamble: Start
0151047: 5668: Sharing Plugins: CHTTPRequestMessage::ReadPreamble: Finish (0 ms)
0151047: 5668: Reader: CHTTPRequestMessage::ReadPayload: Start
0151047: 5668: Reader: CHTTPRequestMessage::ReadPayload: Finish (0 ms)
0151047: 5668: Sharing Plugins: CHTTPListenerWorker::HandleRequest: Read succeeded
0151047: 5668: Reader: VHTTPMessage::Write (from reader): Start
0151047: 5668: Reader: CHTTPResponseMessage::WritePreamble: Start
0151047: 5668: Reader: CHTTPResponseMessage::WritePreamble: Wrote 189 of 189 bytes
0151047: 5668: Reader: CHTTPResponseMessage::WritePreamble: Finish (0 ms)
0151047: 5668: Reader: CLocalReader::OpenInternal: Opening: H:\movies\Christmas\XXXXXXXX.avi
0154547: 5668: Sharing Plugins: CTCPSocketReader::Write: Write failed: 10054 (socket: 720)
0154547: 5668: Reader: VHTTPMessage::Write (from reader): Finish (3500 ms)
0154547: 5668: Reader: CLocalReader::Close: Closing: H:\movies\Christmas\XXXXXXXX.avi
0154547: 5668: Reader: CLocalReader::Close: Closing: H:\movies\Christmas\XXXXXXXX.avi
0154547: 5668: Reader: CLocalReader::Close: Closing: H:\movies\Christmas\XXXXXXXX.avi
0154547: 5668: Sharing Plugins: CHTTPListenerWorker::HandleRequest: Finish (3500 ms)
0154547: 5668: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Finish (3500 ms)
0154547: 2660: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Start
0154547: 2660: Sharing Plugins: CHTTPListenerWorker::HandleRequest: Start
0154547: 2660: Sharing Plugins: CHTTPRequestMessage::ReadPreamble: Start
0154547: 2660: Sharing Plugins: CHTTPRequestMessage::ReadPreamble: Finish (0 ms)
0154547: 2660: Reader: CHTTPRequestMessage::ReadPayload: Start
0154547: 2660: Reader: CHTTPRequestMessage::ReadPayload: Finish (0 ms)
0154547: 2660: Sharing Plugins: CHTTPListenerWorker::HandleRequest: Read succeeded
0154547: 2660: Reader: VHTTPMessage::Write (from reader): Start
0154547: 2660: Reader: CHTTPResponseMessage::WritePreamble: Start
0154547: 2660: Reader: CHTTPResponseMessage::WritePreamble: Wrote 189 of 189 bytes
0154547: 2660: Reader: CHTTPResponseMessage::WritePreamble: Finish (0 ms)
0154547: 2660: Reader: CLocalReader::OpenInternal: Opening: H:\movies\Christmas\XXXXXXXX.avi
0154750: 2660: Sharing Plugins: CTCPSocketReader::Write: Write failed: 10054 (socket: 2064)
0154750: 2660: Reader: VHTTPMessage::Write (from reader): Finish (203 ms)
0154750: 2660: Reader: CLocalReader::Close: Closing: H:\movies\Christmas\XXXXXXXX.avi
0154750: 2660: Reader: CLocalReader::Close: Closing: H:\movies\Christmas\XXXXXXXX.avi
0154750: 2660: Reader: CLocalReader::Close: Closing: H:\movies\Christmas\XXXXXXXX.avi
0154750: 2660: Sharing Plugins: CHTTPListenerWorker::HandleRequest: Finish (203 ms)
0154750: 2660: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Finish (203 ms)


[rjm]

My guess is that it is something external to MC. Are you using Vista and do you have indexing turned on? Could be building the index if you don't plug the USB drive in very often.

[notzippy]

Nope I have Win XP (index off). Like I said to begin with MC is the only application that is running with sparatic CPU spikes..
USB drive is always on and plugged in with the PC.

[glynor]

Nope I have Win XP (index off). Like I said to begin with MC is the only application that is running with sparatic CPU spikes..
USB drive is always on and plugged in with the PC.

I've definitely seen similar results on some of my single-core machines, when building thumbnails for XviD and x264 videos particularly.  I know it has something to do with how MC calls the DirectShow filters to generate the thumbnail.

I can say that keeping the thumbnails well-built manually helps a lot.  Also, a dual-core machine (with plenty of RAM) makes the problem completely irrelevant because MC is so well multi-threaded.  With a dual-core machine, even though the CPU usage is still high on a single core (FFDSHOW's fault), MC's UI still feels snappy and responsive.

Though... As I've said again and again in these threads (which seem to pop up every so often).  Some method to completely disable the on-the-fly thumbnailing, with an accompanying automation command to initiate the manual build, would completely solve this problem.  Then you could just schedule the builds for 2am every Tuesday and be done with it.

[Alex B]

I would like to be able to disable the thumbnailing process on my laptop after I have used the new "copy" feature for taking some of my media files with me.

A simple on/off switch would make using the new files much smoother, especially when the laptop is running on battery power.

[notzippy]

Hi

Thanks for all the suggestions but unfortunately nothing has helped. The UPNP server still stalls on occasion. (With media center taking up to 100 % of the CPU for a period of 20-30 seconds) then everything returns to normal. I have even tried boosting the media center's process to "Real time" with no effect. My suggestion would be to have an entirely different process serving out the UPNP data. (I attempted to do this by sharing the MC library with another computer and having that computer act as the UPNP host, unfortunately even though the navigation worked properly the server did not stream the video files ). Is it possible to do this ?

thanks
z

[John Gateley]

What happens if you play the entire file on the MC computer (take the UPnP server out of the picture), does it still happen?

j

[statious]

I also have a DMS-320 and I will be the first to say that I love MC12 but honestly tversity is a much better option for serving video via UPNP. I know that MC12 is an amazing program but the transcoding options available within tversity simply make it a better option for playing back video via UPNP. I am able to playback every media file without issue on tversity but MC12 does not like the majority of video files. However, interestingly audio is played back much smoother and with a bit better sound via MC12.

Like TV this is one area that MC12 lacks a bit but as has been said there have been remarkable improvements to the program. I am certain we will see an update to the UPNP mode in the feature.

[notzippy]

Hi

John: I let the show run for 15 min's on the PC and did not experience the CPU spike. nor any pause in the video. Would it help if I you knew which thread (from media center) was consuming the cpu ? I have process explorer which I could try and use to capture it..

statious : TVersity was good but my machine is not speedy enough to transcode the video fast enough to feed the DSM (p4 3G) Anything that doesnt run I use mencoder against first.

z

[John Gateley]

Okay, you say 5 times in 40 minutes, would you check that it happens every 8 minutes (more or less, and let me know how long until the first pause happens).

Thanks,

j

[notzippy]

ok

Started 7:33 First hi was at 7:46, second at 7:48, 7:52
I dont know upnp protocol but I found this odd: Looking at the TCP/IP tab for the mediacenter process the remote port that the server connected to was always incrementing. The servers (media center) local address localhost:41952 The remote (DSM320) 192.168.0.102:1017 then it would change to 192.168.0.102:1022 then 192.168.0.102:1028 and 192.168.0.102:1033 so on 192.168.0.102:1038 ... Like every request from the dsm was sent back on a different port (Eventually it flipped back to 1000, im not sure at what point but it was over 8000 and maybe less then 10000). Also im pretty sure the increments would be sequential but the process explorer application only updates the screen once a second..

TVersity on the other hand establishes only 2 connections on ports 3303 and 3302 and sticks with those for the entire episode.

It also seems like when the process runs away these request increment faster..

Hope that helps.
z

[notzippy]

MC 12.404 Also has the problem (with the ever increasing port address connection). Oddly enough this does not occur when streaming mp3's only for video...

z