Print

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

[HTPC4ME]

I've been troubleshooting jriver on pc's, cellphones, and friends via facebook over lan, and on outside networks for the last 2 hours
none of us could connect to our libraries, NOR the forum here. 

1. Why are our libraries lost when your site is down?! if our lan works, our libraries should continue to work! now we have lost all of our scheduled recordings!
2. don't we at least deserve an email stating you guys are down, and all of our files will not be accessible via clients?!
3. with the government/nsa BS we are all aware of now... by all of us having to connect to jriver, what assurance do your users have that our files/ PERSONAL FILES are safe?! Let it be noted that my wife's nude files are not your, or anyone's else's business.
4. does anyone at JRiver monitor facebook? ( this would be a perfect alternative for keeping your users posted. not to mention it may be a good idea to look through the posts that are already there... there are quite a few unanswered posts from users experiencing other problems.)

[mwillems]

I've been troubleshooting jriver on pc's, cellphones, and friends via facebook over lan, and on outside networks for the last 2 hours
none of us could connect to our libraries, NOR the forum here.  

1. Why are our libraries lost when your site is down?! if our lan works, our libraries should continue to work! now we have lost all of our scheduled recordings!
2. don't we at least deserve an email stating you guys are down, and all of our files will not be accessible via clients?!
3. with the government/nsa BS we are all aware of now... by all of us having to connect to jriver, what assurance do your users have that our files/ PERSONAL FILES are safe?! Let it be noted that my wife's nude files are not your, or anyone's else's business.
4. does anyone at JRiver monitor facebook? ( this would be a perfect alternative for keeping your users posted. not to mention it may be a good idea to look through the posts that are already there... there are quite a few unanswered posts from users experiencing other problems.)

I'm not an expert on how this all works, but my understanding is that it's just the access keys that are kept on JRiver's servers.  When you go to log into a server from a client with an access key, it just looks up the access key on JRiver's servers.  If you configure your clients to use local network addresses instead of access keys, you can get lan connectivity without connecting to JRiver's servers.  At least that's what I think the deal is.  

[HTPC4ME]

if there is an alternative... stellar, i would love steps on how to accomplish this. (thanks in advance)
not to complain but i consider myself some what savy here...
How bout noobs? shouldnt having access to your lan be a default?

[glynor]

You can, if you set it up that way.

The Access Keys make it easier, and don't require knowledge of how IP addressing works, but you trade it for requiring:

1. Internet access on both the client and server.
2. JRiver's servers must be up.

[mwillems]

if there is an alternative... stellar, i would love steps on how to accomplish this. (thanks in advance)
not to complain but i consider myself some what savy here...
How bout noobs? shouldnt having access to your lan be a default?

I'd be interested myself in some more explicit directions on setting up the alternative; I've tried to do direct IP connections in JRiver in the past (for exactly this reason), but couldn't seem to get them working within the LAN when the internet was down.  I don't ever access my network from outside the LAN, so I really just need a way to get everything within the LAN talking when my internet is down (or JRiver's is)

But what I know about networking PCs is left over from the middle 90's and could've fit inside a thimble even then.  Maybe Glynor could offer a few tips?  I kind of dead-ended when the info I pulled from ipconfig didn't seem to work, and I couldn't find a way to ascertain which port was being used.

EDIT: I figured it out, you can choose which port to set under media network, so instead of an access key on the client, just enter the server's IP address from ipconfig followed by a colon and the port you have set on the server.

So the steps if you only need LAN access are:

1) run ipconfig on the server, write down the ip address
2) mark down which port you have set on the server under options.
3) On the client, instead of the access key for a library, enter "[ip address from 1)]:[port number from 2]" with brackets removed, obviously.

If you need access from outside the LAN, I suspect that might be more complicated especially if you don't have a static outward facing IP.

[glynor]

I've explained it before.

Pretty much, put in your IP address and port, instead of the access key, in the format:
<IP_ADDRESS>:<PORT>

So, if your server is running at 192.168.0.5 and the port is 52199 (the default) then you'd put:
192.168.0.5:52199

I explained some port configuration details here just recently:
http://yabb.jriver.com/interact/index.php?topic=88071.msg603676#msg603676

