Print

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

[AndyU]

When you transfer a library from one machine to another, the Media Network Access Key gets transferred along with it which meant, in many case, that  JRemote couldn't connect and I was nonplussed until I realised what had happened and got a new access code.

Not quite sure what the fix is - possibly change the access code to the one that belongs to the machine which the library is being transferred to, or warn the user, whatever, just something to reduce the chances of a mystified or frustrated user.

[RoderickGI]

Not quite sure what the fix is

If you had waited a little while, the existing Access Key would have been updated with the internal IP Address for the PC you transferred the library to.

Normally the address is checked when you start the MC Server, so I would have expected if you restored the backup to the new PC, closed the MC Client and Server components, or rebooted the PC, then the Access Key would have been updated and everything would have worked. If you just started the MC Server, restored the backup, and then tried to connect JRemote, MC wouldn't have had a chance to update the Access Key.

Of course if you were just moving MC from an old PC to a new PC, you could have given the new PC the IP Address the old PC used to have, and then it would have worked first time. But whether that was practical depends on what you were actually doing with the old and new PC.

[AndyU]

If you had waited a little while, the existing Access Key would have been updated with the internal IP Address for the PC you transferred the library to.

Normally the address is checked when you start the MC Server, so I would have expected if you restored the backup to the new PC, closed the MC Client and Server components, or rebooted the PC, then the Access Key would have been updated and everything would have worked. If you just started the MC Server, restored the backup, and then tried to connect JRemote, MC wouldn't have had a chance to update the Access Key.

Of course if you were just moving MC from an old PC to a new PC, you could have given the new PC the IP Address the old PC used to have, and then it would have worked first time. But whether that was practical depends on what you were actually doing with the old and new PC.

Thanks! I can't remember exactly now but I'm pretty sure there were several hours between when I transferred the library and then tried JRemote. Had it happened immediately I would have more quickly twigged the connection. And moreover I'm also pretty sure I tried killing and restarting JRemote several times over a few hours before it occurred to me to check the access key. Have to say that I have now sadly got resigned to JRemote frequently losing connection and needing restarted, so I find myself using it less.

PS. And thinking about it some more .. your answer kinda proves my point, and my suggestion still stands. How was I supposed to know that I should have "waited a little while"? What would "a little while" have been? How was I supposed to know that I should have "closed the MC Client and Server components, or rebooted the PC"?

Can you think of a more convivial way for MC to behave such that this annoyance is not experienced by other users in the future?

[RoderickGI]

Can you think of a more convivial way for MC to behave such that this annoyance is not experienced by other users in the future?

I'm sure the developers could add in a check after restoring a backup to see if the IP Address has changed and immediately update the Access Key details . . . but what you were doing isn't a common thing for users to do, so that probably wouldn't be high on the priority list for them. But that is entirely up to the developers.

Just FYI, for use in the future perhaps, you can check the IP Addresses associated with your Access Key using the following URL:
http://wr.jriver.com/libraryserver/lookup/[Access Key]

where [Access Key] is your seven character Access Key. Check it now and then save the URL to your favourites. I find it handy.

[Arindelle]

When you transfer a library from one machine to another, the Media [url=http://wiki.jriver.com/index.php/Network_Access]Network Access[/url] Key gets transferred along with it which meant, in many case, that  JRemote couldn't connect and I was nonplussed until I realised what had happened and got a new access code.

Not quite sure what the fix is - possibly change the access code to the one that belongs to the machine which the library is being transferred to, or warn the user, whatever, just something to reduce the chances of a mystified or frustrated user.

I know we are not supposed to vote on these, but as I have a minor problem with this too for a different reason, I'll add to the request for a different reason. AndyU is talking about the IP address, so ok Roderick explained how this can get sorted. I have used in the past (actually pretty recently setting up my son's system again), restores of my library to friends or family member's machine ... so all of my views, custom fields etc. are instantly ported over saving a great deal of time. Just nuke the local library afterwards.

The issue is not the IP address, but the access key itself becomes their key as well as mine. Short of editing the registry of their machines, I don't see how else to avoid this - as I would not want my license or key info spread around even among family members. Can cause headaches with machine's remote access.

The quick fix for me would just be to just NOT back up the access key info. This would also solve AndyU's suggestion, wouldn't it?. Just have to manually retype the key on the clients. As a key would be generated (or regenerated) server side.  Or am I missing something?

