View Issue Details

IDProjectCategoryView StatusLast Update
0014665MMW 5Syncpublic2020-11-15 22:23
Reporterrusty Assigned To 
PriorityurgentSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version5.0 
Target Version5.0Fixed in Version5.0 
Summary0014665: Cloud storage metadata issues
DescriptionThere are a number of issues for metadata synced to the cloud, preventing users from managing their cloud-stored library (tested with Google Drive):
1) All tracks synced to the cloud have messed up metadata. Tracks are missing all metadata except for Title which is appears as the filename!

2) For tracks synced to the cloud (but not scanned into the library), metadata is read-only. e.g. if the user navigates to Devices & Services > Google Drive > All Tracks, attempts to edit any fields fail!

3) If the user unchecks all content in the sync list, and then scans the cloud location and navigates to Devices & Services > Google Drive > All Tracks
--> The Tracks view is empty!

Note: Navigating to Devices & Services > Google Drive > Folders works as expected.

4) Attempts to edit metadata of cloud-based content after scanning cloud-based content to the library --> metadata was editable, but the functionality wasn't stable--I consistently observed crashes similar to that in 0014664.

5) When cloud storage is scanned into the library (i.e. if the user performs the steps in 3) above), the tracks don't appear in /Music. Presumably this is because all metadata is missing as described in 1).
TagsNo tags attached.
Attached Files
14665_1b_Properties.jpg (41,404 bytes)   
14665_1b_Properties.jpg (41,404 bytes)   
Fixed in build2094

Relationships

related to 0014664 closedLudek Crash on sync to Google Drive 
related to 0014693 closedLudek Numerous commands fail for tracks stored to the Cloud 
related to 0014899 feedbackLudek Cloud scanning: Feature to select which folders to scan 

Activities

Ludek

2018-03-08 20:44

developer   ~0049699

Last edited: 2018-03-09 16:31

1) I see, this happens when you browse the content via [Devices & Services > Google Drive > Folders] , when you go to [Devices & Services > Google Drive > All tracks] then all metadata are there.
=> Fixed in 2091

2) I cannot replicate, F2 edit always works for me to update the metadata, but editing via properties is read-only.
=> Fixed in 2091

3) I cannot replicate, but I've seen something similar once, but it was rather a content refresh issue. i.e. By a quick move from another node (with empty tracklist) to 'All Tracks' sometimes caused that content of the last node remains in the view although 'All tracks' is selected in the tree. I believe this is a regression to be looked into.

4) 0014664 is fixed in 2091

5) This is caused by the proposals of pairing the tracks with local copies, just go to [Music > Location > Google Drive] and you will see which local copies were assigned to the remote tracks. i.e. only those tracks that don't exist in MM5 library (based on metadata) are added to the library, otherwise they are just "linked" with already existing tracks (to prevent from duplicates)

rusty

2018-03-08 21:13

administrator   ~0049700

Re. 5) I had deleted the local copies from the library prior to scanning the cloud-based copies. In other words, after I scanned the items from the cloud, they simply didn't appear in the library. If you can't replicate, I'll retest once the other items in this bug are fixed.

Ludek

2018-03-09 19:50

developer   ~0049704

I think that the issues are mostly fixed in 2091.

Let's re-test in 2091 and report back in case you are still observing an issue.

peke

2018-03-16 21:44

developer   ~0049726

Verified 2091 left resolved till Rusty confirmation

rusty

2018-03-22 02:31

administrator   ~0049788

Tested 2093 and it's much improved, but I'm still seeing the following issues:

1) Metadata seems to mostly sync correctly however:
a) artwork isn't visible in A&D when the user selects a track in Google Drive > Folders view (it is visible in Google Drive > All Tracks view)
b) in the properties dialog, the filename entry is blank
c) When browsing in Music, there's no indication, in the Path (or anywhere else as far as I can see) that a file is stored to Gdrive. The only way to see that it's on Gdrive is to navigate to Folders > Gdrive

2) Partially verified. Tracks are updated in the library. Need to retest once 6) is fixed in order to verify whether the track tag is updated.

3) If the user selects and album and then Send to > Google Drive (synchronize), and then deletes the Album from the local library
--> The Album Remains visible in Google Drive > Folders > ...
--> The Album does not appear in Gooogle Drive > All Tracks
I'm not sure what the intended behaviour is, however, it should be consistent (this question relates to the usecase of users wanting to move content from their Local drive to Google Drive, and how to do so).

Note: this inconsistency doesn't exist for tracks that are auto-synced

6) If the user deletes a track from Google drive and opts to only delete the track from the Library (and not from Google drive), rescanning the drive fails to add it back to the library

Ludek

2018-03-22 17:03

developer   ~0049791

Last edited: 2018-03-22 18:25

re 1a) Yes, artwork isn't shown for remote tracks, currently the artwork and stream URL is getting on demand once track playback is started (e.g. for GPM). Or once the track is downloaded to local library (for all cloud storages). But you are true that even selecting the track should probably attempt to download/show the artwork in A&D window.

re 1b) the path is intentionally blank, because tracks in the cloud gets stream URl on demand and it expires in minutes, so you need to get another URL each time you want to access a cloud file. Also, e.g. Google Play Music has nothing like remote path. This is consistent with online tracks (e.g. in album "online" view)

re 1c) this is indicated via the 'Source' column that can be enabled in tracklisting (including the cloud icon)

3/6) In truth, I haven't tested the scenarios of deleting local tracks yet, it is TODO

rusty

2018-03-22 21:01

administrator   ~0049792

1a) What's the rationale for not syncing artwork? Is artwork 'lost' only for cloud storage and not when migrating content to MMS?

1b) The path was filled--it's the filename field that's empty!

1c) Thanks. I guess that we need to add this field to Properties (metadata should be visible in either the listview OR in Properties).

Ludek

2018-03-23 18:39

developer   ~0049796

Last edited: 2018-03-30 12:12

1a) The artwork isn't lost, it just isn't showing for remote content that's not scanned/downloaded. The issue is (related to 1b) that under D&S > Google Drive > Folders > ... it is showing the remote content (and not the library content), to be unified.

1b) I see, to be fixed

3) OK, I see this in the D&S > Google Drive > Folders... , reasons same as in 1a

1c) OK, I'll add an icon there (or something like this) next to the path

Ludek

2018-03-27 20:52

developer   ~0049818

Last edited: 2018-03-30 14:55

1a) remote artwork showing in A&D added in build 2094

1a/3) Fixed in build 2094. i.e. the [D&S > GDrive > All tracks] always shows the _real_ cloud (remote) content,
while [Music > Location > GDrive] always show the scanned local library content.

1b, 1c, 6) fixed in 2094

peke

2020-11-15 22:23

developer   ~0060239

Verified 2274

Gdrive, one drive, dropbox.