Print

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

[Mike Foran]

I recently upgraded from v.20 to v.21 on my Windows based network, and an issue has arisen. Prior to the upgrade, I could, from my desktop computer, open the JRiver library hosted from my server, import files, then hit F6 to move them to the server location. My desktop and my server all have the same drive letters assigned. I have several profiles for moving different types of media to the media server's drive this way. However, after this upgrade, as soon as I hit F6 to initiate the Move command, I get an error message "this tool is not available when connected to a server."

Is this a change in v.21? If so, why? I had no problems with the way it was working before. If not, has something broken in the upgrade?

[Mike Foran]

Is this really not an issue for anyone? Is my question not clear? This is really a big issue for the way my house is set up. I have a media server that hosts the library, and each family member shares the library on their own computers. Up to now it hasn't been an issue for each member to add their own media to the library but now it's prohibited.

Am I the only one having this issue? Is this not how anyone else uses JRiver? Is there a better way for multiple stations to add media to the shared library? Since this is the only means of getting support on this program I'd appreciate some feedback.

[glynor]

I have thoughts on this, but I need to do more testing and collect more evidence.

The ability to use RMCF and to copy files from clients has absolutely "weakened" in the Media Network setup over time, and now is completely disabled. I haven't had time or energy to go back and reinstall old versions and figure out the exact chain of events that led us here, though.

[Arindelle]

I have thoughts on this, but I need to do more testing and collect more evidence.

The ability to use RMCF and to copy files from clients has absolutely "weakened" in the Media Network setup over time, and now is completely disabled. I haven't had time or energy to go back and reinstall old versions and figure out the exact chain of events that led us here, though.

Still have v20 on my PC and RMCF tool doesn't work on a client either. So it was disabled before version 20. I think Mike F must have had his desktop machine running as the server before. Otherwise he'd have gotten a similar error message prior to his upgrade

[Mike Foran]

Still have v20 on my PC and RMCF tool doesn't work on a client either. So it was disabled before version 20. I think Mike F must have had his desktop machine running as the server before. Otherwise he'd have gotten a similar error message prior to his upgrade

Hmm, interesting. Yes, I believe I originally set up the library on my Desktop, but then moved it to the server once I had a better idea how JRiver worked. Would that have influenced things? I am happy to replicate this setup if it meant this functionality would be restored (although it seems a bit ridiculous to have to do so).

[Mike Foran]

I have thoughts on this, but I need to do more testing and collect more evidence.

The ability to use RMCF and to copy files from clients has absolutely "weakened" in the Media Network setup over time, and now is completely disabled. I haven't had time or energy to go back and reinstall old versions and figure out the exact chain of events that led us here, though.

I would appreciate that Glynor. I have, for the time being, moved back to v.20 where this functionality is still available. Thankfully I have discovered this issue before I made any changes to my database so it doesn't fork.

[glynor]

Still have v20 on my PC and RMCF tool doesn't work on a client either. So it was disabled before version 20.

I was all set to complain and then tested that myself and found the same. I suspect it was one of the later v20 builds, but haven't done the investigation to see exactly when it broke.

