Print

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

[LeoH]

My Media Center server has developed a peculiar problem of exiting memory after about one hour of running. It only does this whenever 'Media Networking' is enabled.  It exhibits this behavior on two different servers in my home. Both machines are small form factor devices; one is running 2nd gen Intel i7 cpu and the other 3rd gen i7; both run Windows 7 with 16 GB of RAM. Also, both machines have OS on an SSD drive and the media library on an internal 4 TB drive.  The most recent Media Center version tried on both machines was MC 18.212 as well as MC 19.32, though I should note that the problem began about one month ago before MC18.212 and not coincident with any MC upgrade.  I have uninstalled and reinstalled Media Center as well as reset the access key, just to try anything.  Both servers work fine for about one hour then happiness ends. The problem also occurs even if I only run the app and not the server and vice versa.  I have run out of ideas, any suggestions would be appreciated. Thanks.

[Matt]

Please enable Help > Logging.  After a crash, send a log to logs (at) jriver dot com with a link to this thread.

Thanks.

[CountryBumkin]

I'm not sure what you mean by "exiting memory", but I found on my two client machines with small (60GB) OS drives that while watching a movie the OS drive would fill up with "temp files" and after 5 to 10 minutes would cause the movie to stutter and/or stop playing. As the small hard drive filled up, memory use would increase until it was at 100% then the movie stopped.
I moved the MC temporary file storage location to second (larger) drive on the same computer and have had no more issues. You can check for this by watching a movie with the Windows Resource monitor open (put a checkmark next to JRiver program to keep it on top/visible) and watch drive and memory resources.

[Matt]

I'm not sure what you mean by "exiting memory", but I found on my two client machines with small (60GB) OS drives that while watching a movie the OS drive would fill up with "temp files" and after 5 to 10 minutes would cause the movie to stutter and/or stop playing. As the small hard drive filled up, memory use would increase until it was at 100% then the movie stopped.
I moved the MC temporary file storage location to second (larger) drive on the same computer and have had no more issues. You can check for this by watching a movie with the Windows Resource monitor open (put a checkmark next to JRiver program to keep it on top/visible) and watch drive and memory resources.

If you play from a network resource, the file may be backed by disk so that seeking is possible.

This is normally a good thing, but I suppose it could be a problem if the file you're playing is bigger than the free space on your hard disk.  I'm not sure the best way to handle this.

[Matt]

LeoH, thanks for the log.

However, the previous log shows the program being shut down normally after 4 minutes.  The current log shows you running and opening the logging dialog.

Maybe you could try again to get a log showing the exit?

[LeoH]

Sorry, too many balls in the air, I will get a clean log and send it.  Meanwhile, this just in: MC18.212 on one of my test machines ran error-free for several days with 'Media Network' enable BUT port forwarding turned off on the router (using default port 52199, just for the record).  When port forwarding was turned back on, Media Center crashed after about one hour. Also, prior to testing with turning port forwarding off and on, I extended the test to a laptop and an ordinary PC workstation on the same home network; in both cases MC18 crashed like the others when 'Media Network' was enabled, and was stable when not enabled.  Seems the house is haunted (or the network).

[Matt]

The latest 'Previous Log.txt' you sent last shows the program running for 22 minutes and then being closed with a regular close button:
1302920: 2888: General: CMCShutdownHelper::Cleanup: Start
1302920: 2888: General: CMCShutdownHelper::Cleanup: Source: CMainFrame - Close(...)

Right after a crash, you should re-run the program and pick Help > Logging > Report a Problem.

Or is it possible something is closing programs, so it's not really crashing?

[LeoH]

My test steps were: (1) run Media Center, (2) reset the log file, (3) play some music for about 20 minutes, (4) let the program idle until it exits memory (Windows dialog appears stating "program generated unexpected error"), (5) restart Media Center, (6) select "Report Problem" from Help > Logging, (7) return the report.

Is there a better sequence of test steps? Thanks.

[Matt]

Thanks for the new log.  It captures a crash.  Unfortunately the 'Previous Crash.dmp' file is empty, but at least we have a log.

This is the tail, showing some DLNA connection on a background thread crashing after 9.3 hours of runtime:

Code: [Select]

33653362: 2564: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Start
33653362: 2564: Sharing Plugins: VHTTPMessage::ParseBody: Start
33653362: 2564: Sharing Plugins: VHTTPMessage::ParseBody: Reading 684 bytes from message body
33653362: 2564: Sharing Plugins: VHTTPMessage::ParseBody: Finish (0 ms)
33653362: 2564: Sharing Plugins: CHTTPListenerWorker::HandleRequest: TCP: 192.168.1.31: POST: http://192.168.1.36:52100/ContentDirectory/control
33653362: 2564: Sharing Plugins: CDLNADeviceServerWorker::ProcessPost: Start
33653362: 2564: Sharing Plugins: CContentDirectoryService::HandleControlFunction: Start
33653362: 2564: Database: CMediaFileIOLoad::Load: Loading: M:\MediaDB\JRiver MC19\RosettaMaster\Cache\File List Sort\Cache (3).dat
33653362: 2564: General: TopLevelExceptionFilter: Unhandled exception -- program crashing
33653362: 2564: General: TopLevelExceptionFilter: Message: 275, wParam: 6002, lParam: 0

So it looks like something is controlling the machine with DLNA and that brings it down.

Can you add any more to the story that might offer clues?

Thanks.

