Print

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

[dtc]

I am trying to do a remote copy of tracks from my main server in MA to my client in FL.  I do the typical client connection (Tremote) to my remote server, select the files, and do the download. That part works fine. The files are transferred to my client.

However, when I close the connection to my server and then reconnect to the server, the album I transferred no longer appears in my view.  I have done this with 2 albums and the same thing happens. The files are transferred, but they disappear from my view of the server.

Unfortunately, I have no remote access into my server system other than through MC and Gizmo, so I cannot tell if anything actually changed on the server. But, the view I get on the client no longer shows the album I transferred.

I also used Gizmo to connect to the server and the Silent Night album does not show on the AsusDesktop (in MA) server.  This makes me think something has actually changed on the server.

The first  two screenshots show the problem. I selected the files in the album Silent Night on the Server (AsusDesktop), which is shown in the display. After transferring the files, I disconnected from the server and then reconnect my client to it. The second picture shows that the album Silent Night no longer appears in the view of the server.

My understanding is that the file transfer should transfer the file but not do anything on the server and the view of the server from my clients should remain the same.  Unfortunately, the original album on the server is no longer visible on my clients.  This makes the download feature pretty useless. Every album I download to my client will disappear from my clients' view of the server.

I do not think this feature is suppose to work like this.  I thought it was a straight copy to the client without changing anything on the server. Any suggestions?

One further piece of information. After copying the file down to the client, the view of the server has the filename of the tracks as the filename on the client, not on the server. The third screenshot shows the view of the server after doing the copy. The filenames listed (the e: ones) are the files on the client, not the server. Not sure if that is relevant, but I was surprised to see them changed by the copy process.

[JimH]

My understanding is that the file transfer should transfer the file but not do anything on the server and the view of the server from my clients should remain the same.

That's correct.

[dtc]

That's correct.

Thanks for confirming that.  So why does my view of the server change on both my client and on Gizmo?

[dtc]

I turned off Auto Sync with Server and the copy operation no longer deletes the albums in the server view from the client and from Gizmo when I reconnect to the server.  It seems like the library sync function is somehow making changes back to the server.  Since I see this behavior on Gizmo, I have to believe that with auto sync enabled, a change is actually being made on the server.

In my third screen shot above, it shows that after a copy the client side version of the library has changes made to the file location to point to the local file location.  I wonder if in that process something gets set that makes is appear that the album is no longer on the server and the auto sync picks that up and removes the album from the server?

If, in fact, a change is being made on the server, then using this copy feature with auto sync set is a dangerous option that needs to be fixed.

[Craig Shipley]

I'm seeing a similar if not the same problem as well. Two servers on the same home network, latest version on both, if I download files (complete albums) from Server A onto Server B, once completed Server A shows no album artwork and no files, just a box with the album name. But Windows Explorer shows the files are still present (as I would expect them to be). Server B is fine. It's like the files are being moved, not copied and a sloppy move at that since traces of the album still shows up in the window.

[dtc]

I'm seeing a similar if not the same problem as well. Two servers on the same home network, latest version on both, if I download files (complete albums) from Server A onto Server B, once completed Server A shows no album artwork and no files, just a box with the album name. But Windows Explorer shows the files are still present (as I would expect them to be). Server B is fine. It's like the files are being moved, not copied and a sloppy move at that since traces of the album still shows up in the window.

Try turning off library sync and see if it still happens.  (Tools - Options - Media Network -Client Options - Auto Sync with Server). My guess is the changes to the server are not being made directly by the file move operation but by the subsequent auto syncing of the temporary client library data back to the server.

[dtc]

I found another problem related to mutli-disc sets. The filename for the file on the client is neither the one on the server or the one in File Location - Audio on the client.  For the first disc, the name uses the standard track # name convention (e.g. 01 first track.flac) but for subsequent discs it uses disc disc# name (e.g. DISC 2 - 01 first track.flac)  The convention using DISC # in the file name for second and higher discs is not used on the server nor is it defined on the client. It appears to be a special convention for this copy procedure.  Unfortunately, it is not one I use which means renaming all the files for dics 2 and up.  If the disc # was in the folder name, then I would only have to change it in one place. But, since it is in the file names, I have to change it for each track.  I am trying to just replace files that got deleted without having to re-import the albums and then using RMC to change files names.

