INTERACT FORUM
More => Old Versions => JRiver Media Center 24 for Windows => Topic started by: jmone on December 10, 2017, 12:07:19 am
-
100% reproducible. On my Android 7.0 Phone when I take a photo and go to share it (to upload to NextCloud), MC Crashes. Looking at the log (attached), you see a heap of activity from 192.168.1.67 which is my phone. This happens with prior versions as well but I'm on V90 at present. I'm not doing anything with MC at the time.
-
That's interesting!
-
I know - I feel like a hacker able bringing down systems with the power of my phone 8) ... except it is my system :-\
-
I'm thinking it is DLNA related both from the Log and also when you bring up sharing in the Phone I see MC's DLNA zones. Anyway, it's not as if Bob has anything better to do!
-
Did you try turning off Media Network?
-
Not yet. I'm not sure that if turning off and on again will re-issue the key. I'll hold fire till Bob has had a look at the logs. From what I can see my phone gives MC a bunch of traffic then at the end of the Log you see a bunch stuff stopping:
061922: 12640: Sharing Plugins: CHTTPListenerWorker::HandleRequest: TCP: 192.168.1.67: POST: http://192.168.1.10:52100/ContentDirectory/control
0061922: 12640: Sharing Plugins: CDLNADeviceServerWorker::ProcessPost: Start
0061922: 20224: Sharing Plugins: VHTTPMessage::Write: Wrote 0 bytes
0061922: 21496: Sharing Plugins: JRWebService::Process: Start
0061922: 21496: Sharing Plugins: JRWebService::Process: URL: /MCWS/v1/Library/GetRevision
0061922: 12640: Sharing Plugins: CContentDirectoryService::HandleControlFunction: Start
0061922: 21496: Sharing Plugins: JRWebService::Process: Finish (0 ms)
0061922: 12640: Sharing Plugins: CContentDirectoryService::HandleControlFunction: Action: Search
0061922: 12640: Sharing Plugins: CContentDirectoryService::Search: Start
0061922: 12640: Sharing Plugins: CContentDirectoryService::Search: Search: upnp:class derivedfrom "object.item.imageItem"
0061922: 12640: Sharing Plugins: CContentDirectoryService::Search: 1
0061922: 12640: Sharing Plugins: CContentDirectoryService::Search: 2
0061922: 12640: Sharing Plugins: CContentDirectoryService::Search: 3a
0061922: 12640: Sharing Plugins: CMCViewInfoTree::GetSearchFilesItem: Start
0061922: 12640: Sharing Plugins: CMCViewInfoTree::GetSearchFilesItem: Hash: 8690193089776076918
0061922: 21496: Sharing Plugins: VHTTPMessage::Write: Wrote 200 bytes
0061922: 12640: Sharing Plugins: CMCViewInfoTree::GetSearchFilesItem: Finish (0 ms)
0061922: 12640: Sharing Plugins: CContentDirectoryService::Search: 3d
0061922: 12640: Sharing Plugins: CContentDirectoryService::Search: 4
0061672: 16552: General: JRWebApp::Destroy: Start
0061672: 16552: General: JRWebApp::Destroy: Finish (0 ms)
0061672: 16552: General: JRWebApp::Run: Finish (61641 ms)
0061672: 16552: General: JRWebApp::ExitInstance: Start
0061672: 16552: General: JRWebApp::ExitInstance: Stopping web engine
0061547: 19316: General: JRWebApp::Destroy: Start
0061547: 19316: General: JRWebApp::Destroy: Finish (0 ms)
0061547: 19316: General: JRWebApp::Run: Finish (61532 ms)
0061547: 19316: General: JRWebApp::ExitInstance: Start
0061547: 19316: General: JRWebApp::ExitInstance: Stopping web engine
0061703: 16552: General: JRWebApp::ExitInstance: Stopping callback server
0061703: 16552: General: JRWebApp::ExitInstance: Stopping interface server
0061703: 16552: General: JRIpcServerThreaded::ServerStop: Start
0061703: 16552: General: JRIpcServerThreaded::ServerStop: Canceling thread
0061703: 16552: General: JRIpcServerThreaded::ServerStop: Canceling pending run
0061703: 16552: General: JRIpcServerThreaded::ServerStop: Stopping thread
0061703: 7976: General: JRIpcServerThreaded::Thread: Thread finishing (cancel: 1; errors: 1)
0061703: 7976: General: JRIpcServerThreaded::Thread: Finish (61688 ms)
0061593: 19316: General: JRWebApp::ExitInstance: Stopping callback server
0061593: 19316: General: JRWebApp::ExitInstance: Stopping interface server
0061593: 19316: General: JRIpcServerThreaded::ServerStop: Start
0061593: 19316: General: JRIpcServerThreaded::ServerStop: Canceling thread
0061593: 19316: General: JRIpcServerThreaded::ServerStop: Canceling pending run
0061593: 19316: General: JRIpcServerThreaded::ServerStop: Stopping thread
0061593: 8904: General: JRIpcServerThreaded::Thread: Thread finishing (cancel: 1; errors: 1)
0061593: 8904: General: JRIpcServerThreaded::Thread: Finish (61578 ms)
0061734: 16552: General: JRIpcServerThreaded::ServerStop: Canceling response threads
0061734: 16552: General: JRIpcServerThreaded::ServerStop: Deleting response threads
0061734: 16552: General: JRIpcServerThreaded::ServerStop: Closing notification window
0061734: 16552: General: JRIpcServerThreaded::ServerStop: Finish (31 ms)
0061734: 16552: General: JRWebApp::ExitInstance: Finishing
0061609: 19316: General: JRIpcServerThreaded::ServerStop: Canceling response threads
0061609: 19316: General: JRIpcServerThreaded::ServerStop: Deleting response threads
0061609: 19316: General: JRIpcServerThreaded::ServerStop: Closing notification window
0061609: 19316: General: JRIpcServerThreaded::ServerStop: Finish (16 ms)
0061609: 19316: General: JRWebApp::ExitInstance: Finishing
-
The MC server supports the UPNP ContentDirectory Service.
CDS comprises four required actions (methods) GetSortCapabilities, GetSearchCapabilities, GetSystemUpdateId, and Browse. MC supports all those required methods. It also supports one of the CDS optional methods (Search).
The CDS:Search method is notorious for allowing very sophisticated search filters (things like Search for A, or B, and C, and not D, ..) and most servers only support a rudimentary subset of the syntax.
CDS also defines other optional methods CreateObject, DestroyObject, UpdateObject, ImportResource, ExportResource, DeleteResource, CreateReference and a couple more. The purpose of these being to allow external control points to add or modify media in the server’s media library. These methods are seldom used as most servers tend to supply their media libraries in read only format only.
So I am guessing that your crash is due to one or other of the following..
1. The phone is calling CDS:Search with an unexpected syntax (unlikely to cause a crash), or
2. The phone is trying to add its picture to MCs library via one of the CDS:CreateXX, ImportXX, or UpdateXX methods. This seems more likely, as MC probably has an entry point that accepts incoming CDS calls which probably dispatches the supported methods properly, but results in an unhandled exception for method names that it does not support..
-
Can you give me a step by step to try to reproduce it?
It's easier to catch it in the act in the debugger that way...
I've got a fire android table with a pretty recent OS I could use...
-
On the Android 7.0 Phone go to the pictures (Gallery):
1) Press the Share Button it will bring up a list of items you can share to (and you see MC Zones)
2) Don't do anything
3) MC will crash
-
On the Andriod 7.0 Phone go to the pictures (Gallery):
1) Press the Share Button it will bring up a list of items you can share to (and you see MC Zones)
2) Don't do anything
3) MC will crash
how do you get it to share to MC? I don't see this. Do you have some (not stock) app installed doing this?
-
I don't even try to share with MC. I just press the share button on the photo on my Phone and it brings up a screen as attached. Leave it for a few seconds and MC will crash.
-
The Picture App is Gallery 5.30.32 - Not sure if the sharing button takes you to another app or Andriod Resouces however. It is only when in the Sharing Screen that MC Crashes
-
Fwiw I have never seen such targets for a share intent on any of my android (all Nexus or pixel) devices so I would guess that is contributed by some app (or your MC is configured differently perhaps?)
-
I don't even try to share with MC. I just press the share button on the photo on my Phone and it brings up a screen as attached. Leave it for a few seconds and MC will crash.
Your screenshot shows four icons called DLNA Generic, High Quality, Normal, and Search. These are obviously a DLNA “mirror” into the MC server UPNP AVT and CDS interfaces. Can you please tell us what App on the phone is behind those icons? I assume it must be a DLNA app that you purchased and downloaded from the App Store; I am pretty sure that it is not a native Android built in app.
-
I think it is just the Stock LG Gallery App that was loaded on my phone (LG V20 only a couple of months old). I "think" it is this app - https://android-gallery3d.en.aptoide.com/?store_name=tamubcs
-
I can't install that app on my phone, it fails with "corrupt" every time. I tried the latest version, the version you mentioned, and several others but none will install. I've got a Moto G5 Plus with Android 7. Bob has the same problem on an Android Fire tablet.
I've never seen DLNA zones when sharing from my phone. Did you double check that you don't have some other third party DLNA app on your phone that is making these zones visible as sharing targets? Or maybe LG has some special extended sharing capability built in that you could try disabling - just to narrow down the cause.
-
A google search showed that some LG phones have a screen in settings called "Share & connect" which has a 'Media Server' option: "Share media content with nearby DLNA-compatible devices".
Maybe try disabling that to see if it's the cause.
http://www.lg.com/uk/support/solutions/tv/smartshare-screen-share (http://www.lg.com/uk/support/solutions/tv/smartshare-screen-share)
-
I have those settings but they are all off.
-
I suppose a packet capture would help as then you'd see the traffic hitting MC
-
I suppose a packet capture would help as then you'd see the traffic hitting MC
Yeah. Look for HTTP SOAP action commands..
-
We found one issue that's not directly related to the search but it might be a side effect of it being triggered.
I'm going to make a new beta in a bit. It would be nice to see if that fixes the issue.
-
Will test and let you know, thanks.
-
Will test and let you know, thanks.
It's up..
-
Still crashing :(
-
To make it more confusing, just tested with MC on a Laptop and it does not crash, only MC on the MAIN-PC
-
I just also discovered by accident that I have the ability to "share photos" to MC in my gallery app on a samsung galaxy note 8. The gallery app in my case is the stock samsung gallery app, and I ahve no other DLNA type apps. So this isn't just an LG feature/issue.
When I tried it, it did not trigger any MC crashes, but it doesn't "work" either (it wasn't clear what is supposed to happen in this case). It would be neat to be able to share things with MC via the phone's sharing api (i.e. videos, etc.), but it sounds like this android feature may still be early on.
-
To make it more confusing, just tested with MC on a Laptop and it does not crash, only MC on the MAIN-PC
Both 64 bit?
-
Yup - Same Version as well. The laptop was what I used to get the captures for the Axiom issue, so I was getting it ready again (in case you wanted captures)
-
Yup - Same Version as well. The laptop was what I used to get the captures for the Axiom issue, so I was getting it ready again (in case you wanted captures)
Big speed difference?
-
I guess so - this is the MainPC
=== Running Benchmarks (please do not interrupt) ===
Running 'Math' benchmark...
Single-threaded integer math... 3.193 seconds
Single-threaded floating point math... 2.204 seconds
Multi-threaded integer math... 0.595 seconds
Multi-threaded mixed math... 0.428 seconds
Score: 2960
Running 'Image' benchmark...
Image creation / destruction... 0.140 seconds
Flood filling... 0.161 seconds
Direct copying... 0.274 seconds
Small renders... 0.747 seconds
Bilinear rendering... 0.583 seconds
Bicubic rendering... 0.344 seconds
Score: 9783
Running 'Database' benchmark...
Create database... 0.108 seconds
Populate database... 0.613 seconds
Save database... 0.126 seconds
Reload database... 0.079 seconds
Search database... 0.826 seconds
Sort database... 0.818 seconds
Group database... 0.568 seconds
Score: 6851
JRMark (version 23.0.91 x64): 6531
-
and this is the Laptop
=== Running Benchmarks (please do not interrupt) ===
Running 'Math' benchmark...
Single-threaded integer math... 5.328 seconds
Single-threaded floating point math... 3.676 seconds
Multi-threaded integer math... 3.015 seconds
Multi-threaded mixed math... 2.018 seconds
Score: 1354
Running 'Image' benchmark...
Image creation / destruction... 0.238 seconds
Flood filling... 0.311 seconds
Direct copying... 0.487 seconds
Small renders... 1.335 seconds
Bilinear rendering... 1.608 seconds
Bicubic rendering... 0.967 seconds
Score: 4448
Running 'Database' benchmark...
Create database... 0.204 seconds
Populate database... 1.035 seconds
Save database... 0.192 seconds
Reload database... 0.069 seconds
Search database... 1.512 seconds
Sort database... 1.115 seconds
Group database... 0.682 seconds
Score: 4471
JRMark (version 23.0.91 x64): 3424
-
and this is the Laptop
=== Running Benchmarks (please do not interrupt) ===
Running 'Math' benchmark...
Single-threaded integer math... 5.328 seconds
Single-threaded floating point math... 3.676 seconds
Multi-threaded integer math... 3.015 seconds
Multi-threaded mixed math... 2.018 seconds
Score: 1354
Running 'Image' benchmark...
Image creation / destruction... 0.238 seconds
Flood filling... 0.311 seconds
Direct copying... 0.487 seconds
Small renders... 1.335 seconds
Bilinear rendering... 1.608 seconds
Bicubic rendering... 0.967 seconds
Score: 4448
Running 'Database' benchmark...
Create database... 0.204 seconds
Populate database... 1.035 seconds
Save database... 0.192 seconds
Reload database... 0.069 seconds
Search database... 1.512 seconds
Sort database... 1.115 seconds
Group database... 0.682 seconds
Score: 4471
JRMark (version 23.0.91 x64): 3424
I wouldn't expect that to make a difference.
-
The only thing I can think of that that MC on MAIN is trying to enumerate something that the LG V20 is after and coming unstuck. If it is not obvious then don't waste any more time on it. While it's not good that something can crash MC, if I'm the only one then who cares (...well apart from me).
-
Network hardware or driver problem on the one that crashes?
-
Doubtful as it looks like the phone polls MC DLNA servers and then MC just then falls over ....but who knows
-
LG G6, Gallery 6.1.29
Not crashing here, but as others have noted it doesn't work either.
Crashing on only one machine suggests to me that it's something to do with the zone configuration. Anything unusual there?
-
Somebody needs to do a WireShark capture please.
-
I'll do a capture...
-
Here is the capture. I'm not sure if it contains sensitive info so I've password protected it and sent a PM to AndrewFG, bob, and JohnT
-
Thanks for the capture. It looks as though it is indeed a CDS:Search problem in MC. At least I can see no other SOAP actions that might cause problems. Many of the CDS:Search requests are answered properly by MC by providing an HTTP 200 OK response with a respective resource payload. However towards the end of the log there seem to be requests where MC does not respond (or even responds with garbage). I cannot say why MC would crash on such requests. The JRiver guys will need to run the requests through their debugger..
Example of last CDS:Search in the log..
POST /ContentDirectory/control HTTP/1.1
Connection: Keep-Alive
HOST: 192.168.1.10:52101
User-Agent: LGMOBILE/7.0 UPnP/1.0 DLNADOC/1.50 (MS-DeviceCaps/1024) LGUPnP/2.1.022
Content-Type: text/xml; charset="utf-8"
Content-Length: 692
SOAPACTION: "urn:schemas-upnp-org:service:ContentDirectory:1#Search"
DLNADeviceName.lge.com: V20
<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:Search xmlns:u="urn:schemas-upnp-org:service:ContentDirectory:1">
<ContainerID>0</ContainerID>
<SearchCriteria>upnp:class derivedfrom "object.item.imageItem"</SearchCriteria>
<Filter>@id,@parentID,@restricted,@refID,dc:title,upnp:class,upnp:artist,dc:date,upnp:albumArtURI,upnp:albumArtURI@dlna:profileID,dc:description,res,res@size,res@resolution,res@importUri</Filter>
<StartingIndex>50</StartingIndex>
<RequestedCount>50</RequestedCount>
<SortCriteria/>
</u:Search>
</s:Body>
</s:Envelope>
-
Thanks for the capture. It looks as though it is indeed a CDS:Search problem in MC. At least I can see no other SOAP actions that might cause problems. Many of the CDS:Search requests are answered properly by MC by providing an HTTP 200 OK response with a respective resource payload. However towards the end of the log there seem to be requests where MC does not respond (or even responds with garbage). I cannot say why MC would crash on such requests. The JRiver guys will need to run the requests through their debugger..
Example of last CDS:Search in the log..
POST /ContentDirectory/control HTTP/1.1
Connection: Keep-Alive
HOST: 192.168.1.10:52101
User-Agent: LGMOBILE/7.0 UPnP/1.0 DLNADOC/1.50 (MS-DeviceCaps/1024) LGUPnP/2.1.022
Content-Type: text/xml; charset="utf-8"
Content-Length: 692
SOAPACTION: "urn:schemas-upnp-org:service:ContentDirectory:1#Search"
DLNADeviceName.lge.com: V20
<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:Search xmlns:u="urn:schemas-upnp-org:service:ContentDirectory:1">
<ContainerID>0</ContainerID>
<SearchCriteria>upnp:class derivedfrom "object.item.imageItem"</SearchCriteria>
<Filter>@id,@parentID,@restricted,@refID,dc:title,upnp:class,upnp:artist,dc:date,upnp:albumArtURI,upnp:albumArtURI@dlna:profileID,dc:description,res,res@size,res@resolution,res@importUri</Filter>
<StartingIndex>50</StartingIndex>
<RequestedCount>50</RequestedCount>
<SortCriteria/>
</u:Search>
</s:Body>
</s:Envelope>
Interesting...
Do you have a particular tool you recommend doing this with Andrew?
-
Not really :) I think I would just inject the HTTP SOAP message into MCs server via the debugger and step through the code and see where it takes you..
-
Actually, this is kind of annoying now. Every time I look at a photo on my phone if connected to my Home Network, MC crashes.
-
Actually, this is kind of annoying now. Every time I look at a photo on my phone if connected to my Home Network, MC crashes.
We'll see what we can find.
-
Still can't reproduce this.
Would you email me the dump file please?
bob (at) jriver (dot) com
Thanks
-
I've emailed the Zip of the Log files... but there is no Dump File in it?? Here is a pic of what I see in Windows.
-
I've emailed the Zip of the Log files... but there is no Dump File in it?? Here is a pic of what I see in Windows.
Thanks, checking into it.
Just in case, do you have the resources to try a linux version?
-
I have an Ubuntu 16 box that runs my Unifi Home Security / Network Infrastructure. I don't think it is very powerful and while I'm not that skilled on Linux but can muddle through.
-
FYI - in the Log the Phone IP is 192.168.1.67
-
FYI - in the Log the Phone IP is 192.168.1.67
Thanks, I hoping we can figure out why you don't have a crash dump.
In this case it would be much easier to figure out that way.
-
Let me know what you would like me to do.... I've a few more days before I'm back to work.
-
Bob,
AndrewFG had a suggestion above:
https://yabb.jriver.com/interact/index.php/topic,113536.msg785298.html#msg785298
Jim
-
Bob,
AndrewFG had a suggestion above:
https://yabb.jriver.com/interact/index.php/topic,113536.msg785298.html#msg785298
Jim
I saw that and tried it as close as I could without triggering the issue which leads me to believe the crash dump would be more useful
-
How about I try:
- Uninstall
- Install 32-Bit : test
- load my library & settings : test
- Install 64-bit : test
- load my library & settings : test
-
I wonder if something at the network layer on the PC is getting confused.
If it were MC, you would think we'd see more problem reports. Still ...
-
jmone and I tracked it down. It's something to do with the web browser (start) window. If that's not showing, no crash.
Nope, still an issue, sigh...
-
I think we are getting closer however.... I've created a new Library (Blank) on this instance and it is not crashing even though the settings (incl DLNA) are all the same. I'm now wondering if there is some particular item(s) in my library that could be triggering it.
-
So I imported all the my images into this new Temp library, and it is not crashing. ;D
I then switched back to my Main Library and it is now not crashing!?!?! (maybe too soon to call it)
Q: If it continues to be stable I don't understand what has "fixed" it, given the two libraries are separate.... or could their have been something updated in my setup / Main library when I created and imported the pics into the Temp library?
-
So I imported all the my images into this new Temp library, and it is not crashing. ;D
I then switched back to my Main Library and it is now not crashing!?!?! (maybe to soon to call it)
Q: If it continues to be stable I don't understand what has "fixed" it, given the two libraries are separate.... or could their have been something updated in my setup / Main library when I created and imported the pics into the Temp library?
The phone is sending a series of CDS:Search() requests for image items, with certain filter parameters, each with successive Offset-Index and Requested-Count values. So I would look at which image items in your library match the filter parameters (in particular matches with “edge” conditions). And also the Offset-Index and Request-Count values (perhaps MC thinks it has more images than it really does, and one of the last “matches” is falling off the edge, or perhaps MC doesn’t like requests for more items than it owns). Also think about duplicate image items that MC may count as two, but only returns as one item. Stuff like that..
PS a CDS:Search example is in this post: https://yabb.jriver.com/interact/index.php/topic,113536.msg785193.html#msg785193
-
@AndrewFG: That was kind of of my approach. I looked at the Capture to see when the MC starter returning garbage then imported those images into MC (the new Temp Library). When it did not crash I started importing the rest (in batches). When that did not crash either, I switched back to my Main Library, and for some reason it is now not crashing either. Good outcome for me but No Idea why it is now not crashing.
-
Cosmic rays.
-
Cosmic rays.
I’m surprised you didn’t mention AV .. :)
-
Yeah well it crashed again.... and it was when my phone moved between WAP. Looking at the last part of the latest log, it is something to do with my image library requests. I have a bunch of these
4475937: 17440: Sharing Plugins: CHTTPListenerWorker::HandleRequest: TCP: 192.168.1.67: POST: http://192.168.1.10:52102/ContentDirectory/control
14475937: 17440: Sharing Plugins: CDLNADeviceServerWorker::ProcessPost: Start
14475937: 17440: Sharing Plugins: CContentDirectoryService::HandleControlFunction: Start
14475937: 17440: Sharing Plugins: CContentDirectoryService::HandleControlFunction: Action: Search
14475937: 17440: Sharing Plugins: CContentDirectoryService::Search: Start
14475937: 17440: Sharing Plugins: CContentDirectoryService::Search: Search: upnp:class derivedfrom "object.item.imageItem"
14475937: 17440: Sharing Plugins: CContentDirectoryService::Search: 1
14475937: 17440: Sharing Plugins: CContentDirectoryService::Search: 2
14475937: 17440: Sharing Plugins: CContentDirectoryService::Search: 3a
14475937: 17440: Sharing Plugins: CMCViewInfoTree::GetSearchFilesItem: Start
14475937: 17440: Sharing Plugins: CMCViewInfoTree::GetSearchFilesItem: Hash: 8690193089776076918
14475937: 17440: Sharing Plugins: CMCViewInfoTree::GetSearchFilesItem: Finish (0 ms)
14475937: 17440: Sharing Plugins: CContentDirectoryService::Search: 3d
14475937: 17440: Sharing Plugins: CContentDirectoryService::Search: 4
14475937: 17440: Sharing Plugins: CContentDirectoryService::Search: 4a
14475953: 17440: Sharing Plugins: CContentDirectoryService::Search: Matching container: 1000 (has 14949 children)
14475953: 17440: Sharing Plugins: CContentDirectoryService::Search: 4e
14475953: 17440: Sharing Plugins: CContentDirectoryService::Search: 5
14475953: 17440: Sharing Plugins: CContentDirectoryService::Search: Finish (16 ms)
14475953: 17440: Sharing Plugins: CContentDirectoryService::HandleControlFunction: Finish (16 ms)
14475953: 17440: Sharing Plugins: CDLNADeviceServerWorker::ProcessPost: Finish (16 ms)
-
..then there starts to be errors mixed in such as:
14518984: 14040: Sharing Plugins: CHTTPListenerWorker::HandleRequest: TCP: 192.168.1.96: SUBSCRIBE: http://192.168.1.10:52100/ContentDirectory/event
14518984: 12792: Sharing Plugins: CContentDirectoryService::HandleControlFunction: Start
14518984: 12792: Sharing Plugins: CContentDirectoryService::HandleControlFunction: Action: Search
14518984: 12792: Sharing Plugins: CContentDirectoryService::Search: Start
14518984: 12792: Sharing Plugins: CContentDirectoryService::Search: Search: upnp:class derivedfrom "object.item.imageItem"
14518984: 12792: Sharing Plugins: CContentDirectoryService::Search: 1
14518984: 8280: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Start
14518984: 12792: Sharing Plugins: CContentDirectoryService::Search: 2
14518984: 12792: Sharing Plugins: CContentDirectoryService::Search: 3a
14518984: 12792: Sharing Plugins: CMCViewInfoTree::GetSearchFilesItem: Start
14518984: 13264: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Start
14518984: 8280: Sharing Plugins: CHTTPRequestMessage::ReadPreamble: Failed to read Method
14518984: 12792: Sharing Plugins: CMCViewInfoTree::GetSearchFilesItem: Hash: 8690193089776076918
14518984: 8280: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Finish (0 ms)
14518984: 12792: Sharing Plugins: CMCViewInfoTree::GetSearchFilesItem: Finish (0 ms)
14518984: 12792: Sharing Plugins: CContentDirectoryService::Search: 3d
14518984: 12792: Sharing Plugins: CContentDirectoryService::Search: 4
14518984: 12792: Sharing Plugins: CContentDirectoryService::Search: 4a
14518984: 9868: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Start
14518984: 9868: Sharing Plugins: CHTTPRequestMessage::ReadPreamble: Failed to read Method
14518984: 9868: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Finish (0 ms)
14518984: 14040: Sharing Plugins: VHTTPMessage::Write: Wrote 0 bytes
14518984: 13264: Sharing Plugins: CHTTPListenerWorker::HandleRequest: TCP: 192.168.1.135: SUBSCRIBE: http://192.168.1.10:52100/ContentDirectory/event
14518984: 14040: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Finish (0 ms)
14518984: 3336: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Start
14518984: 3336: Sharing Plugins: CHTTPRequestMessage::ReadPreamble: Failed to read Method
14518984: 3336: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Finish (0 ms)
14518984: 13264: Sharing Plugins: VHTTPMessage::Write: Wrote 0 bytes
14518984: 13264: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Finish (0 ms)
14518984: 12792: Sharing Plugins: CContentDirectoryService::Search: Matching container: 1000 (has 14949 children)
14518984: 8512: Sharing Plugins: VHTTPMessage::Write: Wrote 0 bytes
14518984: 8512: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Finish (43125 ms)
-
Yup it’s the CDS:Search alright. It seems to work fine when the searches are neatly serialized. But when the calls come thick and fast, and possibly overlapped, then it falls over. I would look into whether MCs SOAP implementation in general, or its CDS Search implementation, is fully thread safe code..
-
The Failed to read method messages are normal. It's a generic message in the http server code that appears with the SSDP stuff since it doesn't have a "method".
That doesn't rule out the search being an issue though. It would be nice if you could get a crash from the build I sent you. It would pin down the location. You'd probably need your material from the troublesome machine as well as the built thumbnails. You might want to do the Help->System Info on the Windows machine to see if they are all built.
-
HI Bob - I checked, All thumbs are built (for Images anyway). I'm running out of time for now to get that build up (I'll need to setup a new box as my exisitng one is headless Ubuntu).
-
Finally got it setup on Ubuntu 16.04 LTS. Took 3 goes of installing the OS / MC etc before I could get MC to install and run. Windows looks good to me! I'll let you know if either crash again.
-
Hi Bob, The Linux build crashed overnight (not sure why). Ran up MC again to output the logs but the logs are all really small and there is no Crash dump. Is this right? (note: logging is ON).
-
Arggg still crashing in MC24. This time my phone was syncing a few items, and I had to wait till it was finished or MC would just crash over and over. Log attached but it looks like all the rest.
-
Would a Memory Dump help?
-
Arggg still crashing in MC24. This time my phone was syncing a few items, and I had to wait till it was finished or MC would just crash over and over. Log attached but it looks like all the rest.
The crash dump would be awesome!
-
Got a DMP for both MC24 and JRWeb. I'll PM you the link when it has finished uploading.
-
Got a DMP for both MC24 and JRWeb. I'll PM you the link when it has finished uploading.
Got it.
It appears to be crashing in JRWeb. Are you using Chromium or the native browser?
-
Native (IE), but swaping to Chromium does not help, still crashes within seconds (let me know if you want more logs, tests etc).
-
Native (IE), but swaping to Chromium does not help, still crashes within seconds (let me know if you want more logs, tests etc).
It's in the message loop. I can't see why it should be crashing there.
Can you package up a new set of dumps so I can see if the crash location changes?
-
Dump uploading (with Chromium as the browser). Liking my new faster upload speed! Anyway will PM the link shorly.
-
Hey bob - any luck with that 2nd Dump File?
-
Hey bob - any luck with that 2nd Dump File?
No, unfortunately it's not giving a break where the crash is.
I took a look at the search again and have been testing it a bit this morning.
There doesn't seem to be any threading issues in there, there is a lock around the view retrieval.
It sure would be useful to be able to duplicate this.
-
No, unfortunately it's not giving a break where the crash is.
I took a look at the search again and have been testing it a bit this morning.
There doesn't seem to be any threading issues in there, there is a lock around the view retrieval.
It sure would be useful to be able to duplicate this.
I think we have something to try. I'll PM you with a test build.
-
That would be great as otherwise I'm thing of changing phone's. I'll be away for a few days so no rush.
-
That would be great as otherwise I'm thing of changing phone's. I'll be away for a few days so no rush.
You've got a link to the DL now.
Please don't change phones, it will be nice to fix this!
Thanks!
-
Still crashing, next log send by PM. Thanks for the persistence.
-
I think you are on the right path!!!! I had 3 DLNA renderers (say low, med, high). If I delete them all and just add "Generic DLNA" then MC does not crash. If I then add "Audiophile", MC will then crash.
-
I think you are on the right path!!!! I had 3 DLNA renderers (say low, med, high). If I delete them all and just add "Generic DLNA" then MC does not crash. If I then add "Audiophile", MC will then crash.
Weird because in that last test build we added a lock to handle just that situation, will keep looking.
-
I think you have it licked ;D No crashing so far with the latest test build!
-
I think you have it licked ;D No crashing so far with the latest test build!
Thanks for the report, fingers crossed!
-
It's been good all day. No crashes and no weirdness that I've noticed.