I should also say, that like many today we have plenty of upload bandwidth to be able to stream out video (well mine is only 50mbps but it is "good enough").
this is a real video of a red belly black snake at our front door.... we get a few!
Token: {File:24514625, Expiry:1612558645, Flags:0}
Encoded: mfhfiP5H0MMlO9id2YkWKzRFNRFe66lqTzkGvCHDf4gOp11O79k8ezCK
URL: http://73.164.109.246:52199/MCWS/v1/Share?token=mfhfiP5H0MMlO9id2YkWKzRFNRFe66lqTzkGvCHDf4gOp11O79k8ezCKA simpler idea:I think we need to make it easy to share a file or files with a Share link that uses the standard icon.
- [Shared] field, user can check/uncheck
- "Enable Sharing" in Settings, with a distinct User/Password
- Accessing MCWS/Panel will that account will only serve Shared files.
Like I could create a guest access key, give it to somebody which when they use that access key within their copy of MC it'd connect and prompt me at my end informing me there's a connection attempt, that I can accept, temp allow it for X amount of time, deny, ignore, etc.
I think multiple libraries is problematic - updating the file tags in the main library would not update in the other libs, so this would require too much management overhead.I don't think we care much about that once a file has been shared. You could always share it again if you did care.
What about sharing playlists instead of files? We could have different playlists for different people, different credentials/key per playlist, etc. Seems more practical than distinct libraries. This could work for any generic playlist, or you could add a special Playlists\Shared section in the tree. Playlist Groups could also be used to share a group of playlists to the same person.I can imagine situations where you might want to share different sets of files with different people. Grandma gets the cleaned up version without all the empty beer bottles, for example.
7. NEW: Added the right-click command Get Sharing URL... to get a URL from MCWS to share externally (it uses your external IP address, so you will need to set port forwarding on your router).
6. Changed: MCWS no longer requires authentication for functions marked to not require authentication.
I don't propose to know the right way of doing this (zybex could be correct), but from a users POV:
- MC Needs to generate a random token
- This should be stored in a Database field (so you can see what it is and re-use it)
- This needs to be clearable (so to stop sharing)
What they actually require is:
1. MC should share those files the user has explicitly asked it to share, and ONLY those files.
2. They need to be able to see what is shared
3. They need to be able to see the URL for access, so that they can give it to others
4. The URL from one copy of MC shouldn't work on another (URLs are unique or non-transferable)
5. They need to be able to stop sharing
Most routers would be smart enough to just route that request internally in your network.
How useful is the local sharing?Testing. Large network like a university or a business.
Wouldn't the internet link just work in the occasion you need something local?
Most routers would be smart enough to just route that request internally in your network.I didn't know that. Is it safe to assume it's 100%? I'd rather not find out the hard way.
Regarding the local vs remote URL... I agree that the remote one is what makes sense.Interesting idea. Do we know the FQDN? If the user has to set it, we end up doing network support. Local vs Internet is clear and simple to explain.
What about adding a setting/RegistryKey to add an FQDN? If it's blank, then MC would use the public IP; if it's defined then it would use that instead.
Testing. Large network like a university or a business.I didn't know that. Is it safe to assume it's 100%? I'd rather not find out the hard way.
Interesting idea. Do we know the FQDN? If the user has to set it, we end up doing network support. Local vs Internet is clear and simple to explain.
Cool :) Encryption looks good. Just a note: please ensure that the encryption key is unique for each PC or MC install. This should not be the same as the Access Key... maybe you can generate a random key on first time use.
The thing with external IPs is that they change, so the links become invalid. Only companies have fixed IP addresses. Having the option to use a dyndns domain is nice; I bought a domain name with dynamic IP support and use it to reach my home services.Our Access Key sever keeps track of the outside address. We use that server for this new sharing feature.
No - MC could do a reverse DNS lookup to find the FQDN but that won't work for dynamic domains like "myhome.dyndns.org".
The user would need to somehow give it to MC - if one is knowledgeable enough to have a DynDNS, one knows how to use it (I hope). The alternative is to have to edit all MC Sharing links to replace the IP with the FQDN.
The thing with external IPs is that they change, so the links become invalid. Only companies have fixed IP addresses. Having the option to use a dyndns domain is nice; I bought a domain name with dynamic IP support and use it to reach my home services.
<VirtualHost *:52200>
ServerName home.mydomain.com
Include /usr/local/apache2/conf/options-ssl-apache.sslconf
SSLCertificateFile /usr/local/letsencrypt/live/fullchain.pem
SSLCertificateKeyFile /usr/local/letsencrypt/live/privkey.pem
ProxyRequests Off
ProxyPass / http://192.168.2.103:52199/
ProxyPassReverse / http://192.168.2.103:52199/
ProxyPreserveHost on
</VirtualHost>
You can't use that, really... the generated Sharing URL is a public address which does not link in any way to JRiver's access keys. It's either an IP address or a domain name.No, you don't use the Access Key, but yes, we use our Access Key server to get your current IP address.
There's an option to "Enable SSL" under Settings->Media Network, using port 52200. You can provide your certificate as well. So I think you can skip your proxy server.
No, you don't use the Access Key, but yes, we use our Access Key server to get your current IP address.
1. Changed: Added URL escapement to the share URLs.
4. Changed: When sharing, a choice is offered about what link to place on the clipboard.
Looks like (for Video) only MP4 plays in Web Browser, the other types are not shown in the Web Browser but are download automatically. So (for video):
- Would using Hendrik's new MCWS API for Video Streaming like that used for JRemote2 be a better idea? I expect this should then work with all video (including compound videos like DVD / BD etc) on any device regardless of Formats, Bitrates etc (and the Bitrate should be better for streaming)?
- If the above is added then a "nice" to have would be for the Download Button option to allow for either the converted stream or original but.... I'd just be happy with the above.
That is not really related. If you want to be able to watch every video in-browser properly, it would likely have to produce some kind of website with an actual video player component on it, similar to Panels player page.Couldn't the server convert?
That is not really related. If you want to be able to watch every video in-browser properly, it would likely have to produce some kind of website with an actual video player component on it, similar to Panels player page.
That is not really related. If you want to be able to watch every video in-browser properly, it would likely have to produce some kind of website with an actual video player component on it, similar to Panels player page.
That is not really related. If you want to be able to watch every video in-browser properly, it would likely have to produce some kind of website with an actual video player component on it, similar to Panels player page.
...but you already have that new high quality AutoFPS MCWS call that will produce a webplayable stream that is used by JRemote2 etc. Only about 20% of my Videos are MP4, so the other 80% will not play with the current method, but 100% will if using your new MCWS call. Without on-the-fly conversion then I'm not sure this public URL feature is all that useful (to me), unless I make a MP4 versions of everything I want to share first (which is an option I guess).
We're working on a set of video streaming improvements for MCWS and JRemote2 for Android. They will arrive later this month.
All these changes are designed for cases when streaming video to the remote device, ......
The other thing I use a web server for is to host pics to be used to embed IMG links in forums (especially when you can't attach). Lets see if the share links works for this.Maybe because it's not an image. Try making it a simple link.
Image imbedded between the lines using "Insert Image Link" option on the forum sw
--------------------------
(http://144.137.208.82:52199/MCWS/v1/Share/Get?File=8dli%2FaQTYeT%2BzDMXBo9ZKqjWkPbDN4DhZISpDjK2moSPSTKGLRjyoRxg1F5uMoYC%0AICd0bok%2BZ7cUrJmzKQcSDg%3D%3D)
--------------------------
edit - Nope. just above is the following wrapped in the img tag (img)(/img) (but with square brackets) but nothing appears
http://144.137.208.82:52199/MCWS/v1/Share/Get?File=mwZDhP%2BGhvcquLv5kBISJNzON2X5ohUoz0Ll1b2a9emPSTKGLRjyoRxg1F5uMoYC%0AICd0bok%2BZ7cUrJmzKQcSDg%3D%3D
[Shared] - Bool. When user generates the Sharing URL, this field gets checked. If the user unchecks it the file cannot be played using the Sharing URL. This allows:
- un-share a single file instead of having to invalidate all shares
- temporary un-sharing
- easy list/filter for currently shared files
[Shared] - Bool. When user generates the Sharing URL, this field gets checked. If the user unchecks it the file cannot be played using the Sharing URL. This allows:
- un-share a single file instead of having to invalidate all shares
- temporary un-sharing
- easy list/filter for currently shared files
I tested out expiring the links and that worked. Good idea. Does that mean that I can somehow generate a report in MC of all the links I've created? Anyway to manually manage that, ie - expire one link, but not all? Or when sharing, set a default expiration? OneDrive does this well. When you go to make a sharable link, you can set an automatic expiration after X days.
That would accomplish what I was thinking here fairly elegantly:QuoteI tested out expiring the links and that worked. Good idea. Does that mean that I can somehow generate a report in MC of all the links I've created? Anyway to manually manage that, ie - expire one link, but not all? Or when sharing, set a default expiration? OneDrive does this well. When you go to make a sharable link, you can set an automatic expiration after X days.
http://my.mchome.net:52199/Share?File=ZaV5zK3P1XeCollisions would need to be prevented. Security would come from the randomness of the identifier, hard to guess a valid one.http://my.mchome.net:52199/Share?File=123456&Name=The%20Croods%3A%20A%20New%20Age&Sig=5zK3P1XeThe &Name= parameter is entirely cosmetic/optional (can also be added on the first method above). The &File has the actual file Key to share, and the &Sig has an encrypted hash that must match some server-generated hash for this URL/File.It doesn't show your image because its http (not https), and mixed content is no longer allowed in any modern browsers.
Media Network -> Enable SSLIf you use the MC generated certificate, I think most browsers will throw a wobbly over it?
I suppose the links will be https:// with this option enabled.
Yeah - I've tried using the self MC generated SSL but could not get it to work either.... hence I thought I'd throw it out to those that know this stuff way better than me!
Why can't that url be the filename, that when clicked goes there... You know what I mean? What is it in html speak... <a href=?The URL would need to include the full path - just the filename could lead to collisions (same filename in different folders, which one to play?)
You need to provide your own certificate. It's not trivial, you need to buy a domain name, get the certificate for it, and the Sharing URLs need to use that domain instead of the IP address...
eg, this works to embed : https://behome.dyndns.info/index.php/s/AxQpXKqAZWKD66F/previewI can see that image.
The URL would need to include the full path - just the filename could lead to collisions (same filename in different folders, which one to play?)C'mon zybex, I know I can be a bit slow on the uptake sometimes...? I followed the entire thread from inception. Now I'm at my PC, maybe I can explain better...
Since chars like slash, dots, spaces, symbols, etc, would need to be URL-escaped (%2F...), the URL would still be ugly, and long. Having the FileKey (unique number) in the URL is a shorter way to uniquely point to a given file.
Also, security: Just the filename or Key isn't enough, people could guess other names from your naming schema. So the URL needs to include some encrypted token that the server can verify.
The first link works. The second doesn't. Port forwarding or firewall?Could be.... but I find if I click on the 2nd link you will notice it is "loading" but it takes several minutes rather than actually failing.
C'mon zybex, I know I can be a bit slow on the uptake sometimes...? I followed the entire thread from inception. Now I'm at my PC, maybe I can explain better...Oh, I can be pretty dense too as you just pointed out ;D
Thanks, your SSL link started up just fine (apart from buffering - you need a bigger pipe .... or on the fly transcoding!!! ;) )I don't think so, looks like MC is really slow doing this. I have 500/25 Mbps. Your first link/image above also takes 5 seconds to show up completely, and that's just 100KB - Chrome draws it in chunks as it arrives. Then it takes another 5 seconds to receive the favicon, which is about the same size. See timeline below - note that it's the download itself that takes a long time, so it's MC that is uploading veeeeeery slowly.
Does my Link2 open up for you OK or do you get a 3min wait?2.7 minutes. The image also appears in chunks during the last 5 seconds - the rest of the time Chrome is just waiting, no data is arriving.
I see the same delays when accessing your DynDNS link using my cell phone over 4G or Wifi.
It is weird. Maybe some security check on your router? Or even your ISP? But that doesn't explain why it works fine on your nextcloud...
I don't think so, looks like MC is really slow doing this. I have 500/25 Mbps. Your first link/image above also takes 5 seconds to show up completely, and that's just 100KB - Chrome draws it in chunks as it arrives. Then it takes another 5 seconds to receive the favicon, which is about the same size. See timeline below - note that it's the download itself that takes a long time, so it's MC that is uploading veeeeeery slowly.In general that seems to be my experience also when I tested from cable to mobile. According to Windows Task Manager ethernet seemed to send data @10mbps when sending a file from MC to mobile. Trying same with other application I was able to send same data ~50mbps. I have ~800/100 mbps connection
2.7 minutes. The image also appears in chunks during the last 5 seconds - the rest of the time Chrome is just waiting, no data is arriving.
(same router, WAN IP, but it is on a different subnet, port and firewall rules)
Do any of these calls go via JRiver's servers in the US?No.
What do you mean "same router, different subnet"? Are you using VLANs?
What is your IP config (IP, netmask, gateway, dns) for the Router, PC and nextcloud ?
Here's an MP4 over HTTPS+DynDNS: Olaf's Frozen Adventure (https://troti.net:52200/MCWS/v1/Share/Get?File=V9Q5pZjenSFuvwxEA6%2FpfCkDTg34%2FPJVVLtxs6zfj5nZfle8DaKoTRsKeXa8fZDt%0AKvezDJL%2FNq8ZmoAx7atGaw%3D%3D)
So, I've got a bit further:
- Created a new DynDNS name for my IP Address
- Created a SSL certificate for the DynDNS name using "Certify the Web" GUI / Lets Encrypt
- Loaded the SSL certificate and key into MC
Link1: Here is the non-ssl (std Share link): Works and the image displays pretty well straight away
http://144.137.208.82:52199/MCWS/v1/Share/Get?File=wUgLY6bHiVXo8ImCBhqPU3VNbble%2FmCo%2BRzTRaMN5XyPSTKGLRjyoRxg1F5uMoYC%0AICd0bok%2BZ7cUrJmzKQcSDg%3D%3D
Link2: Here is the same link but changed to use HTTPS, MC SSL Port, & DynDNS: It eventually loads...... but it takes ages (eg a few minutes) to show the picture.
https://mymc.dyndns.info:52200/MCWS/v1/Share/Get?File=wUgLY6bHiVXo8ImCBhqPU3VNbble%2FmCo%2BRzTRaMN5XyPSTKGLRjyoRxg1F5uMoYC%0AICd0bok%2BZ7cUrJmzKQcSDg%3D%3D
EDIT:
- If anyone can test by clicking on the two links and letting me know if they load about the same?
- Oddly, If I access this link from outside my LAN (eg using my phone over a 4G etc) then it is quick. It is only deadly slow if my device is connected to my LAN (wired or wifi). Something weird ....
Here are some links of a 30sec video
MC Links
http://144.137.208.82:52199/MCWS/v1/Share/Get?File=8dlSvKW3vpF1QpmlzE%2BUZ804uzsI1XixknlNTB9VrSCvwmOUzOZx2fBsAfKzeLkX%0AICd0bok%2BZ7cUrJmzKQcSDg%3D%3D
https://mymc.dyndns.info:52200/MCWS/v1/Share/Get?File=8dlSvKW3vpF1QpmlzE%2BUZ804uzsI1XixknlNTB9VrSCvwmOUzOZx2fBsAfKzeLkX%0AICd0bok%2BZ7cUrJmzKQcSDg%3D%3D
NextCloud Link
https://behome.dyndns.info/index.php/s/LLrKNdnbNf9QJPW
1) Performance of the MC Server?Unlikely. It's just serving a file. Not a heavy load at all.
Here are some links of a 30sec video
MC Links
http://144.137.208.82:52199/MCWS/v1/Share/Get?File=8dlSvKW3vpF1QpmlzE%2BUZ804uzsI1XixknlNTB9VrSCvwmOUzOZx2fBsAfKzeLkX%0AICd0bok%2BZ7cUrJmzKQcSDg%3D%3D
https://mymc.dyndns.info:52200/MCWS/v1/Share/Get?File=8dlSvKW3vpF1QpmlzE%2BUZ804uzsI1XixknlNTB9VrSCvwmOUzOZx2fBsAfKzeLkX%0AICd0bok%2BZ7cUrJmzKQcSDg%3D%3D
NextCloud Link
https://behome.dyndns.info/index.php/s/LLrKNdnbNf9QJPW
All the links buffer badly. I downloaded the first link and it took 5 minutes to download. Using Chrome with Windows 10 on Comcast. Speedtest gave 120 Mbps while I was downloading. Clearly being throttled somewhere. Amazon Prime plays HD movies fine.
That was probably me swapping routers. I had to set QOS/Shaper on my router for the upload @ 50mbps as I was hitting the FTTP policer (Australian NBN) and it was throttling my upload (down to only 10mbps). That part should now be "fixed" now from what I can see.
I just noticed MC serving a file to "red.jriver.com" - Jim was that you? :)Yes, but my office has a wi-fi link so it didn't stream without pausing.
The nominal speeds aren't reliable. Try running an Internet speed test (https://support.google.com/websearch/answer/6283840?p=speedtest&visit_id=637488596684658151-2012735645&rd=1) a few times.
I have a pretty slow connection at home because it's enough for me. But when I run the speed test, I get results that vary a lot. I think it's the girls at the end of the street watching movies in their rooms.
I think the best way forward would be to add the concept of Shared Playlist...
It seems to me that if you have a single playlist or smartlist named "Public" it will be shared...
What about sharing playlists instead of files? We could have different playlists for different people, different credentials/key per playlist, etc. Seems more practical than distinct libraries. This could work for any generic playlist, or you could add a special Playlists\Shared section in the tree. Playlist Groups could also be used to share a group of playlists to the same person.