I have also seen albums where the filenames on the client are of the form 00 01 first track.flac. I have no idea where the 00 comes from and, again, it is not the file name on the server nor is that form defined on the client.

I thought this copy function was going to be very useful, but in its current state, I am afraid to continue using it unless the file syncing problem gets fixed and until there is better control over the naming convention on the client.

[dtc]

bump

Now that JRiver is back after the holidays, I wanted to bump this thread.

The copy to client option does not work as intended, as it appears to change the data on the server. This is not only not the intended operation, it is damaging to the server library.

Please, take a look at this. Changing the server by mistake is a problem.

[dtc]

The courtesy of a response would be appreciated.

Use of this option damaged my library server and has the potential to do serious damage if used repeatedly.  It seems like such a bug should be addressed.

[wer]

I can't really be of any help dtc as I don't use this functionality, but it does sound like a serious problem.  It would seem the file disappearing from the server's view is due to the the filename tag being changed to one that doesn't exist on the server, which would make it a broken link and might therefore be dropped depending on your settings. I found a similar phenomena the other day where files that were destined for "<no change>" in RMCF actually had their filename entry in the library changed to "<no change>" and this of course resulted in broken links.

Have you been able to confirm whether any changes were actually made to the server-side filesystem, or whether it was just MC database fields that were mangled?

[dtc]

Have you been able to confirm whether any changes were actually made to the server-side filesystem, or whether it was just MC database fields that were mangled?

Unfortunately, I do not have remote access to my server system so I cannot tell exactly what happened on the library.  But, nothing is supposed to change on the server. But something is happening in the server library.  And, since Gizmo shows the same change to the server library, it is definitely a change on the server side.

I was going to copy down hundreds of albums, but thought I would try one as a test. Glad I did the test. A large copy  would have made my server useless as a server. That is why I keeping pursuing this. Someone could unknowingly destroy the functionality of their library server by using this function.

[JimH]

I have never seen this happen.  Can anyone else duplicate it?

[wer]

I just tried this functionality.  And regretfully I can report that what dtc described is essentially correct.  The file I "downloaded" has disappeared from my library and all playlists. It does NOT show in the library as a broken link. It's just gone.

This feature is totally unsafe to use.  It is highly destructive.

I'll report back when I determine what happened at the filesystem level.

[wer]

Ok, here's the deal...

First, I looked at the "documentation" (meaning the forum post that announced it) on this new feature.  It stated the file would be downloaded to the "default directory" on the client. So I prepped my client by specifying a default directory for audio of X:\  since there is no X drive on the server.

Then I tried to reproduce dtc's results, which I successfully did. Here's what I did and what happened.

1. I started MC, which connected to the local library by default, and then connected to the remote library server.
2. I navigated view on the server, picked a file, and did a download from server.
3. Immediately MC opened up the little progress dialog and performed the download. The file appeared on my local file system at the expected location.
4. My view of the server through the MC client immediately showed the [Filename] field had been updated to X:\...   
5. I went into the other room and looked at MC on the server. Nothing had changed. The file was still there on the fs, still there in the view and playlists, and [Filename] still showed the normal D:\... path for the file.
6. I tried playing the file on the server. It played.
7. I went back to the client PC and look around. Everything was still as it had been in step 4. So I thought I'll see if any local library changes are made.  But first...
8. I went back into the other room to inspect the server a second time.  The file was now GONE from the library, and removed from all playlists.
9. I disconnected the MC client from the remote server and reconnected to the local library.
10. No changes made to my local library on the "client" pc, but the file was still there where it had been downloaded; it was not added to the local library.
11. I went back to inspect the server yet again.  Now, the file was BACK, in Album and Artist views. [Filename] field was as it originally was. The file could be played.  However, the file was missing from all playlists.  The file on the filesystem had not been modified, and was still in place.

