All Windows these days Jim.
I rebooted just in case. Radio JRiver still works fine. I think Cloudplay has worked in the past for me, but I haven't tested much... Sort of. See below.
I did try to play several User's playlists, and just tested on yours again Jim. Still doesn't work.
My firewall allows JRWeb.exe, JRWorker.exe, and "Media Center 25.exe". There doesn't seem to be anything of note in the firewall history. The firewall shouldn't block outbound HTTP or HTTPS calls anyway, if that is what Cloudplay is using.
In Task Manager "Media Center 25" shows a tiny bit of network activity on either trying to download a playlist, or play the playlist. Trying to play the playlist just goes on for a bit longer, and Windows marks MC as "Not Responding" after a while, until MC25 quits trying.
In the Windows Resource Monitor, clicking the Play icon for a playlist sees an awful lot of local ports being opened. About 80 different local ports. I guess trying to get a port out to the target address, which always uses port 443.
i.e. 192.168.0.10 ports in the range 50xxx to 215.14.187.171 port 443.
In fact, the starting port number for the outbound port just increments 100 each time I click the icon.
That doesn't seem real logical. I could understand trying different ports at the target end, trying to find an available port, but not at the source end.
Given that port 443 is used for HTTPS, or HTTP protocol over TLS/SSL, the problem is probably a security issue. The server doesn't like the request from my PC. But why?
Actually, I think when Cloudplay did work for me, on April 3rd, I was using the browser interface, user.jriver.com. I still have a couple of downloaded playlists from then. That still works, but not as expected, in that clicking the Play button, which points to "
https://user.jriver.com/playlists/play/1882/playlist.mpl", the playlist is downloaded rather than played. I get the file "Decade (2000 - 2009).mpl" for example, which is one of Jaxtherogue's playlists and points to the files on "
https://s3.amazonaws.com/content.jriver.com/users/etc." and can, of course, be played in MC25.
It could a security setting on my PC that results in the playlist being downloaded rather than played. i.e. Some settings around not opening downloads from the internet directly. Certainly there are dangers is opening files directly from the internet, but I do it all the time with PDFs and so on. I would have to investigate that for mpl files.
Clicking on the download icon in the web version of Cloudplay does nothing, which is not surprising, since it points to the URL "localhost:52199/MCWS/v1/SharedPlaylists?function=download&downloadtype=playlist&id=1882", which is my local PC. Pointing at a MC server to boot, which isn't going to have playlist 1882, until I download and import it. Which doesn't work with the download icon. That's a circular problem right there. Even when I import that playlist, the download icon does nothing. In fact that is exactly the same URL as appears in the bottom status line of the MC Cloudplay pane, when I hover over the download icon for the same playlist. So is the web version of Cloudplay actually pointing to a MC implementation, which handles the requests for playing or downloading Playlists, or is it just that Cloudplay on the web is incomplete, and contains stuff carried over from the MC implementation?
I would really like this Cloudplay to work. Just about everybody other than me can build better playlists. I might actually improve my appreciation for music (I'm mostly a video guy).
Author
Topic: CloudPlay Questions and Answers (Read 34217 times)