[Hendrik]

I split this out of the Too Easy thread, as it clearly requires discussion and is no clear and simple improvement.

[leezer3]

Wouldn't the simple answer be to tie the access key to the machine's hardware ID?

If the hardware ID changes, new key.

Use the same method as licence validation, and you  probably don't even need much code.. 

-Leezer-

[Arindelle]

I split this out of the Too Easy thread, as it clearly requires discussion and is no clear and simple improvement.

sorry Hendrik .. I just though it was worth mentioning. I should have posted a new thread myself.

[Hendrik]

Wouldn't the simple answer be to tie the access key to the machine's hardware ID?

If the hardware ID changes, new key.

If I build a new machine to replace a old one, requiring me to change the key on all client systems accessing this seems rather pointless, don't you think.

Main point is that library backups are meant as backups, they restore the exact same state as it was before, including Access Key - at least when you restore with settings.
If you use a backup to "give" your library to some other person, you are going beyond the intention of the system, and its kinda up to you to make sure no information is "leaked" that you don't want to share (whatever that is depends what your library may contain, not only the Access Key)

You can always restore without settings, only the library, to avoid this particular problem, but selectively excluding a few settings would get complicated fast.

[leezer3]

If I build a new machine to replace a old one, requiring me to change the key on all client systems accessing this seems rather pointless, don't you think.

Main point is that library backups are meant as backups, they restore the exact same state as it was before, including Access Key.
If you use a backup to "give" your library to some other person, you are going beyond the intention of the system, and its kinda up to you to make sure no information is "leaked" that you don't want to share.

I'm in two minds about that one
I and I suspect plenty of others regularly copy libraries around.
I never reinstall unless I have to.

You might build a new PC once a year, if that?

Perhaps an option on restore?
That rather contributes to options bloat though

-Leezer-

[JimH]

Just to set your expectations, the access key system generally works very well, so changing it isn't very likely.

If you move a system, the new IP addresses (inside and outside) will get picked up after a few minutes, so the existing access key will work.

[AndyU]

Just to set your expectations, the access key system generally works very well, so changing it isn't very likely.

If you move a system, the new IP addresses (inside and outside) will get picked up after a few minutes, so the existing access key will work.

That did not happen in a few minutes, not even in a few hours, for me, for sure. I played an album, tried to stop it with JRemote, it wouldn't connect, played another one from my PC, same again.. left it .. returned .. thought it was just the depressingly increasingly familiar habit JRemote has of losing connection .. then I checked the access key and it was the one from the old machine. Hours.

And even if it had only been a few minutes it would still have been long enough to have experienced JRemote not working, so I can't see that a delay of a few minutes would be acceptable, unless you warn the user about it. Does it need to take minutes to effect the change? A user has selected a library restore, you know that a change in access key is possible, surely you can pick it up and fix any issues immediately - or at least tell your user to wait or whatever.

[glynor]

If I build a new machine to replace a old one, requiring me to change the key on all client systems accessing this seems rather pointless, don't you think.

Main point is that library backups are meant as backups, they restore the exact same state as it was before, including Access Key - at least when you restore with settings.

Completely agree. I have done this myself here and again.

Also:

Short of editing the registry of their machines, I don't see how else to avoid this - as I would not want my license or key info spread around even among family members. Can cause headaches with machine's remote access.

Just reset the Access Key after you restore: Tools > Options > Media Network > Access Key > Reset

[Arindelle]

Completely agree. I have done this myself here and again.

Also:

Just reset the Access Key after you restore: Tools > Options > Media Network > Access Key > Reset

Thanks Glynor. That's a lot easier than what I was doing Never saw that reset before!! @Hendrik, yes see your point. ok no need to change anything then for me 

[glynor]

I think it is reasonable that after restoring Settings it should trigger a "forced" Access Key network update.

The problem is that if you are using a settings restore to copy settings to a different PC (that is not intended to replace your real server, so you need to reset the Access Key), then this will cause your Access Key on your real server to get screwed up for a while. And then you'll have nothing you can do to fix it other than to wait it out.

Not sure how to solve that.

