[norswap]

Hey folks,

I'm looking to stream my music from my phone to my computer.

At home, I managed to do this by installing Kodi on my (Windows) computer, enabling UPnP control in services, then selecting the computer as a target in an Android app (I use "Hi-Fi Cast", but it should be irrelevant).
This works nicely, because of auto-discovery.

At work, I use a Mac laptop, and I want to do something similar. The problem is that auto-discovery doesn't work in this case, I assume due to the configuration of the network.

I'm pretty sure UPnP would work well with the Mac at home, I'll try this latter to make sure.

1) Could I manually indicate Kodi's UPnP renderer to my phone? Hi-Fi Cast has an URL field for this, but a solid hour of googling did not help me find what to put there. I know my IP, but on what port does Kodi serve the UPnP "device descriptor/description"? Is the protocol http?

2) Anyhow, my goal is not necessarily to make UPnP work, I just want to stream my music to my laptop! Is there any other way that might allow me do this? I have full control over my phone (unrooted) and my laptop, but not over the network configuration. The solution doesn't even need to use Kodi (though this be the Kodi forum, I suppose it would be preferable). I'll take your wild shots, but please do indicate whether you ever made something similar work or not, so that I know how much effort to invest in the solution.

Thanks!

[dandnsmith]

this url may help a bit

[norswap]

Thanks for the answer, but trust me, it doesn't.

I even pulled up the UPnP spec, and the point is that there is no mandated URL for the description, as it is supposed to be served as a result of discovery.

[Kib]

UPNP requires several networking components to be available. (UDP multicast discovery, UDP port 1900 open)
Enterprise networks usually block these to prevent people from sharing data locally over UPNP.

No way around it, use unicast sharing if you must (set up a fileshare and connect to it from your client)

EDIT: Actually more common is to disallow endpoint clients from connecting with each other at all on corporate networks. There is usually no business reason to allow client A on the wireless to talk to client B; it only adds a security risk so it is disabled globally.

[norswap]

Bummer!

Actually the network is not that locked. It's an university network, and you can certainly do a bunch of things like ping other devices or ssh into devices on the network.

I was afraid I'd have to resort to that. I would have avoided it because I had some mixed results with SMB sharing in the past. Maybe FTP could work, to be investigated.

Regarding SMB, using this app works, with a few caveats: https://play.google.com/store/apps/detai...x.landrive

The biggest caveat is that it only works on OSX - Windows forces the port number 445 and you can't pick that port if your Android device is rooted.
The author suggests a local port forwarding tool (https://www.verigio.com/products/multi-port-forwarder/) to bypass the issue, but I haven't tried it.
Apparently Linux has issues has well, but since I don't use it I can't comment.

Even on OSX, network auto-discovery does not seem to work (the server shows, but connection fails), one needs to use "Connect to Server..." and specify the port number explicitly.
That does work nicely, but the free version of the app throttles bandwidth to 0.5M/s (it feels like even less).

This app seems to be the only one that actually works to run a SMB server on Android, as per comments (!)
I tried this one: https://play.google.com/store/apps/detai...rsultimate which seemed promising.
I managed to authenticate from OSX, but then it serves a protocol version error or some such garbage.

All this was tried at home, I'll try at the university and report. I'll also investigate using FTP sharing instead.

I'm somewhat amazed that such a simplistic use case (streaming from phone to computer via network) ends up being so damn difficult.

[norswap]

Also regarding UPnP, I get that the discovery doesn't work; but the protocol ultimately serves the URL of some kind of XML description document.

IF that URL is fixed and it is available regardless of whether some device attempted discovery, then getting hold of the URL would allow me to stream to Kodi even though UDP multicast is disabled.

I was hoping some developer could give some insight on that.

... Actually I ended up looking, and while it's not quite clear, here's what I have traced from the Github repo, starting with a search on "M-SEARCH" (the name of the UPnP message whose response includes the description URL)

https://github.com/xbmc/xbmc/blob/6fcbb1...p.cpp#L172
https://github.com/xbmc/xbmc/blob/6fcbb1...a.cpp#L106
https://github.com/xbmc/xbmc/blob/6fcbb1...st.cpp#L59
https://github.com/xbmc/xbmc/search?p=3&...DeviceHost

From that last search, we can see that the descriptor URL could either be the root ("/") or "/DeviceDescription.xml".

If we look at the first link, the port could be 5000. This does seem to check out with this description: https://www.grc.com/port_5000.htm

When UPnP devices wish to announce themselves, or "shout out" to find out what other UPnP devices are hanging around on the network, they issue a UDP message aimed at port 1900 of the special IP address [239.255.255.250]. This special "multicast" broadcast address has been set aside for UPnP devices and will be received by all of them listening on UDP port 1900. After such an announcement broadcast is made, any devices wishing to reply or respond to the broadcaster initiate a TCP connection to the broadcaster's TCP port 5000. The devices then engage in a dialog to meet their needs. As you can see, UPnP enabled devices will be opening and listening on UDP port 1900 and TCP port 5000.

Anyone with the knowledge necessary to confirm / infirm this? Might try toying with this hypotheses sometime later when I have the time.

(Sorry for the double post, but I can't seem to be able to edit the previous one. Not high enough forum standing?)

[norswap]

Holy shit, I got it to work!

So port 5000 was a dead end, but I had the idea to scan for listening ports using

Code:

sudo lsof -i -n -P | grep TCP

(alternative commands here: https://stackoverflow.com/questions/4421633)
This turned out that Kodi was listening on 1912, 1655, and 9090.

Well it turns out the device description can be reached at

Code:

http://<ip>:1655/

!
Inputting this into Hi-Fi Cast makes it work perfectly, even on the university network.

Some more reports:

- LANDrive did not work at university because the network is not NATed (LAN IPs == public internet IPs)
- But using WebDAV and FTP servers via Servers Ultimate on Android did work (FTP feels a bit more snappy, ignore the "Native FTP" option)