[Matt]

Thanks for your report and all the detective work.

Do any of the crash logs you've captured have a Previous Crash.dmp file in them that's not zero bytes?

If not, we'll have to add more logging and try to find the issue that way.

Thanks again.

[Matt]

Bump for the Previous Crash.dmp file size question above.

Also, I added more logging to the DLNA browse / search response code.  It will be in 19.0.39 or later (should be available in about a week).  I'd appreciate if you could get a crash log from it once the build is available.

Thanks.

[Matt]

Build 41 is out, so if you could grab another crash log / dump, I'd appreciate it.

Thanks.

[Matt]

The last log contains a good clue:
1988326: 20224: Sharing Plugins: VHTTPMessage::ParseBody: Finish (0 ms)
1988326: 20224: Sharing Plugins: CHTTPListenerWorker::HandleRequest: TCP: 192.168.1.35: POST: http://192.168.1.150:52100/ContentDirectory/control
1988326: 20224: Sharing Plugins: CDLNADeviceServerWorker::ProcessPost: Start
1988326: 20224: Sharing Plugins: CContentDirectoryService::HandleControlFunction: Start
1988326: 20224: Sharing Plugins: CContentDirectoryService::HandleControlFunction: Action: Browse
1988326: 20224: General: TopLevelExceptionFilter: Unhandled exception -- program crashing
1988326: 20224: General: TopLevelExceptionFilter: Message: 15, wParam: 0, lParam: 0

I'll add more logging to yet another build to get us closer yet.  Thanks a lot for all the help.

It's too bad the crash DMP file is always blank for some reason on your system.  If that were working, it'd point us right to the issue.

(p.s. please post text describing what you've learned here instead of in email so we have a clean record of it)

[LeoH]

Will do on posts to this thread.  To repeat from today's test:

New behavior, when my LG 32LN5700 Smart TV is plugged in and connected to my home network, Media Center continues to crash as before.  However, if I am playing music, the music freezes with what sounds like the last buffer repeatedly sent to the DAC which continues until I force the program to quit. The program used to just exit memory even if music was playing.

Current version is: 19.0.45.

[LeoH]

Now testing 19.0.49.  Using the "Interfaces to ignore: list of network/bits", I entered the local IP address for my bad boy LG smart TV (192.168.1.35) but what is the "/bits" for?

BTW, I have been running the Mac version 19.0.47 with the same library imported to the Mac. With "Use media network to share..." on, it seems to be immune to the LG TV. It is on the same network as the PC music server that has the problem and the TV. In other words, with both the PC and Mac running Media Center and the same library, the PC quits (after the usual hour) and the Mac doesn't. Interesting.

[Matt]

I've put more logging in 19.0.51, which should be out tomorrow morning.

If you would be willing, please grab a log and mail it our way.

Sorry this is taking a while.  I think we'll get it eventually if you're willing to stick with us.

Thanks.

[Matt]

Bump.

[Matt]

Thanks for the updated log.  For my records, here's the crash:
1371716: 30412: Sharing Plugins: CContentDirectoryService::HandleControlFunction: Start
1371716: 30412: Sharing Plugins: CContentDirectoryService::HandleControlFunction: Action: Browse
1371716: 30412: Sharing Plugins: CContentDirectoryService::Browse: Start
1371716: 30412: Sharing Plugins: CContentDirectoryService::Browse: Browse BrowseDirectChildren for 37821
1371732: 30412: Database: CMediaFileIOLoad::Load: Loading: M:\MediaDB\JRiver MC19\RosettaMaster\Cache\File List Sort\Cache (18).dat
1371732: 30412: General: TopLevelExceptionFilter: Unhandled exception -- program crashing
1371732: 30412: General: TopLevelExceptionFilter: Message: 15, wParam: 0, lParam: 0


The TV must periodically issue a browse request on some specific DLNA container (maybe the one it looked at last).  In this case, that crashes.  My guess is that the container it's trying to talk to is stale and/or deleted, since it seems like the crash happens after some amount of time.  Let me spend some time in the code and circle back in a few days.

Thanks again.

[Matt]

Looking at this some more, the TV made 639 browse requests on DLNA container 37821 in 12 minutes.  This is about once a second!

The first 638 worked, and the last one crashed.

[Matt]

I set up a test in the debugger to allow me to simulate thousands of DLNA browse calls coming in on background threads.

Unfortunately I never experienced a crash.  However, I was able to find several speed improvements to help our server handle this better.

It's possible the speed improvements will also fix the crash, but I'm not sure.  Testing appreciated once build 55 or newer is available.

I'm also thinking about if there are ways to handle borderline-denial-of-service behavior by DLNA devices, but I'm not sure what metrics to use that wouldn't lead to other problems.

[LeoH]

I have many DLNA devices on my home network between the TV, Sonos devices, a QNAP NAS, laptops and a few networked blu-ray players. Let me know if I can help with any particular configuration.

[LeoH]

Running MC 19.0.56 on three PCs all of the same Win7 config.  Two of three have continued to run for two days (to date) with the bad boy smart TV on. The first still crashes but now runs for many hours before freezing. Log file sent.

[Matt]

Another user experienced a similar crash on the Mac side.

I'm suspicious that the browse system for DLNA isn't as thread safe as it needs to be.  A coming build (probably available sometime after Thanksgiving weekend) will make some changes here, and I'm hopeful it'll solve the problem.

Thanks, and testing appreciated.