View Issue Details

IDProjectCategoryView StatusLast Update
0015183MediaMonkey 5Synchronizationpublic2019-04-25 16:49
ReporterLudek Assigned To 
PriorityurgentSeverityfeatureReproducibilityalways
Status resolvedResolutionreopened 
Product Version5.0 
Target Version5.0Fixed in Version5.0 
Summary0015183: MM5 > MMS migration wizard and issues
DescriptionBased on discussion with Jiri and feedback here: https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=91632

1) There should be an ability to migrate just metadata without uploading tracks. i.e. for the tracks accessible by both MM5 and MMS at the same time.
e.g. for network tracks in UNC form (when MMS and MM5 are part of the same network) or for local tracks (when MMS and MM5 are installed on the same PC).
This can be done automatically during sync, i.e. technically MM5 sends current file path to MMS and once MMS finds the path as accessible then it will be used (instead of unnecessary upload of the track).

2) There should be a migration wizard that helps user to pre-config the MM5-MMS sync. Something like:

-------------------------------------------------------------------------------------
{This version is shown for non-empty MM5 Library (i.e. existing installation, not new)

There was a new MediaMonkey Server detected. Do you want it to start managing your Library?

{some more explanatory text in smaller font here?}

1. Move local content to MMS (and delete it locally).
2. Copy local content to MMS and keep it cached locally.

[x] Scan all existing MMS content to the local library {shown only when MMS isn't empty}

You can select only a subset of you Library to be managed by MediaMonkey Server in the next step.

[Cancel] [Ask later {?}] [Next >>>]
---------------------
{This version is shown for an empty MM5 Library, i.e. after a fresh MM5 installation}

There was a MediaMonkey Server detected. Do you want to Scan its content to your local Library?

[ ] Also cache the media content locally

[Cancel] [Ask later {?}] [OK]
---------------------




TagsNo tags attached.
Fixed in build2155

Relationships

related to 0005548 feedbackpeke Abandon handling Mapped Drives and force UNC Naming 

Activities

jiri

2018-10-25 11:47

administrator   ~0051454

Note that the wizard should automatically pop-up upon the first connection of MM5 to MMS. And, later it should also be possible to open it from MMS node in MM5 UI.

jiri

2018-10-25 11:48

administrator   ~0051455

Reminder sent to: rusty

Rusty, please have a look, particularly at wording of the wizard.

peke

2018-10-25 15:01

developer   ~0051459

Last edited: 2018-10-25 15:02

View 2 revisions

Added relations to 0005548 where mapped paths can be simply translated to UNC paths for use in MMS

Ludek

2018-10-28 09:25

developer   ~0051486

1) is implemented in MM 5.0.0.2131 / MMS 0.1.7
It includes also the mapped drive => UNC path conversion suggested by Peke in 0005548

rusty

2018-10-31 19:06

administrator   ~0051516

These are the possible scenarios I'm considering for MMW/MM5 users considering MMS:
1) User has content and DB in MM5 only (i.e. on the PC)
a) MMS installed to PC to better share with other MM clients
b) MMS installed to NAS (because user wants to migrate content/management to the NAS)

2) User has content in NAS already, managed via DB on MM5
a) MMS installed to NAS to better share with other MM clients

3) User has content in various locations (NAS, MM5 device, other locations), managed via DB on MM5
a) MMS installed to PC to better share with other MM clients
b) MMS installed to NAS (because user wants to migrate content/library management to the NAS)

What I'm hearing from the user is that they're really unclear on how to proceed for any of these scenarios. The proposed solution seems to mostly deal with these scenarios. The main exception would seem to be cases where content is stored externally (e.g. to Gdrive and the user wants to move that content to MMS). Also, I have a couple of questions about the design at the end of this comment .

I've modified the text / layout slightly for clarity.

-------------------------------------------------------------------------------------
{This version is shown for non-empty MM5 Library (i.e. existing installation, not new)}

