Post Reply 
GETTING STARTED
20-12-2015, 18:01 (This post was last modified: 20-12-2015 18:03 by simoncn.)
Post: #111
RE: GETTING STARTED
(20-12-2015 17:00)rockerz Wrote:  Since disabling the VPN settings and rebooting per your instructions It has worked perfectly. Thanks again for all of your help and advice. I have learned a lot .

Thanks very much for your patience and perseverance while we worked out what was causing the problem. I have learned a lot as well.

I will try to reproduce the problem on my own QNAP. This might enable me to find a solution that would enable MinimServer to function correctly with these VPN settings enabled.
Find all posts by this user
Quote this message in a reply
20-12-2015, 18:46
Post: #112
RE: GETTING STARTED
(20-12-2015 18:01)simoncn Wrote:  I will try to reproduce the problem on my own QNAP. This might enable me to find a solution that would enable MinimServer to function correctly with these VPN settings enabled.

I enabled the VPN settings on my QNAP but I haven't been able to reproduce the problem. What IP address is MinimServer using on the QNAP? You can find this by selecting About from the MinimWatch minim icon. The "Running on" line gives you the MinimServer IP address and port.
Find all posts by this user
Quote this message in a reply
20-12-2015, 22:06
Post: #113
RE: GETTING STARTED
192.168.11.6:9791
Find all posts by this user
Quote this message in a reply
20-12-2015, 23:44
Post: #114
RE: GETTING STARTED
(20-12-2015 22:06)rockerz Wrote:  192.168.11.6:9791

Thanks! I now have some idea what is causing this problem. It looks like a problem in the ohNet UPnP stack that MinimServer is using. This seems to sometimes get its responses to M-SEARCH requests a bit scrambled when a VPN server is active.
Find all posts by this user
Quote this message in a reply
20-12-2015, 23:57
Post: #115
RE: GETTING STARTED
Thanks I wish I had a clue to what you are talking about?
Find all posts by this user
Quote this message in a reply
21-12-2015, 01:13
Post: #116
RE: GETTING STARTED
(20-12-2015 23:57)rockerz Wrote:  Thanks I wish I had a clue to what you are talking about?

I am slightly tempted to explain in more detail but I will resist the temptation. Instead, I will apply my efforts to finding a way to fix the problem. Smile
Find all posts by this user
Quote this message in a reply
21-12-2015, 02:07
Post: #117
RE: GETTING STARTED
Fair enough Smile
Find all posts by this user
Quote this message in a reply
21-12-2015, 20:30 (This post was last modified: 21-12-2015 20:47 by DavidHB.)
Post: #118
RE: GETTING STARTED
(21-12-2015 01:13)simoncn Wrote:  
(20-12-2015 23:57)rockerz Wrote:  Thanks I wish I had a clue to what you are talking about?
I am slightly tempted to explain in more detail but I will resist the temptation. Instead, I will apply my efforts to finding a way to fix the problem. Smile

While Simon (quite rightly in my view) concentrates on finding the fix, I'd like to have a go at offering an explanation. Simon can mark me out of 10 afterwards Smile.

A network streaming system consists of a number of components (called 'devices') which perform specific functions and communicate with each other over the network. To do this, they need to send each other messages in a format (or protocol) that all the devices will understand. The protocol used for music streaming is called UPnP AV, often shortened to just UPnP. This provides a defined standard for messaging. MinimServer is a UPnP device.

There is another standard that is widely used, called DLNA. This uses essentially the same messaging standard as UPnP, so DLNA devices like many network players and UPnP servers like MinimServer can, more often than not, communicate with each other.

The UPnP protocol is complex and extensive; writing software from scratch to implement all of its features would be a massive task. So developers like Simon who write UPnP-based applications typically make use of a UPnP 'stack', which is a set of software building blocks from which elements of the complete application are constructed. For MinimServer, Simon uses a stack called ohNet, which is part of the open source OpenHome initiative. What that means to you and me is that the stack is provided free of charge, which is part of the reason why MinimServer is free to download (with a donation from users requested).

When one device on the network wants to find out if another device is present, it sends out what is called an M-SEARCH request. Actually, it typically sends out rather a lot of such requests. The problem that Simon has identified is that the VPN is in some way interfering with this search for devices. The relevant code is in one of the ohNet 'building bocks'. Once Simon has found the cause of problem (he has access to the code, because it is open source), he may be able to provide his own fix, or he may need to consult the ohNet developers.

I hope that this explains things reasonably clearly.

David
Find all posts by this user
Quote this message in a reply
22-12-2015, 17:09
Post: #119
RE: GETTING STARTED
A fix for the VPN discovery problem is now available in MinimServer update 75.

@DavidHB: Thanks for your very clear description of the M-SEARCH message.
Find all posts by this user
Quote this message in a reply
22-12-2015, 17:31
Post: #120
RE: GETTING STARTED
That was an outstanding explanation. Thanks very much!!
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)