And, assuming the address of the server is reachable from the client (within the same subnet, typically), it'll connect.  If the internal IP address of the server changes, you'll have to modify the entry.  If you don't want it to change, and it does all the time (as might happen if you shut it down often and leave it off, or if your gateway is a PITA) you'll have to configure the server computer to use a static IP.  Depending on your network setup and gateway capabilities, you can do this either via:

1. Setting the router/gateway to assign a particular address to the server via DHCP whenever it sees the computer connect (typically via the server's MAC address).
2. Configuring the server itself to use a static IP address instead of a dynamically assigned (DHCP) address, which is done on the computer itself from within Windows.

If you are only ever using it within your LAN, then that's all you need to do (you don't have to worry about Port Forwarding on your router for use on your internal LAN.

[glynor]

If you don't know how to:

1. Figure out what your current internal IP address is
2. Assign a static IP from within Windows
3. Other stuff like that

Then I'd suggest The Googles.

This is very individual depending on the setup of and capabilities of your local network.  If it works with an Access Key, though, then it IS reachable (not blocked by a firewall or anything) so you just need to put in the proper IP and port.

[mwillems]

I've explained it before.

Pretty much, put in your IP address and port, instead of the access key, in the format:
<IP_ADDRESS>:<PORT>

So, if your server is running at 192.168.0.5 and the port is 52199 (the default) then you'd put:
192.168.0.5:52199

I explained some port configuration details here just recently:
http://yabb.jriver.com/interact/index.php?topic=88071.msg603676#msg603676

And, assuming the address of the server is reachable from the client (within the same subnet, typically), it'll connect.  If the internal IP address of the server changes, you'll have to modify the entry.  If you don't want it to change, and it does all the time (as might happen if you shut it down often and leave it off, or if your gateway is a PITA) you'll have to configure the server computer to use a static IP.  Depending on your network setup and gateway capabilities, you can do this either via:

1. Setting the router/gateway to assign a particular address to the server via DHCP whenever it sees the computer connect (typically via the server's MAC address).
2. Configuring the server itself to use a static IP address instead of a dynamically assigned (DHCP) address, which is done on the computer itself from within Windows.

If you are only ever using it within your LAN, then that's all you need to do (you don't have to worry about Port Forwarding on your router for use on your internal LAN.

Thanks for the detail, I figured you'd posted it somewhere before, but I couldn't turn it up immediately on the wiki or the forum.  

I appreciate you taking the time.

[glynor]

1) run ipconfig on the server, write down the ip address

You can copypasta out of the CMD box.

[mwillems]

You can copypasta out of the CMD box.

Whoa!  That's some ninja stuff.  Thanks buckets, I still treat the command prompt like a DOS prompt; I had no idea  

[HTPC4ME]

http://yabb.jriver.com/interact/index.php?topic=88071.msg603676#msg603676

am i understanding this correctly?

if at home, one must set up static ip's and ports to access jriver library (if one does not want to use access keys/ be self sufficient.)

if away from home. one would have to enter in external static ip's? would no-ip.com work for this? (i'm already subscribed to them for remote assistance support with relatives)

Now, when all tablets, cellphones, laptops leave the home each user would have to KNOW that they are not in home network, and would have to manually enter in the external static ip. If so, here's where i believe the "kicker" WILL come in... once each user comes home they would have to remember that each tablet, cellphone, laptop device NEEDS to be disconnected from the external static, and then they must login with internal static ip/port number? Failing to do this basically brings your chances of going over your ISP bandwidth usage caps dangerously high. (when at home is when most people will use jriver the most) In our household JRiver is being used literally 24/7 some people work nights here, others days. sooo if all users accidentally did not connect to correct static. in ummm 3 days we would be over the 250GB cap. (honestly no clue how long it would take, but i doubt this household would last for 30 days if accessing library outside home network/lan)

Not all of us walk around with Excel to do list's and read them when we get home...
1. Feed fish
2. unpack
3. disconnect your cellphone(work & personal), laptop, tablet, smart watch, blah blah from jriver libraries.
4. connect all devices you took away from home to internal ip's for jriver libraries.
5. relax