MediaMonkey Server Migration Wizard
-----------------------------------
A new MediaMonkey Server was detected. It can be used to store and share portions of your library content even if this copy of MediaMonkey isn't running. Any content on the MediaMonkey Server can be managed using MediaMonkey as if the content were local, provided that both MediaMonkey and MediaMonkey Server are on the same network. If the devices will sometimes be on different networks, you may want to cache some content locally.

Do you want to migrate content to the MediaMonkey Server?

[ ] Yes, move local content (to be specified) to the MediaMonkey Server
. . [x] Cache the content locally {this option should only be shown if the MediaMonkey Server is on a different machine}
. . [x] Scan MediaMonkey Server content to the local library {shown only when MMS isn't empty}

[Cancel] [Ask later {?}] [Next >>>] {presumably 'Next' opens a variant of the sync dialog?}


---------------------
{This version is shown for an empty MM5 Library, i.e. after a fresh MM5 installation}

A new MediaMonkey Server was detected. It can be used to store and share portions of your library content even if this copy of MediaMonkey isn't running. Any content on the MediaMonkey Server can be managed using MediaMonkey as if the content were local, provided that both MediaMonkey and MediaMonkey Server are on the same network. If the devices will sometimes be on different networks, you may want to cache some content locally.

Do you want to Scan its content to your local Library?

[x] Scan MediaMonkey Server content to the local library
. . [ ] Cache the content locally {this option should only be shown if the MediaMonkey Server is on a different machine}

[Cancel] [Ask later {?}] [Next >>>] {note: I changed 'OK' to 'Next' because shouldn't the user be given a choice of which content to cache? Otherwise this can take forever!}
--------------------
Questions:

Question1: Does the proposed workflow support case 2a)? The workflow seems to assume that the user has scanned into MMS all content that exists in the library and is stored to the server. If the user hasn't done so (i.e. only a partial scan has been completed), then will metadata from MM5 get associated with content on the server (i.e. will MM5 cause the server to add content directly from the MM5 DB)?

Question2: Presumably when MMS conten is 'scanned', this will be a sync operation avoiding the creation of duplicates?

jiri

2018-11-01 09:06

administrator   ~0051519

re. Q1: Yes, this is supposed to be done automatically after running the wizard. Since it isn't a local content, it isn't managed by the checkbox, so it'd probably be useful to mention it somewhere in the wizard, by a text shown when some non-local content is in the MM5 library.

re. Q2: Yes, the scan is supposed to be done in cooperation of MM5 and MMS, so that the result is as expected.

I think that Ludek can start the implementation, there might be just a slight text change as mentioned in Q1.

peke

2018-11-01 11:24

developer   ~0051520

As talked with Rusty yesterday, I agree with all accounts.

I would only add to case 2 and 3 when Library content is detected to be on Network shares NAS, Other PC and there is no MMS installed. It would be nice to have some sort of notification that we also have MMS and that it can be installed and that "It can be used to store and share .... cache some content locally."

I'm proposing this as Most use case I think is 2. where MM5 was managing library that is already on NAS and UNC path.

Ludek

2018-11-01 17:47

developer   ~0051521

Last edited: 2018-11-01 18:07

View 7 revisions

I have implemented the first version of the migration wizard in build 2131 per Rusty's proposals , but it needs some corrections/clarifications:

1) Jiri asked me to have the ability to show the wizard anytime later , so I added 'Show migration wizard...' and 'Open web configuration...' links to the MMS device profile, see:
https://www.dropbox.com/s/mspjgehj3oiaj2b/Screenshot%202018-11-01%2018.43.47.png?dl=0