Hendrik, if you see this, can you confirm exactly when the Access Key does get "refreshed" on JRiver's servers?  I know it is periodically, on a timer.  At one time it was every 24 hours, right? But there are probably other "triggers" too. Does it happen at every startup of MC (so in the above case you'd just need to restart the server)? Is there some other way to force an update?

Maybe that's all we need? Tools > Options > Media Network > Access Key > Force Update or something?

[Hendrik]

Hendrik, if you see this, can you confirm exactly when the Access Key does get "refreshed" on JRiver's servers?  I know it is periodically, on a timer.  At one time it was every 24 hours, right? But there are probably other "triggers" too. Does it happen at every startup of MC (so in the above case you'd just need to restart the server)? Is there some other way to force an update?

At startup and once every hour.

[glynor]

Ok. Sounds entirely reasonable. But, when you start up immediately after applying Settings from a backup, does it "miss" that first update? Is that what people are seeing? Perhaps it is still "applying" settings and so doesn't do the normal Access Key update (if it previously had a different one or was off or something)?

That would potentially require up to an hour (possibly longer if the server is then sleeping and can't "talk" online) to make the update go through.

[RoderickGI]

But, when you start up immediately after applying Settings from a backup, does it "miss" that first update?

AndyU hasn't said, but I don't think he restarted the Server after restoring the backup, so the Access Key wasn't immediately updated. But it should have worked after an hour or so. It is quite possible that initially JRemote didn't connect because of the Access Key issue, and then later didn't connect because of a JRemote issue, given that he is reporting lots of lost connections JRemote.

Main point is that library backups are meant as backups

This is my belief as well. If someone was to back up a Windows system, and then restore it on a completely different PC with new hardware, that person would expect to have to do some extra work to get Windows to function again, such as change all drivers to support the new hardware. It is the same when moving a MC backup from one PC to another. A user has to understand what needs to be done to make that work, which means doing some research, and expecting to do some troubleshooting.

Maybe this thread will help some future users who do transfers. 

[glynor]

AndyU hasn't said, but I don't think he restarted the Server after restoring the backup, so the Access Key wasn't immediately updated.

It forces you to restart when you restore Settings from a Library Backup. The thing I don't know is does it:

1. Restart and then after restarting "ingest" the new settings (in which case, the Access Key wouldn't get updated because it would still point at the old value while the "Update" portion of starting up happens).

2. Apply the new settings and then restart (which would suggest the Access Key should be immediately updated, if the PC is online at the time).

[Hendrik]

Its (2).

To me AndyU's problem sounds different though, it sounds like he copied the library to another system and the new system then stole the Access Key, which resulted in JRemote no longer being able to reach the old one.
Well, and this is just working as intended, then. Maybe some info might be nice.

[Arindelle]

OK, so it sounds like all you would have to do is restart the server and wait right? As for AndyU's issue, If the waiting period is too long, for JRemote you can still add a server connection using an IP address and not authentication. You won't be able to tag, but you can do everything else. You can still do tagging as long as the Authentication option is checked  As this happens pretty rarely, seems to be pretty easy work around

Maybe this thread will help some future users who do transfers.  

yes, I'm starting to have a few ideas ...

just a couple of questions/confirmations

1) the access key is ported over ONLY if the settings option is checked, right?

2) the JRiver license is NEVER overwritten by a restore, right? (I could check this on my son's machine, but I don't have remote access so ...)

3) Settings also would copy over all the options, including RMCF presets, DSP studio settings

4) Library+Playlist check box Only restores would copy over all media and tags in the library and the database fields (including custom fields), and views for Remote, Standard and Theater "modes", right?  [As remote and Theater Views are created via the options, this is really the important PITA to avoid having to redo]

EDITED as per Glynor's correction

[AndyU]

OK, so it sounds like all you would have to do is restart the server and wait right? As for AndyU's issue, If the waiting period is too long, for JRemote you can still add a server connection using an IP address and not authentication. You won't be able to tag, but you can do everything else. As this happens pretty rarely, seems to be pretty easy work around

My only point is that I didn't know I had to do any of these things, nor is there any reason to suppose I should or could have known. All I'd suggest is a warning, and possibly a choice, something like:"You've just restored a library from a different machine. Would you like to keep your current access code for media network or change it ..." or whatever makes sense. Then there's less likelihood of confusion.

[glynor]

for JRemote you can still add a server connection using an IP address and not authentication

