0006491: MTP Devices should use root folder for in-place configuration - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0006491	MMW v4	Synchronization	public	2010-09-20 22:15	2011-05-29 01:13

Reporter	rusty	Assigned To
Priority	urgent	Severity	feature	Reproducibility	always
Status	closed	Resolution	fixed
Product Version	4.0
Target Version	4.0	Fixed in Version	4.0

Summary	0006491: MTP Devices should use root folder for in-place configuration
Description	WMDM support should be improved so that such devices show a folder structure similar to that of the iPhone (i.e. Artist, Album, ...) instead of the current folder structure that reflects folders on the device. Once this is done, the root folder can be modified with an in-place configuration dialog similar to that of the iPhone/iPod.
Additional Information	More details of how this should work: 1. After a device is connected or otherwise recognized by MM, MM will ask the device for its content, so that it can be later reused for showing the content or deciding what to synchronize. Technical: We will call DEVICE_ListContent() method for this purpose, it will return the complete content of the device. The result will be used to correctly populate device nodes and their content, it will also be used during auto-sync, when this function won't be called again, but the initial results will be re-used. 2. For devices that have their internal DB, we are done after step 1, but since this isn't case of most of the devices, we have to manage a background scanning - as will be the case of all d_WMDM devices. Since this operation can take quite a long time on large devices, and user might want to browse the device immediately, we should use the internal list from last synchronization until the device is scanned. While this initial scan is in progress, we probably should make this somehow apparent, e.g. by adding ' (scanning...)' after device title? It might also be some animated icon, but it should be clear, that it isn't a synchronization, but a scan only. Technical: DEVICE_ListContent() would have possible return values (it has to be modified to return such values): a. Complere - Device scan is complete. b. Incomplete - Returned data are only partial, scanning continues in the background and DEVICE_ListContent() should be called again soon, in order to get more results. c. Error - Some problem occurred. So MM will continually (upon more DEVICE_ListContent() calls) get more and more content from the device. During this time it might be useful to always merge the partial results from the device with the full results from the last synchronization, so that the full content (presumably) of the device could be shown. 3. Using DEVICE_ListContent() we get only a list of filenames stored in device, it doesn't return any metadata. This is mainly because there isn't any fast way to get metadata in case of most devices and so it will be better to show metadata based on values retrieved from MM DB - this will certainly work only for tracks synchronized by MM, for tracks that got to the device by different means, we will have to get metadata from the device. Technical: We will have to add a new device plug-in function DEVICE_GetFileMetadata( fname: PChar; trackcookie: integer) that will be called for tracks that weren't synced by MM and so their metadata have to by retrieved from the device. These calls will also proceed on the background during the initial scan. The tree nodes structure of each device node should be like: +Music +Videos // These nodes would be visible only when device has at least one +Audiobooks +Podcasts +Locations These nodes could be expandable, but I wouldn't consider it the top priority, since Browser can be used for this purpose and implementation of this feature would probably take a while. Alternatively, we could re-use main tree structure, i.e. show a node for each visible Collection from the main tree (in case it has at least 1 track on the device). Might be a little slower and harder to implement, but would probably be nicer?
Tags	No tags attached.

Fixed in build	1317

Ludek 2010-10-11 13:45 developer ~0020723	Fixed in build 1316.

Ludek 2010-10-14 18:20 developer ~0020771 Last edited: 2010-10-14 21:33	Various fixes and improvements in build 1317: - gradual tracklist filling - device starts background scanning once its node is accessed and not earlier - fixed a mem-leak Test note [added by Rusty]: this is also supposed to fix the fact that iPhone browsing and sync dialog don't show 'Composer'.

~~stephen_platt~~ 2011-05-29 01:13 developer ~0025747	verified 1381