2)
a) I left the 'scan' and 'cache' checkboxes independent from the 'move local content' checkbox, see:
https://www.dropbox.com/s/xxuh083qakif7z0/Screenshot%202018-11-01%2018.28.22.png?dl=0
The reason is that user may want to scan and cache the MMS content even if he doesn't wish to migrate the current local content?
b) You suggested for the 'move local content' checkbox to be unchecked by default.
But what should happen once the checkbox is unchecked? Should be the [next] button be changed to [ok] button and vise versa (depending on the 'move local content' checkbox state) ??
c) My understanding from your proposal is that that the content isn't actually moved until the 'Cache the content' checkbox is unchecked, is this right?
But if the 'Cache the content' checkbox is unchecked -- shouldn't the action of moving be permanent? i.e. anytime later on any sync operation all local files should be automatically moved to MMS (not just copied), right?

If yes, then I think we need to adjust current 'Remote content' page of the profile ( https://www.dropbox.com/s/mspjgehj3oiaj2b/Screenshot%202018-11-01%2018.43.47.png?dl=0 )
to better indicate that the '[x] Download MMS content missing from the library' corresponds to 'Cache the content locally' checkbox?
Ideally the wording should be the same for both the checkboxes? And also indicate (in a tooltip?) that the checkbox also influences whether local content will be copied or migrated during the sync operation.
Maybe a beter wording could be '[x] Keep files cached locally' and should be independent from the 'scan' checkbox. BTW: The 'Scan' checkbox also needs to be unified with the '[x] Add links to MMS content missing from the library'

EDIT: Thinking about it further I guess that the checkbox influencing whether local content should be migrated or copied should rather belongs to the 'Library content' page of the profile?? i.e. We may want to make both the checkboxes independent.
i.e. '[x] Download MMS content' content on the 'Remote content' page shouldn't be related to '[x] Keep files cached locally' on the 'Library content' page that should be rather changed to something like '[ ] Delete local copies after sync' ???

3) In the [Next] step of the migration wizard: https://www.dropbox.com/s/adwoss12i31k8wn/Screenshot%202018-11-01%2018.45.20.png?dl=0
I would suggest to change the 'Choose which library content to sync' to 'Choose which library content to migrate' ? But the 'migrate' versus 'sync' should probably vary on the state of 'Cache the content locally' checkbox?

rusty

2018-11-14 17:38

administrator   ~0051542

Based on offline discussions, we've updated the workflow as shown.
New Mockup 3.png (474,458 bytes)

Ludek

2018-11-19 10:55

developer   ~0051567

Last edited: 2018-11-30 23:51

View 3 revisions

Implemented in MMS 0.2.0 / MM5 2136

rusty

2018-12-05 19:06

administrator   ~0051674

Tested MMS .2.1 / MM5 2136 and noticed the following issues as they relate to the current design--i.e. These are just suggested tweaks to the current design (along with a couple of questions):

1) When the migration wizard is run, the window showing 'x files will be scanned...' flashes 3 times with different messages before the final message appears. This will be partially resolved in item 4.

2) In a scenario where MMS is run on the same machine as MM5, and MM5 has a mix of local content and networked content, the dialog indicates:

w files at C:\ will be scanned and accessed via MediaMonkey Server - OK
x files at \\192.168.... will be scanned and accessed via MediaMonkey Server - a) is this correct? I would have thought that content that isn't local would be copied/moved to the MMS server?!
y files at D:\ will be scanned and accessed via MediaMonkey Server - OK
1 audio files at remote storages will be copied to MediaMonkey Server (C:/Users/Russell/Music) - b) What is 'remote storages' ?

c) '1 audio files' is grammatically incorrect (for singular it should be '1 audio file'. Note : to simplify, we could just have strings for 'file' and 'files' and change messages along the following lines:
C: (1 file) will be scanned and accessed via MediaMonkey Server
D: (y files) will be scanned and accessed via MediaMonkey Server

3) Seeing the wizard in operation, I'm reluctant to commit the change to my library because it's not clear whether there's a way to undo these changes and/or how much data will be lost by undoing them manually. Let's discuss.

4) 'Keep this content locally cached' is confusing because:
a) 'keep' implies that it's already cached
b) 'this content' is unclear which content it's referring to (is it all of the content from the server/selected content OR just the selected content that has been migrated)?
c) Enabling/Disabling it causes the description of which content is going to be migrated/cached to change. This isn't a problem except for the fact that the list appears _above_ rather than _below_.