Conclusions:
A. The server database is permanently modified by this function. The function is not safe to use.
B. The file reappeared in my server library because auto-import was running on the server. The [Date Imported] field confirmed this.
C. The changes to the server do not happen instantly. I think they are delayed somewhat because of the vagaries of "Sync changes with library server". I did not explicitly perform a sync during the test.
D. If auto-import is not running, the file will not reappear on the server. It must be re-imported, or a library backup restored.
E. The loss of playlist membership, and other database metadata not written to the file, is permanent.
F. The server change does not behave like a simple change of the [Filename] field; more below.
G. The consequences of the bug might be masked if the default path on the client is available to the server. For example, if the client default path is "C:\..." then the server will of course have access to an equivalent location. Likewise if the default path is a UNC path like \\NAS\Flac both servers could have access to it. If the path is the same on both machines, like D:\FLAC  then perhaps the bug won't manifest at all. Perhaps this is why something this catastrophic escaped internal testing.

I'm not going to do further testing regarding point G, since I've done myself enough damage already. I have some playlists to fix and metadata to recover.  JRiver should do that testing.

Point F is significant too. I will note that this server has "Fix Broken Links=OFF".  If the file had been merely "renamed" in the database (see point F) by modifying the [Filename] field, the file would stay in the views, and would remain on the playlists, albeit as a broken link.  But this did not happen on my server. The file was actually removed from the library, with the negative consequences that result from that.  If it had been a simple corruption of the [Filename] field, that could have been corrected (on my server) with RMCF using the update database/no copy function.  But the way the bug is, repair in that way is impossible.

So the good news DTC is that your files are still on the server. The bad news is that any playlist membership you had is destroyed, along with any metadata not saved in tags.  If you have an appropriately timed library backup, that should fix you up.

Anyway, yes this is a bad one.  Hopefully nobody uses the feature until this can be fixed.

-Will

[JimH]

Thanks for the details.  We'll take a look.

[wer]

Considering that this has been in the field for an entire year, it's either a miracle or an extensive lack of use that there haven't been people complaining of their library being destroyed by this.  Perhaps people haven't been traveling because of the pandemic, so they haven't needed the feature.  I don't use client/server generally, so although I'd seen the original announcement, I'd actually forgotten this feature even existed until I was reading your post, dtc.

[dtc]

wer - Thanks for the follow-up. Without access to the server, I could not tell exactly what was happening, but your observations are consistent with my thinking of what was happening.  Fortunately, I tested on single albums before doing any large copy. So, when I am physically back to my server, the fixes will be very easy.

I think it is pretty clear that the library server sync is changing the server database, which is probably an unintended consequence of implementing this option. Turning off the auto sync stops the problem, but that is not a permanent solution. And, now that I have turned auto sync off and copied down many albums, I am afraid to turn it back on. I certainly will not do that until I am back at the server location and have suitable backups.

And, I agree, this is a serious problem. Even though the option is not used much, anyone who uses it could do serious damage to their server.

[Matt]

Thanks for all the details.

This should be fixed next build.

The history:
Fixed: After downloading from library server, the file could be incorrectly removed from the server's library.

[wer]

What was the actual nature of the problem, Matt? Point F indicates it was not as simple as the [Filename] field being modified.

Does your change fix it so that observation #4 does not happen?

[dtc]

Thanks for all the details.

This should be fixed next build.

The history:
Fixed: After downloading from library server, the file could be incorrectly removed from the server's library.

I have been downloading albums with auto sync turned off. With the new version, can I safely turn auto sync back on without an chance of the albums being deleted from my library? And, do I need the new version on both the client and the server?

I also raised the issue that the naming for multi-disc sets does not follow the naming conventions of either the original files or the default naming convention on the client. Any ideas of what to do with that?  Currently, it takes a lot of renaming to get a downloaded box set to confirm to my standard naming conventions.

[Matt]

Files would be downloaded, then we would clear the key back to the original database while we were clearing all the other library server stuff.  This made our sync think the file had been deleted!

Now I mark the file as downloaded and leave the key there still.

I'm trying to skip even checking for changes if the file has been downloaded.

It's working for me now, but just let me know once there's a new build out.

Thanks again.