Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[jmone]

Not a new suggestion, but last night I tried to share a home video with a friend and they stream everything these days.  I had to post my video on my Nextcloud Site, so they could download it, then copy to a USB Stick, then put it in the TV, then run up some app, then play it.  It worked but is ugly.

It does not need to be this way as almost all the components are already in MC to allow "clients" to stream media with the exception of the ability to create a "Public URL" to an item so it can be accessed by an browser anywhere in the word.... just like YouTube except it streams from your own MC Instance (and not a "Cloud").
- Media Server Profiles for transocoding already exists
- Media [url=http://wiki.jriver.com/index.php/Network_Access]Network Access[/url] all sorted
- Web Services engine already exists

... All we would need is the ability for MC to be able to generate a URL that can be shared and then use that link to either download or play the file.


Here is an example of how my NextCloud instance does it (but it's video transcoding is non existent):
https://behome.dyndns.info/index.php/s/wrXHafPiscg5wt8


Thanks
Nathan

[Edit by JimH -- This was implemented and is in 27.0.66 or higher:  https://yabb.jriver.com/interact/index.php/topic,128554.msg892107.html#msg892107 ]

[rpalmer68]

I was hoping for something a little more exciting Nathan!

But yes I agree, it would be a handy feature at times.

[jmone]

Hey Richard - Long Time!

I think it is actually a big thing.  More and More people are going online only for media consumption.  I think MC should join in and become an server for such consumption over the web.  The family we visited used to be a MC user but now just stream everything, they simply don't have a local "player", so it makes sense that I should be able to just send them a URL that can play.

[jmone]

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").

[zybex]

It's a nice idea and certainly very useful, even for streaming our content ourselves when we're on vacation or outside the house. You can already do that with 3rd party software, not integrated into MC.

However, there are some additional considerations that make it a bit dangerous to share content:
- upload speed limit: most internet connections are asymmetric; the upload speed is much lower than the download. By streaming media, your upload can get saturated even with a single video stream, depending on quality. When that happens your DL also goes down the drain due to delayed ACKs.
- realtime transcoding sucks. Poor quality, and high CPU usage leading to fan noise and heat. Can't be done on a cheap HTPC, requires a good CPU or an expensive GPU. This can be avoided by doing direct streaming (no transcoding), but that only works for some video formats like MP4 (MKV won't work, for instance), and uses up more of that upload bandwidth.
- Sharing control: by giving a link to someone, how do you make sure that it won't get re-shared over and over again until you lose all control? Parents share the link to the daughter, who shares to a friend, who posts it on facebook; BAM, you now have 50 people accessing it, and there goes your internet connection until you block it.
- Related to the previous one, there are legal implications of sharing content. It's fine to share your home videos, but if you share a movie you legally bought and ripped, and then lose control and it gets widely shared or even torrented... tough luck, you're now liable.

I have remote access to my collection for when I'm on vacation, but I only use it for myself. When I need to share something to family/friends, I still do it the hard way, usually setting up a time-limited FTP/HTTP download, or uploading a home video to my (private) youtube channel.

One easy way to share content from your home is to set up an HTTP server. You can then have links to individual files, optional user/pass authentication, and direct streaming even works for MP4 and some other formats. Just... not integrated into MC.

[zybex]

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").

Those 50Mbps upload are not the norm, by far. I have 500/25 and it's already an expensive service. Most people still have far less, or it's the "up to X" variety. Saturating your UL still kills your DL, unless you have a QoS router that prioritizes ACKs.

I agree though, if you have the upload bandwidth, why not make use of it...

[jmone]

So we already can do all of this with Remotes from outside the LAN.... but you have to have access to the entire library with a Key/Username/Password to gain access.

All I'm suggesting is to use the existing services that already exist but allow the generation of a "public" URL that will allow access to that one item without requiring a log in.  Eg - this is what such a string looks like from Next Cloud : https://behome.dyndns.info/index.php/s/Fxc8GAZWtB2reYK (this is a real video of a red belly black snake at our front door.... we get a few!).  You can see, play, download this one Video but not the rest I have on the server. 

[JimH]

I think this is a good idea.  Remind us from time to time.

[jmone]

I do!

[RoderickGI]

this is a real video of a red belly black snake at our front door.... we get a few!

Red Belly Blacks, not really a worry, unless you have a small dog. I see you do!

I have two Mini Foxies. They are hunters and think they are big dogs. The two most common ways they die are fighting larger dogs and snakebite. 

[jmone]

Yup - no fear at all.  Our little black dog tangled last year with a Red Belly and ended up with Multiple Strikes.  Got her to the Vet within 5 Min, multiple shots of antivenin, blood transfusion and a week in hospital. 

[Matt]

(deleted by Matt now that this is public)

[zybex]

Nice pond

But... that login allows us to access Panel, and via that we can see the entire collection.
Even just changing the File ID number on the URL works - File 24514624 also plays.

The idea is to share a single file at a time, with optional credentials, without giving access to Panel or to any other non-shared item.

You may want to change your access key now.

[zybex]

May I suggest an API for individual file sharing:
/MCWS/v1/Share?token=FileShareToken

- Token is a string encrypted with the server's AccessKey (or other server-defined key), and base64-encoded;
- optionally, the Token can embed an expiration timestamp or other restrictions;
- User can right-click on a File and select "Get Sharing URL", optionally providing an expiration date. MC generates the encrypted URL which can then be shared;
- MCWS API, on receiving the call, just needs to decrypt the token to check validity and extract the FileKey;
- Authentication is optional - but could be defined in Settings as a distinct "Sharing user/pass", or even a list of "user/pass" accounts.

You can make the token string as a JSON object, for instance, to allow for future features:

 Token: {File:24514625, Expiry:1612558645, Flags:0}
Encoded: mfhfiP5H0MMlO9id2YkWKzRFNRFe66lqTzkGvCHDf4gOp11O79k8ezCK
URL: http://73.164.109.246:52199/MCWS/v1/Share?token=mfhfiP5H0MMlO9id2YkWKzRFNRFe66lqTzkGvCHDf4gOp11O79k8ezCK

Flags is optional, up to you... it could for instance indicate if authentication is required or not for this URL.

Additionally, we could have a field called [Shared] (bool) which would become TRUE after sharing. Simply unchecking this field would revoke any existing URL pointing to it (MWCS just needs to check this field before serving the file)

[zybex]

A simpler idea:
- [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.

[kensn]

Nice pond...

Worked for me.

Ken

[JimH]

A simpler idea:
- [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.

I think we need to make it easy to share a file or files with a Share link that uses the standard icon. 

I agree that it needs to show only those files, so it would need to have no login / password necessary OR a different set.

It could also be a separate server.

We're on it though.  This is promising.  It solves a problem I've had for a long time.

[JimH]

Adding what I just said to Matt in email:

Could it add files to a Shared Library and share anything in it with a different Access Key?  Or a [Named] Library so you could have different ones for different people?

[Awesome Donkey]

Shame something like a two-factor authentication system couldn't be used here. Like if an outside user wants to access a shared library from outside the network, it could prompt the user in MC with a allow or deny choice. Which if there's some sort of manager, authentication allowing shared library access could be revoked or something like that.

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.

Just thinking out loud.

[zybex]

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.

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.

MCWS would still need a way to provide access for a given playlist based on login credentials or key.

[zybex]

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.

That would require you to be awake and in front of the PC/phone to authorize each access. I think sharing/revoking must be handled asynchronously - you share something and it becomes available to someone having the key; and you can revoke access at any time.

Using playlists is nice (in my opinion) because you can add/remove stuff from a shared playlist at any point.
Playlist -> RightClick -> Share... -> enter credentials, auto-expiry date, other options; show sharing URL. The icon should change to reflect that it is now shared. After this one-time setup, all you need to do is add/remove files to the playlist.

[wer]

I think it needs to be kept simple.

It seems to me that if you have a single playlist or smartlist named "Public" it will be shared with an optional RO password (separate from the RO MC client password) that would be the best compromise for an initial release.

Additional functionality could always be added later.

[jmone]

I'm pretty excited!  The basics work!!!!
- view/play in a web browser
- Allow for a download (for when the bandwidth is not enough)

Some things:
- MC does need to restrict access to just to the content in the particular link
- I don't want or need a Usr/Pass, just the access to a particular Item in the Library by a random Generated Token
- Needs to be easy to mark an item to be shared, generate a link, copy it to the clipboard, and keep track of the # of plays/downloads.
- Needs to be easy to then remove the link to stop access

More Advanced Stuff:
- Sometime I share a "Folder" of items, eg Family Home Videos where the link is to the group, and they can see a thumnail of all the content, be able to navigate to particular items, play, download etc...
- There is also a "Download All" or "Play All" option

Love it!

Thanks
Nathan

[jmone]

Nice Pond!

[Matt]

OK, changed my access key and turned off read-only!  Thanks for looking everyone.

[jmone]

I did not snoop!  ... but good idea.

Also, you may need an set of Conversion Options (like with MCWS) given there will be different bandwidth environments
- Video (For Playback) --> Auto FPS / Safe Web Playable / 25Mbps
- Video (For Download) --> No Conversion
etc

[JimH]

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.

I might want to share single files (a movie) or playlists (trip pictures).  We need to handle both.

[zybex]

I meant that we would just create a new playlist for each person that we want to share things with. Then we would just drag stuff into it, be that just one file or 100 files.
These playlists could be under a "Shared Playlists" group, to clearly separate them from the other regular ones. This would make management trivial, using all the already existing playlist functionality.

[JimH]

A single playlist works for the first set, but what happens if you want to share files on a different subject?  Trip 1, 2 ,3, ...  I'd like to have multiple sets I share with multiple people.

[zybex]

Then share at the PlayList Group level; all playlists inside would be shared according to the Group's sharing settings.
The sharing settings could exist at the Group level only, or alternatively they could be inherited and overridden at the playlist level too.

To support multiple people, either create a group or playlist for each one (with different account/key for each), or provide options to add multiple accounts/keys to each shared playlist/group.

[marko]

Bo-oooooo-b....

Expanding upon this...

If this single-file-sharing becomes a thing, what are the chances of having JRemote for IOS hook into the iPhone sharing system?

I'm out and about most of the day with JRemote playing some choice random smartlists (one usually does me all week) and you know when a track arrives and it instantly takes you back to that great gig, and you want to share it with the folks that were there with you that night...

If JRemote had a "Share" icon there, that generated the required link, it could be sent via whatsapp, email text or whatever, to whoever... This would be brilliant.

The memories these tracks spark are even more so poignant in these locked down times we currently live in.

Do-able?

[Matt]

Tonight's build can provide a sharing URL.  Authentication is not needed for that function any longer.

Let us know!

[jmone]

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).

Thanks!  Here is what I've found in a quick test
- It seems to just use the FileKey instead of a token, so it opens up your entire library to be randomly downloaded! - I can manually plug in any FileKey and the link has access.
- It seems to play many file types in the Web Page just fine (only tested some Video and Audio), but file type that are not supported seem to be automatically downloaded to your PC instead of bringing up the Web IF.  So MP4 works (as expected) but other Video File Types seem to trigger the autodownload.  This is where I think it will make sense for an option that MC use (a selectable) Transcode profile to get a web safe stream working.
- This Transcode option would also make compound content (DVD, BD's) etc work, as at present you just get the index file downloaded.

So as step 1, It Works!  and Works Well! ... but I'd suggest
Step 2: Change the access method as else your entire library is open to anyone by just using any old FileKey in the URL.  Seems like a massive security hole in this version!
Step X: Refine the other things....

[Matt]

I suppose we could base it on a user enterable share ID?  Maybe it uses a string of random characters if it's empty?

[zybex]

I proposed a secure solution above, using JSON.

[jmone]

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)
- Another new DB Field (Number Plays - External) should record the # of play using the external link so you can See when someone has played it.  This would also let you see what media has been accessed with a smart list.

[Matt]

Maybe we require auth for the current get file call but make a new share call that doesn't that takes a user entered field.  If you didn't enter that field value, nothing would be shared.

[jmone]

6. Changed: MCWS no longer requires authentication for functions marked to not require authentication.

This also scares me.  What functions don't require authorisation?  For example, does that mean if I have Matt's external MC IP address I can now do all sorts of stuff remotely without authorisation?  Even simple stuff like start MC Playing content at 2am?

[wer]

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)

I understand jmone's sentiment, but I think this is an overcomplicated way of stating what the user's POV requires.

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

Tokens/fields/etc don't enter into their actual needs, so how MC does this behind the scenes shouldn't impact the user.

[jmone]

I really think it needs a separate token method rather than using the filekey to gain access, otherwise this loop will give access to anyone to all items marked as shared in no time at all:

Loop
 http://xxx.xxx.xxx.xxx:xxx/MCWS/v1/File/GetFile?File=%Index%&FileType=Key

edit - updated my wording as I agree with wer it is up to JR on the "How"

[zybex]

MC just needs to encrypt the FileKey in the URL using an encryption key generated by the current server/install. If the user changes anything on the encrypted string, it won't decode anymore.

From the user PoV, it's clear - a simple right-click->Share is all that is needed (though I think it's useful to share playlists as well as individual files).
What we're discussing is implementation.

[jmone]

That would work (as long as the std GetFile then went back to requiring Authorisation).

[Matt]

The problem is that opening up GetFile let's you snoop.  If we close that but add a new share function, it could only share what you've told it to.

[Matt]

Using an encrypted file key might be clever because then you wouldn't have to enter anything.  It would have everything open for sharing but it would be impossible to guess a key.

[jmone]

Works for me!  So are you thinking something like:
- GetFile:  Goes back to using Authentication
- GetFileEnc: No Authentication but uses an Encrypted Key

[zybex]

I proposed above using a new /Share URL endpoint, I think that would be safer and allow for future expansion.
The Key encryption scheme could be something like this (RC4+Base64) - this was what I used above too. The "output" is the token to be included in the URL, the "input" is the decoded data that points to the shared filekey.

There's no way to guess any valid token by changing the encoded data, it would break the RC4. You can use AES instead if you prefer, or anything else really.

[jmone]

While discussing how all this could work...I also agree that being able to share a playlist or group of items makes sense and is easier eg:
Home Videos (a link for the familly)
Our Trip to Someplace (a link to those we went on the trip to)
etc etc

[Hendrik]

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

I agree with those requirements. And I think its important to note that these should be the absolute minimum requirements to have control over sharing, and not a distant goal. Anything less then that should not even be made available as a half-baked version can compromise your data.

Once we have a safe way to share single files, then we can think about sharing playlists or other logical structures, so I would suggest to leave playlists etc out of the discussion until the fundamentals are solved.

[lepa]

What wer and Hendrik said above

[JimH]

Matt,
Just use "Share" instead of "Get URL ..."

Generate two URL's.  One for inside the network.  One for outside.

It has to work for a set of files.

Security first.

Google Drive's sharing would be worth looking at for ideas.