Originally, you could use all of RMCF (well, the predecessor, Rename Files from Properties) from clients if you had local access to the files, but it broke and re-imported files you moved (so that wasn't very good). Then, later, I'm as positive as I can be (without seeing it again) that you could use RMCF but only in the Copy without Updating modes. That is gone now too, because it broke at some point.

But I need to go back and figure out when it broke, and verify that I'm not crazy.

[Mike Foran]

The v.20 version I am currently using is v.20.0.131, which I thought was the most recent of that version but I just now checked and there was a 20.0.132. So maybe that was where it broke?

I should note that the moving process wasn't the  most elegant. After executing the move from a local drive to the server, there was no progress bar, or even confirmation in the Action Window that anything was going on. In the library list the currently moving titles would be listed as missing until after the move completed.

Is there a better way to import media into a shared JRiver Server? I am not against adapting my behavior as long as there is a good solution.

[glynor]

Mike, I think you are using this in a different way than what I'd been talking about (and way that had been really documented). I think I get it, but can you confirm a few things for me?

1. Are you running MC on a client, connected to a remote Library server, but using RMCF to operate on files that are local to the client (on the C drive, for example, or something)? Then moving them onto a file share that the Server is watching with Auto-Import?

2. If so, how do you Import the files described above onto the Client copy? How do you get them "in there" in the first place?

3. Can you (especially if I'm off base) describe step-by-step exactly what you do that works on your copy of MC20? What files? Where are they? Where are you "sending" them?

4. What exact Mode and Templates are you using in RMCF that works correctly in MC20?

[Mike Foran]

Sure. Thanks for taking the time to look into this. Here's how I have been doing things:

- I have a server computer running JRiver, sharing it's library via Media Sharing.
- I have three other computers on my LAN that load and run the shared library. They have Auto Sync enabled (not sure that's important here).
- All four computers have the drive letter L: mapped to where media is organized and stored. For the server, L: is directly connected to the computer. For the others it is a network drive mapped to this letter.
- When any of the three client computers purchases some type of media, be it MP3 for FLAC audio files, or some type of video file, or whatever, they download it to their local computer. They then drag those files into JRiver. They appear in the library, but the path points to that computer's local drive.
- All the files imported are selected and RMCF is opened (via F6 or Library Tools->RMCF). I have created several custom 'Preset' options for different types of media so they are sorted and named properly. However, all the presets designate the L: drive as the base path.
- If it's multiple files, JRiver confirms I want to handle multiple files, which is confirmed.
- JRiver, in the background, moves the files from the client local drive, across the network, to the L: drive and sorts them into the proper folders.


The step that is failing in v.21 is when I go to open the RCMF panel, at which point it just gives me the error instead.

[Mike Foran]

I should add: After the RMC is approved, JRiver doesn't give any indication that it is doing something. There is no progress bar, nor feedback in the Action Window. The files show a 'missing' icon until they are moved, at which point they show up with the new path.

[RoderickGI]

The removal of access to the RMCF function on a MC Client was a recent MC21 change. Prior to the change the copy process still worked, but other processes such as Move didn't. It was confusing people, and they were breaking their libraries trying to use it, apparently.

I didn't test all this stuff. I am just going by comments in earlier threads.

One of those threads, BTW, was where you were complaining about the removal of access to the Copy function Glynor.

[Mike Foran]

If that's true then that is extremely frustrating. I want to keep supporting this program, but the client/server functionality was one of the main things that drew me to it. I didn't really see any new features in v.21 that were important to me, but I wanted to keep supporting the development of this great piece of software. Unless this is fixed and restored I am going to stay at version 20 and not waste any more money on upgrades that break important functionality. I hope the team can find a way to fix this issue. Clients should be able to import media into a shared library.

[Arindelle]

If that's true then that is extremely frustrating. I want to keep supporting this program, but the client/server functionality was one of the main things that drew me to it. I didn't really see any new features in v.21 that were important to me, but I wanted to keep supporting the development of this great piece of software. Unless this is fixed and restored I am going to stay at version 20 and not waste any more money on upgrades that break important functionality. I hope the team can find a way to fix this issue. Clients should be able to import media into a shared library.

As I said above, the final version of 20 already was like this ... this is not a version 21 change so lets not get all worked up about this. I don't know which exact version, but I checked the 20.0.132.

Clients should be able to import media into a shared library.

careful when you make statements like this. This can be confusing to people.

You are sharing access to the media files, yes. You are, normally, loading a library on your client machines from 1 machine that is running media server. You are not "sharing it" or accessing it directly, it is like a virtual copy - by design. This “copy”  updates via auto-sync every so often, if you have that option ticked, or by running a manual sync.

The fact that through mapped drives it was convenient to move files around via clients is one thing. But by design, and Glynor can edit for omissions or errors on my part, there have always been limitations: Forcing a manual Import, Ripping, Cover art manipulation, moving and renaming files,  audio analysis … So by using RMCF in that way you actually are modifying the library directly, probably why they made the change as it allowed a workaround using mapped drives visible on the client machines. People were clamoring for read only user access and ways to stop family members to mess with the library. They just closed the loophole.

There are ways to do what you do ... just move the files from a client via Windows into a watched folder and wait for auto-import to take over. Or use Team Viewer or any remote desktop app to work directly on the server machine. I've found the best way is just have a temp “sandbox” directory; its gets imported via the server machine (via auto-import or a direct manual import) ... do your tagging from your clients (you still have access to this for playback every where) and when satisfied just use RMCF on the server machine remotely (or locally).

I'm not saying that maybe there should not be a way to use RMCF across the network, or even maybe change how the server/client set-up works. But I don't think it was there intention that you could directly access a library from a client.  Basically one machine running media server; other machines running as clients that can edit metadata is how its been working for a long time. Running media server on multiple machines, and using RMCF from clients I don't believe were ever intentional functionality so saying they have to fix it or restore it doesn't make sense.

[Mike Foran]

Thanks for the suggestions. I'm fine with adapting to new behavior as long as it works reliably. Remoting in to the server is a little beyond my wife and daughter's interest, but I could see copying to a watch folder and then organizing the library afterwards from the client. It's not as convenient and it takes longer, but it would work.

However, to your point of whether this behavior was by intent and needs to be fixed: prior to upgrading to v21, I was at v20.0.131. I'm not actually sure why it wasn't at .132 since I have auto update turned on. Regardless, as of .131 this ability to RMCF across the network from a client was intact on my system. And from a personal perspective, the ability to do this was one of the main reasons I bought into the program in the first place, and has always been an important feature to me. I hope the dev team recognizes the importance of this ability, but considering I appear to be the only person complaining about it's removal (maybe Glynor too but I can't find the other threads you mentioned) I suspect the new behavior is set and I will either have to adapt or remain at v.20.

I can totally understand why it would cause issues and confusion. I doubt it would play nice across platforms (not sure how Linux and OsX handle alternatives to mapping drive letters). And I could see why people would not want clients making revisions to a shared library. However, to that last point, I don't see why there couldn't simply be a checkbox under the 'Media Network' options saying 'Prevent clients from modifying library.' It could even be activated by default.

[mwillems]

The easiest way by far is to have a shared directory that auto-import on the server "watches."  You can recreate your RMCF templates as tag on import rules, and then all your clients will need to do is drag the files to the shared directory.  The server will then pick up the files within a few minutes, apply the templates and it will be the same as if you'd done your old workflow, with the added bonus that your clients have fewer steps to do (i.e. it's actually easier on users this way as they don't need to be aware of templates).

If anything goes wrong or if there's anything that can't be done through tag on import, you might need to remote into your server as Arindelle suggested, but it's much, much easier to do than it sounds and works a treat, and you can do it at your leisure (i.e. your clients will still have access to the files in the meanwhile).  But tag on import should be able to do 90% of the heavy lifting automagically.  I do this at my house, and remote into the server at the end of the day and work through the recently imported list and do any changes I need to do, etc.  It's a bit of work for me, but it's completely transparent to the family, they just know they need to put the files in the "watched" directory (or in the case of my wife's phone, I have it auto-uploading her pics to the server at intervals so she doesn't have to remember at all).

[Mike Foran]

The easiest way by far is to have a shared directory that auto-import on the server "watches."  You can recreate your RMCF templates as tag on import rules, and then all your clients will need to do is drag the files to the shared directory.  The server will then pick up the files within a few minutes, apply the templates and it will be the same as if you'd done your old workflow, with the added bonus that your clients have fewer steps to do (i.e. it's actually easier on users this way as they don't need to be aware of templates).

Thanks this looks like the way to go. I'm having a couple issues but that's a different subject so I'll move it into a new thread.

[RoderickGI]

As I said above, the final version of 20 already was like this ... this is not a version 21 change so lets not get all worked up about this. I don't know which exact version, but I checked the 20.0.132.
careful when you make statements like this. This can be confusing to people.

This is what I meant.

21.0.30 (12/22/2015)
5. Changed: Made the "Rename, Move, & Copy Files" tool no longer available when connected to a server (because the results were confusing anyway).

This is when access to RMCF from a Client was removed and replaced with the message "This tool is not available when connected to a server" which Mike originally reported.

Prior to this a user on a Client could still access the RMCF tool, but Moves didn't work unless there were mapped drive set up as Mike had them, which most people didn't. So results were messy. Copy did work, if everything was set up correctly.

But the solution proposed, using a shared directory and tagging on import, sounds like a better long term solution.

[glynor]

Copy did work, if everything was set up correctly.

Copy did work at one time, but it is/was broken as of the last build of MC20. It makes the destination folders, but never starts the copy of the files.

That's what I want to look up. When that broke, or if I'm crazy and it never worked.

[Mike Foran]

Auto import works ok as long as the tags are already in good shape. My process was to get tags into shape the way i want them, then import with sorting rules based on the tags. i can set those same import rules for auto-import, but if the tags are broken the files get screwed up. I much prefer my old method. It would be nice if the dev team could find a way to bring this functionality back in a way that everyone can use it, not just specific cases like mine.

[blgentry]

^ A good number of people here auto import their files, but mark them with a Tag like "not approved" (or something similar).  Then, they use an administrative view that specifically looks for that tag.  The tag could be a key word, or a custom defined field that you set up.  The point is simply that anything auto imported gets tagged and can be easily found with the admin view.

Then in the admin view, you review the relevant Artist, Album, etc, tags and make sure the they are correct.  Editing them as you go until you like them.  Then you just remove the "not approved" tag, and they are no longer in the admin view.

The really slick way of doing this, is to also modify your top level view(s) to *exclude* files with "not approved".  That way new stuff only shows up in the admin view, until it's approved.  After approval (and possible edits) it then magically shows up in all of the other views as appropriate.  Note that this doesn't require much work.  Just modify "audio" (for example) and EVERY VIEW under audio will follow the rule you just added to exclude "not approved" files.

I think it's a really nice solution for situations where you can't be confident in the tags of new files.

Brian.

[Vocalpoint]

Is this not how anyone else uses JRiver? Is there a better way for multiple stations to add media to the shared library? Since this is the only means of getting support on this program I'd appreciate some feedback.

We have 5 PCs (and 4 iPhones/iPads) accessing JRiver in the house here - but none of the "clients" ever get to add anything to the master library. Our layout works as designed. Clients are clients and the server is the server.

Now for media admin - I do something a bit different but I find it much more flexible than allowing "clients" to mess with the master library.

On my personal workstation - I have my own local library set up which points to the identical location for the media as the shared library on the HTPC (Server) does. (\\MEDIA-PC\Music). There are no drive letters in use here.

When I need to add or change anything with the music or video - I do all the tagging work on my PC and simply move the results to the drives on the HTPC. Then the "server" instance of MC (running on the HTPC) picks up these changes (Has Auto-import) running and all clients instantly get the fresh new stuff.

This method allows me full access to the master "media" without dealing with having to use admin passwords, using a "client" connection to the library or getting any messages about tools not being available. It also ensures no family member can mess with the stash and ensures that I preside over all approved changes.

I also use a series of different "approved/non-approved" views - accessible ONLY on my PC to ensure the library is correct and everything that has been approved appears where it should be on "client" instances when accessed.

My personal PC never even connects to "client" library as I find it much easier to keep a local library for admin purposes.

Just another take on possibilities.

VP

[glynor]

If you go with the Mark as Approved/Not Approved method mentioned above... Make your field [Approved] instead of the reverse, to make your life a bit easier.

Since all new files will initialize with fields set to blank or zero, then you won't need a Tag on Import rule to set everything imported to "not approved".  All new files will automatically get [Approved] = 0.

[Mike Foran]

On my personal workstation - I have my own local library set up which points to the identical location for the media as the shared library on the HTPC (Server) does. (\\MEDIA-PC\Music). There are no drive letters in use here.

Thanks, this is similar to the way I am just now setting things up. I have essentially created a new local library that will be used for tagging and then RMCF to the network drive. With tags in shape, the server scoops them up and puts them in their proper place. I can then switch back to the shared library for general usage. This works ok for me, but is a little involved for other family members.

[Mike Foran]

If you go with the Mark as Approved/Not Approved method mentioned above... Make your field [Approved] instead of the reverse, to make your life a bit easier.

Since all new files will initialize with fields set to blank or zero, then you won't need a Tag on Import rule to set everything imported to "not approved".  All new files will automatically get [Approved] = 0.

This and the previous comment are a good idea. I'll implement something like this to easily identify tracks I didn't personally enter into the library.

[The Big Labinski]

Sorry to bring it up again but the idea from vocalpoint is very useful for me.
My question is now:
Do I get an auto import (when configured) working without starting MC itself?  I just want like to keep the server running for this case.

[JimH]

For auto import to work, you need to have started Media Center or Media Server.  You can configure Windows to start either on Windows Startup.