I hope I'm misunderstanding this?
if so, pardon my ignorance and please elaborate.
if not... wouldn't each server remembering access keys LOCALLY be the safer alternative?
Thanks

[6233638]

Well this might explain why I was having trouble getting one of my clients to connect recently.
It would be good if you could set an optional "fallback" IP when using an access key for when there's no WAN access or the JRiver servers go down.

[MrC]

Get yourself a domain name with a service that provides DDNS.  You will point some A record to your dynamic entry, such ad home.mydomain.com.

At home, set up a DNS server with a similar A record, but this one points to your server's LAN address.

Configure all your systems to connect to that FQDN.  When you are away, external DNS servers will yield your dynamic WAN address.  When you are home, your DNS servers provide a LAN address.

You'll need to configure your firewall to port forward to you server.

[dean70]

... or MC could cache the last known local ip address to use as a fall-back.

[glynor]

Get yourself a domain name with a service that provides DDNS.  You will point some A record to your dynamic entry, such ad home.mydomain.com.

At home, set up a DNS server with a similar A record, but this one points to your server's LAN address.

Configure all your systems to connect to that FQDN.  When you are away, external DNS servers will yield your dynamic WAN address.  When you are home, your DNS servers provide a LAN address.

You'll need to configure your firewall to port forward to you server.

You don't need a local DNS server, you can do it with your hosts file.  Or, get a real gateway that can do full NAT Port Forwarding, which is what I do.  But, otherwise, yes.  I don't use access keys at all, because I have a dyn account and a decent gateway.

But that mostly addresses access from outside the LAN, which wasn't the original question.

If you have an always on server on your LAN, it probably makes sense to assign it a static IP address on your LAN.  With a typical consumer router, if you do want external access at all, you'll have to anyway in order to set up the port forwarding.  But it isn't hard to do.  It'll take seconds for most people to accomplish, if you only have one server.  The clients, of course, don't need static addresses, just the server.

So, the simplest solution is to just set up two entries in Gizmo, JRemote, MC's Library Manager, or whatever. One, that you typically use, with the Access Key, and a backup with the static internal IP of your server.  That won't save you for external access if something bad happens to connectivity, but you could always get to it locally if needed.

Any alternative for external access  to this that is practical with a typical home DHCP assigned WAN address internet connection, will require a service like dyn or noip (which, by the way, just transfers he "downtime" risk to a different company).  JRiver's Access Key system is a kind of dynamic IP resolving system, it just doesn't use DNS, and has some special sauce to eliminate the need to set up Full NAT firewall rules (or use hosts file trickery).

But let's be frank, if you do lose access to your Access Key, it is probably far more likely to be due to an outage at your house (on a residential Internet connection) than JRiver being down.  That did just happen of course, so the memory is fresh.  But you all never noticed this before because it is pretty rare.

If your home connection is down, then no amount of dynamic DNS trickery would have saved you for external access because your Internet is down.  That's why I'd say the simplest solution is to just add that backup version for LAN use (if you can't remember the address and port number to enter it then, should it ever happen).

The biggest problem would be if you're using multiple servers.  I imagine the most common use case would be for remote control over a variety of HTPC's in a house (in addition to a main Library Server, I suppose).  If you have this kind of setup, and especially if Gizmo or JRemote are the sole controllers for the systems, then I'd recommend a more advanced Network setup anyway, just to manage it, if for nothing else.

[glynor]

... or MC could cache the last known local ip address to use as a fall-back.

This would be nice.  I thought it did do some amount of caching, at least server-side, but I don't know the details.  As I said, I don't use Access Keys.  Someone else will have to comment.

I can explain more details on an advanced setup if people want, but not tonight, I'm tired.

[6233638]

... or MC could cache the last known local ip address to use as a fall-back.

That's probably an even better suggestion than mine - or you could go one step further and include all three.
 
1. Lookup access key
2. Try last-known IP if lookup fails
3. Try fallback IP if last-known IP fails
 
 
A scenario where this might occur: I take my tablet with me to a friends' place and play some music there.
I arrive home and my internet connection is down. Both #1 and #2 will fail, but the fixed local IP fallback should continue to work.
 
#2 would work if the JRiver servers or my internet connection goes down, but the last time I connected was on my local network.
 
 
This is by far the most transparent and easiest solution for users rather than the complicated* workarounds being suggested.
 
 
*You may not think so because you're used to dealing with that sort of thing. It's unreasonable to expect a normal user to understand this.

[glynor]

PS.  I have no idea what you're going on about with your data caps worrying above, but that's not relevant.

Access to your server inside your LAN cannot use your "public" Internet service (unless the users turn off their WiFi for some reason, I suppose, but this wouldn't help, and wouldn't happen automatically).  If their WiFi is on, and they're connected to your network, and they try to connect to your WAN address, it'll just fail because that's not how Port Forwarding works.  It can't work right.

You must have a system to direct the request to an internal address when you are internal, and an external address when you are external.  That's what the Access Key system does for you.  It responds differently depending on if it thinks the requesting device is on the LAN, or off the LAN.  If you don't want to rely on theirs, yes, you need to either:

1. Set up your own automatic system, most likely a local DNS based, Hosts file based, or Full NAT based system.
2. Do it manually.

Those are the only options.  Welcome to the Internet.

It sounds like you have some fundamental misunderstandings of how Network access works.  I'd recommend reading up on Port Forwarding,

[glynor]

This is by far the most transparent and easiest solution for users rather than the complicated* workarounds being suggested.

*You may not think so because you're used to dealing with that sort of thing. It's unreasonable to expect a normal user to understand this.

I agree that some kind of simple client-side caching scheme for Access Keys would be nice.

On the other hand, I think maybe this is blowing it a bit out of proportion.  If this was happening every week or something, it'd be different, but generally I think the servers are pretty stable.

In any networking endeavor, the higher level of reliability you want, the more effort you'll need to expend.  The Access Key system is super simple and handles the complexities of the system quite well for a wide swath of users.  But if you demand high reliability and zero downtime... Well, you ain't paying for them to do it for you, frankly, so roll up your sleeves, or pay someone.

But I don't think the mythical "average user" gets to demand zero downtime and high reliability.  Sorry.  No other consumer services work that way.  Crap goes down sometimes, if you don't pay for it never to.  With MC, you can set it up so it is highly reliable, for modest pricing, with pretty basic systems used by a wide variety of software applications (like Remote Desktop software).  There ARE well understood systems for handling these issues, they just made something so much easier (already) that you never noticed it was so complex behind the scenes.

Mine would never go down in a situation like this, but I worked hard on it.  (For example, even if my WAN goes down, I have a fallback cellular WAN now and my router automatically switches to it.). But my system requires knowledge, hardware, equipment, and service plans.  I spend a couple hundred bucks a year on it.

[glynor]

I thought it did do some amount of caching, at least server-side, but I don't know the details.  As I said, I don't use Access Keys.  Someone else will have to comment.

I remember more now... It does do server-side caching, in some way.  I don't remember all the details (I didn't pay attention that much since I don't use Access Keys), but I think it is something like JRiver's servers keep the last LAN and WAN addresses it got from your server for 24 hours from the last request, or something like that.   Someone can look up the threads if you want, but there were, I know discussions around this a while back.

That doesn't, of course, help if the servers are down.

Client side caching would have to be implemented by each client, individually.  So, lespaul could implement it for JRemote if he wants to now (it doesn't require anything from JRiver to do so), but it would need to be client-side to be useful, so they'd each need to have their own system for doing it.  And web-access, of course, can't do this, so you have to "do it right" in those cases.

And, like I said, setting up a Dynamic DNS address is just transferring the "risk" to a different company.  Especially with the free dyndns services, they don't usually have much in the way of uptime guarantees.  dyn.com has been quite good for me, but they've had outages too, and scheduled maintenance, and stuff, and I have a premium-tier paid account.  I don't know if it is more or less than JRiver, but not by orders of magnitude in either direction, for sure.

I still think for most users, with what we have now, the simplest solution is to add a backup entry to the Library Manager and your Gizmo/JRemote server setup, for LAN access should the Access Key system crap out on you for whatever reason.  If all the different remote and client vendors add client-side caching to their individual products, so much the better.  It still might not save you if you just leave everything dynamic and auto-configured on your router at home, though (if your server loses its lease as part of the same event that caused the outage, then you're still stuck).

I don't know... Meh.  How high is it on the overall importance scale of things we'd like to see improved in MC?  Dunno.  

I don't know how many story points of my own pet projects I'd give up for it...  

[6233638]

On the other hand, I think maybe this is blowing it a bit out of proportion.  If this was happening every week or something, it'd be different, but generally I think the servers are pretty stable.

It's unfortunate timing, as my internet connection was down for a few hours yesterday, and then today the JRiver servers went down.
If changes are made to improve reliability, I'd rather they went all the way.

But I don't think the mythical "average user" gets to demand zero downtime and high reliability.  Sorry.  No other consumer services work that way.  Crap goes down sometimes, if you don't pay for it never to.

I'm not suggesting that at all - I'm suggesting that the program be built to account for either JRiver server downtime, or my own connection having problems. (it's less reliable than I'd like, but I don't have any other options here)
 

I still think for most users, with what we have now, the simplest solution is to add a backup entry to the Library Manager and your Gizmo/JRemote server setup, for LAN access should the Access Key system crap out on you for whatever reason.  If all the different remote and client vendors add client-side caching to their individual products, so much the better.  It still might not save you if you just leave everything dynamic and auto-configured on your router at home, though (if your server loses its lease as part of the same event that caused the outage, then you're still stuck).

I don't know... Meh.  How high is it on the overall importance scale of things we'd like to see improved in MC?  Dunno.  

Right now, I mostly just use Media Center on one PC - but I do occasionally use the Mac clients here, and I am planning on buying another machine purely to use as a Media Center client.
If my internet connection goes down, that's probably when I am most likely to want to switch over to one of the other clients.
I couldn't connect yesterday when my ISP was down and I assumed it was this problem again. In fact, the problem there may have been related to internet connectivity and nothing to do with the version of Media Center I was running. Sometimes the connection is only down for a few minutes so I may not have even noticed it.
 
So I definitely want things to continue working if the JRiver servers are having problems or my ISP goes down, without having to change my configuration on client devices.

[glynor]

So I definitely want things to continue working if the JRiver servers are having problems or my ISP goes down, without having to change my configuration on client devices.

Right, but you're no average user.  You're a power user.  Set it up right, and it won't be just a little more reliable in certain conditions, but it'll actually be... You know, reliable.  

I'll explain how tomorrow or at some point over the weekend, and maybe add stuff to the Wiki.  It isn't that hard.

Like I said... I'm not disagreeing.  As I said, it's a good idea.  Client-side Access Key caching (I think just the most recently known WAN and LAN addresses would suffice) would be sweet.  I'd give it a thumbs up.  I do, however, think that... Well, for example:

If you really want to spend time on the system to make it easier for "regular people", I think it would be much better spent on eliminating the need for people to have to do port forwarding at all, even for outside-the-LAN access.*  That's a bigger pain-point, in my estimation.  (And admittedly a bigger project, for sure, though there are the complexities of all the various clients for caching, some of which they don't control, so it might not be a super-simple thing.)  But that can be done.  TeamViewer does it.  GoodSync does it.  Plenty of things like that do.  But that would make users of the system even more reliant on the JRiver servers (as they'd have to be able to negotiate the firewall traversal), not less.

So... I don't know.  It's not my call, but it's a balancing act.

As I said... I'll try to explain some options for alternative setups to Access Keys at some point soon, and we can try to clean up the Media Network section of the Wiki (which is a disaster currently).  That's what I can do to help.

* And I'd much rather see MCWS be SSL.

[6233638]

I think just the most recently known WAN and LAN addresses would suffice

Caching both would work - I was only thinking "last IP" when caching was being mentioned.

[jmone]

FYI - MC Library Server Clients do this now.  I use the Key and have seen that if my server is down they will then attempt the last used connections including IP addies. 

[glynor]

Caching both would work - I was only thinking "last IP" when caching was being mentioned.

Nah, why not cache both?  JRiver's servers respond with both, anyway.

You can look at it easily:
http://webplay.jriver.com/libraryserver/lookup?id=<YOUR ACCESS KEY HERE>

But, I mean, the MC client itself does auto-detection anyway, so if it fails and you're at home, it'll see the servers on the network anyway so you can still connect... We're mostly talking mobile clients, right?

[glynor]

FYI - MC Library Server Clients do this now.  I use the Key and have seen that if my server is down they will then attempt the last used connections including IP addies.  

Yeah, I thought so...  I know there were discussions around this.  I should look but I'm on my iPad and lazy.

[6233638]

Nah, why not cache both?  JRiver's servers respond with both, anyway, I'm pretty sure

I wasn't suggesting otherwise - I meant that when people suggested it cache the "last IP" I was thinking the last one used, not the last WAN and LAN IPs. (which is obviously better)
 

FYI - MC Library Server Clients do this now.  I use the Key and have seen that if my server is down they will then attempt the last used connections including IP addies.

So is the issue only to do with Gizmo or other mobile clients then? (I guess something else was causing the connection problems on my Macs)

[glynor]

So is the issue only to do with Gizmo or other mobile clients then? (I guess something else was causing the connection problems on my Macs)

Yeah, and even if not, all you have to do is load some other default local library (which it forces you to keep one of), and from within MC it'll auto detect other servers on your subnet and put them in the Library Manager under Playing Now.

There are a couple other people at my office who use MC I think, because I've seen two other servers randomly in there as I'm walking around with my laptop and changing subnets.  They have passwords, or I'd have checked out their libraries.  I don't know who they are, though I think I might know one of them based on the server name.  

JRemote and Gizmo could auto-detect too.  MCWS advertises itself on the same port via UDP broadcast.

[csimon]

JRemote allows you to connect via IP address but I don't think Gizmo does [it does -- edit by JimH], which means Gizmo is out of action if JRiver's servers are down.  I had a similar problem a few days ago, I suspect my broadband was down or had got stuck (it's a very bad service here) and Gizmo wouldn't connect.  JRemote was fine becuase I haven't set that up with an Access Key.  I think the Access Key method should not be promoted and pushed so much on installation and enabling Media Network and in advice given on how to set things up, and Gizmo should at least offer the choice.

If it falls back to last known IP address then either this is not working or it's very very slow to recognise the situation.

[Hendrik]

Gizmo also allows connecting via IP, and Gizmo also caches the last IP it resolved from an access key.
MC itself may not cache the last known/working IP for an access key right now, but that shouldn't be too hard to add.

Edit:
And so it will in the next build.

[TCube]

Hello,

Very interesting topic and lots of interesting ideas  I though it was most intriguing the way MC JRiver works.

So here it is roughly :

I have a Pc with 2 home servers installed (1 running Php the other with running a single exe. in Delphi).
They both have specific address DynDNs/No-ip.
Basically then all the set ups are 'bout User/Rights/Libraries/Access/Download and Upload are easier to configure from one PC.
This PC is connected on Ethernet/FTTLA with 5Mb/s upload and will go for FTTH with 50Mb/s upload this year.

Once I get an added FTTH new connexion on top of FTTLA (reserved for 100Mb/s dl for TV) i thought I would may be able to reach SmartPhones on the run just for listening purposes.

In spite of this, fondling with it on FTTLA , I noticed few hiccups.

- No need to use an access Key : it's a waist of time asking MC to resolve the Dynamic Address every time some one tries to connect in 3G/4G broadband.
- If the purpose is sharing/listening tracks, and mind you not pictures and movies for the time being, I'm not getting the hang of it as how to separate these libraries with a single out going IP.
- Few things are left aside ... like if I'm on WIFI with my personal PC running at home how goes it get with MC (obviously no right management so I would have to set up ... an other MC instance running somewhere and would the switch fro one server to the other be automatic ?).

I reckon the original question was asked 'bout FB connexion, still, as I said this topic raises interesting features. A MUST READ. Many thanks.

[glynor]

Edit:
And so it will in the next build.

Awesome! Glad it was an easy change.

I just hedged a bit because I know all to well that often it is the things that "seem easy" to the customers that cause all sorts of headaches.

[Ekpen]

Gizmo also allows connecting via IP, and Gizmo also caches the last IP it resolved from an access key.
MC itself may not cache the last known/working IP for an access key right now, but that shouldn't be too hard to add.

Edit:
And so it will in the next build.

Greetings:

While I have port forwarding properly configured, I think, it is a good idea for Gizmo or within media network config to have internal and or public IPs configured somewhere. The exact place I do not know. The Gizmo should just have an option to connect using a given IP or choice of IPs already detected. This is just my thought, it may fit or may not fit.
My past connection issues are mostly related to my ISP issues. I have more than 30 trouble tickets within 4 months . My  ISP may fail again. I do not trust their services.

Also the issue or problem with PC sleeping and waking up to requests should also be looked into.

P S.. for those who need help doing port forwarding, looking into utilities like Port forward suite of utilities (PFconfig) etc on the net.
Thanks all.

George

[magnust]

I set up OpenVPN at home. Then I run a VPN from my android phone (and from my laptop... and country house subnet and...) and then connect to MC19 running at home. A blast having ALL my music available while driving in my car and everywhere else!!


Since I connect with a VPN I always connect to MC19 on the exact same IP number regardless where I am. And regardless if it's from within Gizmo or MC.



But the lookup key is still a great way of doing it. And even better with some caching  

[glynor]

3. with the government/nsa BS we are all aware of now... by all of us having to connect to jriver, what assurance do your users have that our files/ PERSONAL FILES are safe?! Let it be noted that my wife's nude files are not your, or anyone's else's business.

I'd like to address this one question, as it didn't get addressed elsewhere.

JRiver does NOT have access to your Library itself, via this system.  The Access Key ONLY enables the client to make a direct connection to the Library running on your machine.  Your files are your files, and the data exchanged between the Library and Client does NOT go through JRiver's servers.  Only the initial request to connect to the server, and then, only if you are using an Access Key to connect.

As I mentioned above, if you want to see what "information" JRiver has about your server, you just need to visit this web page:
http://webplay.jriver.com/libraryserver/lookup?id=<YOUR ACCESS KEY HERE>

It is just a list of IPv4 (and IPv6 if that's enabled on your server machine) addresses that your server has been using lately, along with the port number MC is using.  In fact, no other information about your server is transmitted or stored at all by JRiver.  It doesn't even link a server name or anything else to the Access Key (so they're somewhat anonymous).  It is a dynamic address translation system only.  Once the client gets the IP addresses returned from the address listed above, then it makes the Library connection itself directly to your server.

I just wanted to make that clear.

[6233638]

To (hopefully) make things even clearer, the "Access Key" does not provide access to your library.
It is only used to perform an IP address lookup so that clients are able to locate and connect to your PC.
 
Access to your library is controlled by the username and password that can be set in Tools > Options > Media Network > Authentication
And this can only be accessed outside of your internal network if you have forwarded the specific ports on your router to do so.
 
 
I was mistaken in thinking that the "Access Key" was something more than simply a unique identifier for the IP lookup, and was a key used to access your library. (you can see why I might have had that idea though)

[TCube]

@ Glynor

I'd like to address this one question, as it didn't get addressed elsewhere.

I understand you perfectly.
Still Xtacbyme is right in his intentions : if you wished to "share" but "not share all" - even as read only - how would you proceed as there is no "access right management"  within MC19 ?
The least I can think of, with no much troubles, would be to add one private "PSWD".
I don't mean an PSWD within files within a librarie, but a PSWD to excluded one librairie from other libraries for instance "Music"  would be public  "Videos" / "Pictures" would require a PSWD. This added "Access Right" in my knowledge would be effective simply from "physical location". My two cents contribution but that's the way I manage sharing repertories within physical locations with my home servers and it works wonder.

TC

[JimH]

This should help:

19.0.124 (3/25/2014)
4. Changed: MC will remember the last valid IP for an Access Key, in case the Access Key WebService is unreachable.

[HTPC4ME]

TY Jim/JRiver