Summary of changes related to this item:
By default, this wizard migrates all MediaMonkey data and content to the MediaMonkey Server
Fine-tune which content to store on MediaMonkey Server...
[ ] Retain local cache of MediaMonkey Server content (TBD depending on outcome of our discussion re. 4b)
--------------------------------------
Box with summary
--------------------------------------

5) Limit content to store on MediaMonkey Server... --> Fine-tune which content to store on MediaMonkey Server...

Ludek

2018-12-07 09:51

developer   ~0051690

Last edited: 2018-12-07 10:33

View 2 revisions

2a) Yes, this is correct (based on conclusion via the spaghetti email discussion), i.e. content on the local network is considered as local (always accessible)
2b) 'remote storages' are cloud storages, I renamed it to 'Cloud' in 2138 (note that checking to which cloud location(s) track belongs would be time consuming during the calculation, so I left only 'cloud' for the streamed tracks).

1/2c/4/5 are fixed in 2138

Ludek

2019-01-11 15:13

developer   ~0052038

Last edited: 2019-02-06 17:03

View 7 revisions

Re-opened:
1) Currently MMS can detect and map files in UNC form, but it cannot compare and match UNC path with /mnt/storage/... (e.g. on Synology NAS), this results in unnecessary copying.
To be resolved by creating a temporal testing file that MMS would try to find (to be sure that it is the same storage)

6) UI issues when MM5 is initally empty (regression)
=> Fixed in 2155

7) UI is frozen while scanning MMS (regression) -- related to 0015432
=> Fixed in 2155

Ludek

2019-02-20 18:10

developer   ~0052719

Item 1 (UNC > linux path mapping) is fixed in the next MMS build

peke

2019-04-23 01:25

developer   ~0053324

8) NAS collection still shows /share/Multimedia/Music/ that result in doubles as MM5 paths for same files are /Multimedia/Music

We should consider create algorithm that can better map shared Folders and not duplicate/mix with local folders.

Expected Behavior would be that below paths are paired and import correctly as same paths/files:
/share/Multimedia/Music
\\192.168.1.200\Multimedia\Music

Ludek

2019-04-24 08:10

developer   ~0053336

Last edited: 2019-04-24 08:16

View 3 revisions

Could you please write down exact UNC path and path on NAS ?

I have implemented following mappings so far:
CASE1: '\\NAS\music\...' mapped to '/volume1/music/...' (on Synology, Linux)
CASE2: '\\NAS\music\...' mapped to '/var/services/music/...' (on Synology)
CASE3: '\\NAS\share\...' mapped to '/mnt/share/...' (mount points on Linux)

i.e. if MMS gets UNC path from MM5 like '\\NAS\music\...' then it tries to map it per cases above (checks file for accessibility and compares file size), if the mapping fails then it tries to map '\\NAS\music\...' to user configured music collection folder (via MMS web api).
So your case looks like CASE1, but instead of /volume1/ you are using /share/ ? Or by 'share' do you mean a general share?

peke

2019-04-25 00:29

developer   ~0053345

Last edited: 2019-04-25 01:44

View 2 revisions

Sent you offline, mine and users List of Shared folders.

Tested on My QNAP Using RAID1 and users using RAID5 and results are that QNAP allocate "HDA_DATA" to "HDZ_DATA" for each HDD tray if no RAID is used (hence "HDC_DATA" and "HDD_DATA" as they are mounted HDDs), "MD0_DATA" for MirrorDisk RAID1 (hence non raid starts from "HDC_DATA" as "HDA_DATA" and "HDB_DATA" are part of "MD0_DATA"), "CACHEDEV1_DATA" for RAID5/6 array.

Ludek

2019-04-25 16:48

developer   ~0053369

Thank you, added the mappings for the next MMS build: https://github.com/mediamonkeyserver/mms/commit/6b36769a86f45d9c9298961be271d3e21b633f65