You mentioned this once previously (if not in this thread, elsewhere, I'm too lazy to look). You DO NOT need to use an Access Key to enable authentication and have tagging work.

I don't use an Access Key at all anywhere (on JRemote or any of my MC clients) because I actually have a network setup that can resolve my Dynamic DNS name properly inside and outside my LAN. JRemote has an authentication section in the server setup, and it works just fine with a FQDN or IP address instead of an access key.

[glynor]

1) the access key is ported over ONLY if the settings option is checked, right?

Correct.

2) the JRiver license is NEVER overwritten by a restore, right? (I could check this on my son's machine, but I don't have remote access so ...)

Correct. Licensing is not included in the backup, is not impacted by restoring a backup, and is completely separate.

3) Settings also would copy over all the options, including RMCF presets, DSP studio settings

Pretty much everything. Items that are Library specific are included in the Library portion of the backup (like Theater Views, for example).

There are also a few items that are machine specific (which you don't ever set directly) which aren't included in the backup at all, like settings related to your optical drives. This isn't needed because these are just auto-created on first run if missing or incorrect. But everything that you can set in Tools > Options is in either the Library portion or the Settings portion. It even includes the values for some registry settings you can change manually which aren't accessible in the Options dialog (like Thumbnail storage locations, for example).

Plugins, Keyboard Shortcut customization, skins, and other items you install manually by putting files in folders are not included.

4) Library+Playlist check box Only restores would copy over all media and tags in the library and the database fields (including custom fields), and views for Remote, Standard and Theater "modes", right?  [As remote and Theater Views are created via the options, this is really the important PITA to avoid having to redo]

Correct. The basics of which is included in which portion of the backup is addressed on the wiki article:
http://wiki.jriver.com/index.php/Library_Backup

[glynor]

Its (2).

Then I can't see how it could be improved, really. Perhaps the only thing I can think of is if the user manually changes the Access Key, it should refresh itself. But I'd be shocked to learn it doesn't already do that...

To me AndyU's problem sounds different though, it sounds like he copied the library to another system and the new system then stole the Access Key, which resulted in JRemote no longer being able to reach the old one.

Yeah. I wonder if he was doing a manual dump of the registry locations or something?

[Arindelle]

You mentioned this once previously (if not in this thread, elsewhere, I'm too lazy to look). You DO NOT need to use an Access Key to enable authentication and have tagging work.

well I'm glad you spoke up then. I have not just said this once previously probably about 20 times for the past 6 years!!!

Then that means you need only the authentication boxed checked. No authentication no tagging from the client --   then an access key is more of an option, a convenience. Oh well I can say its not obvious and all , but euh no I should have known better, my bad. Thank you

[glynor]

then an access key is more of an option, a convenience.

Yup. It just provides two services for people who can't (or don't want to) set it up themselves:

* dynamic DNS
* proper routing inside and outside a LAN (so that when you are on the same network as the server, it uses the internal IP, and when you aren't, it uses the external IP).

It does the latter in kind of a "kludge-y" manner, but it works well enough.

In fact, using the Access Key connects to the server in exactly the same way as specifying an IP address manually. It just adds a step where it looks up the IP address from JRiver first, and then uses the reply to connect. So it is literally no different than specifying the IPs manually.

[AndyU]

Then I can't see how it could be improved, really. Perhaps the only thing I can think of is if the user manually changes the Access Key, it should refresh itself. But I'd be shocked to learn it doesn't already do that...

Yeah. I wonder if he was doing a manual dump of the registry locations or something?

Nope. I wouldn't even know how to a manual dump of the registry. I transferred my music files from one PC to another and set up MC and redid my views manually, tidying them up in the process. Sometime later, realising that I had messed up my date imported info, I copied the old library to the new machine so that my Recent Music view behaved as I wanted.  JRemote stopped working, for quite a while iirc. Eventually I looked at the JRemote error messages, saw some stuff about the access key, got a new access key and all was better. Struck me that it should be less than an hours work to make MC avoid this or warn the user helpfully in some way. Seems like you guys have spent more than an hour discussing it!

[glynor]

I copied the old library to the new machine so that my Recent Music view behaved as I wanted.

How.

[AndyU]

How.

I copied the library from the old to new PC using drag and drop, then did a restore of that library on the new PC.