Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Delay when calling DvDevice.destroy
11-04-2013, 10:50 AM
Post: #4
RE: Delay when calling DvDevice.destroy
(09-04-2013 11:22 AM)PeteManchester Wrote:  I am working on a Java Media renderer and seem to have an issue when calling the destroy method of the DvDeviceStandard.

In my code when I shutdown I call the dispose methods of all my providers and then call DvDevice.destroy. Sometimes there is a delay of about 5 minutes until the method is completed.

Are there any timeouts that I can configure or could I be doing something wrong in my code.

I can't see anything obvious which would cause this. It sounds like your shutdown order isn't quite right - you should really dispose of (or at least disable) your devices before disposing your providers - but I can't imagine that'd cause this problem.

If you can give me a smallish test case which demonstrates the problem I'd be happy to debug it. If this isn't feasible, here's some more info which might help you add some logging to narrow the problem down.

Disposing a device ends up calling DviDevice::Destroy(). This signals that all protocols (only DviProtocolUpnp for now) should be disabled. Disabling is an asynchronous process so Destroy waits on a semaphore being signalled when it finally completes. This normally takes a few tens of milliseconds but is the most likely place your code is blocking. It'd be interesting to log the times before and after the line iShutdownSem.Wait() to confirm whether this is the source of your delay.

Assuming byebyes are the cause of the delay, you could then move on to look at DviProtocolUpnp. It'd be interesting to log the times DviMsgScheduler::NextMsg runs to see if the timer thread which drives all notifications is being blocked by a different client. Note that this will generate a fair amount of log data, particularly if you have a number of UPnP control points on your network.

(09-04-2013 11:22 AM)PeteManchester Wrote:  Also if I force the app to stop using task manager and then start up again, the control point cannot find my app, it seems I have to stop my app, wait for a few minutes and then start again..

If you kill your device stack process, it won't have a chance to send byebye messages, informing any control points that its devices are no longer available.

Depending how you initialise/use ohNet, when you restart your device stack client it may publish devices with a different udn or on a different tcp port. Some control points (Kinsky included) fail to recognise when a device moves to a new location without first sending a byebye. Such control points will either need to be restarted or wait for their 'stale' devices to expire (taking up to 30 minutes).

If this sounds like it might be your problem, you could work around it by using InitParams.setDvServerPort to use a consistent port on all runs of your program. If you do this, you might want to eventually add a config option to allow users to select a different port (either to allow two instances of your app to be run or to guard against another program hard-coding use of the same port).
Find all posts by this user

Messages In This Thread
RE: Delay when calling DvDevice.destroy - simonc - 11-04-2013 10:50 AM

Forum Jump: