1107146 - [MTP] MTP does not transfer files from windows media player

Status: VERIFIED FIXED

(Firefox OS Graveyard :: MTP/UMS, defect)

Description

[[:RJ]]

Attachment: MTPlog.txt

Description:
MTP does not transfer music files from windows media player


Repro Steps:
1) Update a Flame to 20141203040207
2) start pc > boot windows 
3) Enable MTP > plug into PC
4) In windows media player go to sync options and sync a song to flame 


Actual:
while PC says files were synced no files were synced 


Expected:
while PC says files were synced files are synced

Environmental Variables:
Device: Flame 2.2 (319mb)(Kitkat Base)(Full Flash)
Build ID: 20141203040207
Gaia: 725685831f5336cf007e36d9a812aad689604695
Gecko: 2c9781c3e9b5
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 37.0a1 (2.2)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0


Repro frequency:100%
Link to failed test case: https://moztrap.mozilla.org/manage/case/14300/
See attached:logcat

Comment 1

[[:RJ]]

feature was not implemented in  2.1 flame  2.0 flame
Ftu pops up before email app is launch
Flame 2.1 

Device: Flame 2.1 (319mb)(KitKat)(Full Flash)
Build ID: 20141203001205
Gaia: dbaf3e31c9ba9c3436e074381744f2971e15c7bf
Gecko: ebce587d2194
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 34.0 (2.1)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Flame 2.0 

Device: Flame 2.0 (319mb)(KitKat)(Full Flash)
Build ID: 20141203000201
Gaia: 8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko: 29222e215db8
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 32.0 (2.0)
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 2

[KTucker [:KTucker][Inactive 3/4/2016]]

RJ, please attach a video. Thanks

Comment 3

[[:RJ]]

https://www.youtube.com/watch?v=XPE-C53w808, here is the video of the issue

Comment 4

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Unsure how important the sync option might be from windows media player. NI settings owner for a blocking decision on this

Comment 5

[Gerry Chang [:gchang]]

NI MTP owner for this issue.

Comment 6

[Alison Shiue]

[Blocking Requested - why for this release]:

MTP is 2.1 feature, storage of 2.1 build event could not be detected by windows media player. 
nominate blocking 2.1

Comment 7

[Ben Tian (inactive)]

Eden is checking this MTP bug. Assign owner to him.

Comment 8

[howie [:howie]]

Triage: blocking.

Comment 9

[Eden Chuang[:edenchuang]]

The problem also appears while transferring a hierarchical directories structure form host(PC) to device.

following is the log that transferring a 'test' directory and a file 'testdoc' under 'test'.

846 12-11 03:45:04.877  6278  7204 D MtpServer: path: /storage/sdcard1/test parent: 0 storageID: 00020001
847 12-11 03:45:04.877  6278  7204 I MozMtp  : beginSendObject: Handle: 0x00000003 Parent: 0xffffffff Path: '/storage/sdcard1/t    est'
848 12-11 03:45:05.037  6278  7204 I MozMtp  : endSendObject: Handle: 0x00000003 Path: '/storage/sdcard1/test'
849 12-11 03:45:05.037  6278  6278 I Gecko   : DSF (parent) file-watcher-update: mStorageType 'sdcard' mStorageName 'sdcard1' m    RootDir '' mPath 'test' mFile->GetPath '/storage/sdcard1/test'
850 12-11 03:45:05.037  6278  6278 I MozMtp  : Observe: file-watcher-update: file test modified
851 12-11 03:45:05.047  6278  7204 I MozMtp  : getObjectInfo: Handle: 0x00000003 Display:'test' Object:'test'
852 12-11 03:45:05.047  6278  7204 I MozMtp  : getObjectPropertyList: Handle: 0x00000003 Format: 0x00000000 aProperty: 0xffffffff aGroupCode: 0 aDepth 0
853 12-11 03:45:05.047  6278  6278 I Gecko   : DSF (parent) file-watcher-update: mStorageType 'sdcard' mStorageName 'sdcard1' m    RootDir '' mPath 'test' mFile->GetPath '/storage/sdcard1/test'
854 12-11 03:45:05.047  6278  6278 I MozMtp  : Observe: file-watcher-update: file test modified
855 12-11 03:45:05.047  6278  7204 I MozMtp  : getObjectFilePath: Handle: 0x00000003 FilePath: '/storage/sdcard1/test'
856 12-11 03:45:05.057  6278  7204 D MtpServer: path: /storage/sdcard1/test/testdoc parent: 3 storageID: 00020001
857 12-11 03:45:05.057  6278  7204 I MozMtp  : beginSendObject: Handle: 0x00000004 Parent: 0x00000003 Path: '/storage/sdcard1/test/testdoc'
858 12-11 03:45:05.057  6278  7215 I MozMtp  : FileWatcherUpdate: file /storage/sdcard1/test modified
859 12-11 03:45:05.057  6278  7215 I MozMtp  : FileWatcherUpdate: About to call sendObjectRemoved Handle 0x00000003 file /stora    ge/sdcard1/test
860 12-11 03:45:05.057  6278  7215 I MozMtp  : CreateEntryForFileAndNotify: About to call sendObjectAdded Handle 0x00000005 fil    e /storage/sdcard1/test
861 12-11 03:45:05.067  6278  7204 I MozMtp  : endSendObject: Handle: 0x00000004 Path: '/storage/sdcard1/test/testdoc'
862 12-11 03:45:05.067  6278  7204 E MozMtp  : getObjectInfo: Handle 0x00000004 is invalid
863 12-11 03:45:05.067  6278  7204 E MozMtp  : getObjectInfo: Handle 0x00000004 is invalid

At line 847, host starts to transfer the directory 'test', and at line 848, host finishes 'test' transferring. According to the source code of endSendObject(), it will file a file modified event to others.

http://dxr.mozilla.org/mozilla-central/source/dom/system/gonk/MozMtpDatabase.cpp#653

At line 857, host starts to transfer the file 'testdoc'. Before 'testdoc' transferring finishes, MozMtpDatabase receives the 'test' modified event which filed by endSendObject(). According to MozMtpDatabase::FileWatcherUpdate(), once we receive a modified event, we first remove the entry and then re-create the entry for it. Therefore, the entry of 'test' is changed from 0x00000003 to 0x00000005. Then 'testdoc' transferring finishes, but it parent is not valid, it also make its entry 0x00000004 becomes an invalid entry. And then host receives file transferring fail. 

I guess we should file a 'created' not 'modified' event in endSendObject().

Comment 10

[Ben Tian (inactive)]

ni? EPM Howie to restore 2.1+ flag accidentally removed by comment 9.

Comment 11

[Dave Hylands [:dhylands]]

OK - we can get file-watcher-update events from 2 sources:
1 - DeviceStorage modifying a file.
2 - MTP host modifying a file.

When device storage modifies the file, its ok for us to do the delete/create and assign a new entry id.

When the MTP host modifies a file, we MUST NOT change the entry id.

So I think that what we need to do is to create a variable which tracks this information for us.

I think it should be a member variable in MozMtpDatabase, and it should have accessor routines that assert that they're being called while on the main thread. Let's say we call them:

bool IsFileUpdatedByMtp();
void SetFileUpdatedByMtp(bool aUpdatedByMtp);

Then in FileWatcherNotifyRunnable::Run we'd set/unset around the call to NotifyObservers like so:

> mMozMtpDatabase->SetFileUpdatedByMtp(true);
> obs->NotifyObservers(...)
> mMozMtpDatabase->SetFileUpdatedByMtp(false);

(note - you'll need to add mMozMtpDatabase to FileWatcherNotifyRunnable)

then in FileWatcherUpdate::Observer (in MozMtpServer.cpp) we'd pass mozMtpDatabase->IsFileUpdatedByMtp() as an additional argument to the FileWatcherUpdateRunnable constructor (we're still on the main thread) and pass that through as an argument to MozMtpDatabase::FileWatcherUpdate.

FileWatcherUpdate runs on the I/O Thread, so it isn't safe to access the IsFileUpdatedByMtp directly. It MUST come as an argument to the function.

If the file was updated by MTP, then we need to modify the logic to not remove and re-add the entry, and we also don't need to notify MTP about the change (since the change was originated by MTP in the first place).

Does this all make sense?

Comment 12

[Alphan Chen [:alchen]]

Hi Dave,
I can find one problem when using the way you mentioned.
If user transfer the file by MTP and take picture (or other behavior to create a file), the picture which user take won't add to the database in this case.

So my proposal is add a member variable in entry class but not in MozMtpDatabase.

Comment 13

[Alphan Chen [:alchen]]

What's your opinion if we add a member variable in the entry class?

Comment 14

[Eden Chuang[:edenchuang]]

Hi Dave

I tried the solution mentioned in comment 11 and comment 12. But the problem is not resolved.
Following is the log of fail case

942 12-15 05:11:21.150   208  1456 I MozMtp  : beginSendObject: Handle: 0x00000006 Parent: 0xffffffff Path: '/storage/sdcard/IM    G_3883.JPG'
943 12-15 05:11:21.370   208  1456 I MozMtp  : endSendObject: Handle: 0x00000006 Path: '/storage/sdcard/IMG_3883.JPG'
944 12-15 05:11:21.370   208   208 I Gecko   : DSF (parent) file-watcher-update: mStorageType 'sdcard' mStorageName 'sdcard' mR    ootDir '' mPath 'IMG_3883.JPG' mFile->GetPath '/storage/sdcard/IMG_3883.JPG'
945 12-15 05:11:21.370   208   208 I MozMtp  : Observe: file-watcher-update: file IMG_3883.JPG modified
946 12-15 05:11:21.370   208   208 I Gecko   : DSF (parent) file-watcher-update: mStorageType 'pictures' mStorageName 'sdcard'     mRootDir '' mPath 'IMG_3883.JPG' mFile->GetPath '/storage/sdcard/IMG_3883.JPG'
947 12-15 05:11:21.370   208   208 I MozMtp  : Observe: file-watcher-update: file IMG_3883.JPG modified
948 12-15 05:11:21.370   208  1467 I MozMtp  : FileWatcherUpdate: file /storage/sdcard/IMG_3883.JPG modified
949 12-15 05:11:21.370   208  1467 I MozMtp  : FileWatcherUpdate: About to call sendObjectRemoved Handle 0x00000006 file /stora    ge/sdcard/IMG_3883.JPG
950 12-15 05:11:21.380   208  1456 E MozMtp  : getObjectInfo: Handle 0x00000006 is invalid
951 12-15 05:11:21.380   208  1456 E MozMtp  : getObjectInfo: Handle 0x00000006 is invalid
952 12-15 05:11:22.390   208  1467 I MozMtp  : CreateEntryForFileAndNotify: About to call sendObjectAdded Handle 0x00000007 fil    e /storage/sdcard/IMG_3883.JPG

At line 950, after file transferring finishes, MTP server will ask to execute getObjectInfo() to get the new object information by the object handler created in beginSendObject(). I found that we cannot change the entry number before the getObjectInfo() executed.

We can avoid changing the entry number for the first modified event(line 945) which broadcasted in endSendObject() by solution mentioned in comment 11 and 12. However, the one of observers seem will trigger another modified event(line 947), and the entry number is still changed before getObjectInfo() and get an invalid entry number.

Comment 15

[Eden Chuang[:edenchuang]]

I think the following concept mentioned in comment 11 is correct.

When device storage modifies the file, its ok for us to do the delete/create and assign a new entry id.
When the MTP host modifies a file, we MUST NOT change the entry id.

So, I suggest that add an attribute mUpdatingByMTP in DbEntry to record if the entry is updating by MTP or not.
mUpdatingByMTP will set as true while entry is created in beginSendObject(), and we check the attribute in FileWatcherUpdate(), once the mUpdatingByMTP is true, FileWatcherUpdate() does nothing and return. Until the getObjectInfo() is called for the entry, we set the entry's mUpdatingByMTP as false.

Comment 16

[Dave Hylands [:dhylands]]

(In reply to Alphan Chen[:Alphan] from comment #12)
> Hi Dave,
> I can find one problem when using the way you mentioned.
> If user transfer the file by MTP and take picture (or other behavior to
> create a file), the picture which user take won't add to the database in
> this case.
> 
> So my proposal is add a member variable in entry class but not in
> MozMtpDatabase.

file-watcher-update events (which result from say a new camera photo being taken) all take place on the main thread:
http://dxr.mozilla.org/mozilla-central/source/dom/system/gonk/MozMtpServer.cpp#102

FileWatcherRunnable::Run also runs on the main thread, so these 2 things will be serialized.
http://dxr.mozilla.org/mozilla-central/source/dom/system/gonk/MozMtpDatabase.cpp#218

The issue I see with adding something to the entry is that we don't have any assurances that it will get unset.

Comment 17

[Eden Chuang[:edenchuang]]

Hello Dave 

Could you give some comment about comment 14? Thanks.

Comment 18

[Ben Tian (inactive)]

Hi Jan,

Since Dave is in PTO and you are one of DeviceStorage module owners, can you help advise on this MTP bug about comment 14 & 15?

This bug happens when user sync folder containing files from PC to device via MTP. In comment 11 Dave proposed an approach and Eden suggested a revised one in comment 15 (based on problem in comment 14). Please let us know your opinion on Eden's suggestion.

Comment 19

[Eden Chuang[:edenchuang]]

Attachment: bug1107146_do_not_modify_the_Mtp_DbEntry_while_it_is_being_updated_from_the_host

I had studied the MTP file transferring flow, and following is the steps 

1. Host send file transferring request and corresponding file information to MTP server
2. Once MTP server accepts and executes the request, MTP server needs create a MTPObjectHandle to process the file transferring (what we do in MozMtpDatabase::beginObjectSend())
3. Host transfers file to device
4. After file transferring finishes, host sends the query request to MTP server to refresh the information in the client. It will reuse the MTPObjectHandle which created by MTP server to query the corresponding object information. 

Notice that since the step 4 reuses the MTPObjectHandle created in step 2, we cannot modify our DbEntry before the step 4 executed.

This is the root cause why Dave's solution in comment 11 cannot work. We only block the file-watch-modified event from MTP host, but we do not block the file-watch-modified event from devicestroage. And according to comment 14, we found that file-watch-modified event from MTP host always triggers another file-watch-modified event from devicestroage.

According to my study, the following three functions must be executed in sequence during file transferring flow
1. MozMtpDatabase::beginSendObject() in step 2
2. MozMtpDatabase::endSendObject() in step 3
3. MozMtpDatabase::getObjectInfo() in step 4

To ensure the DbEntry would not be modified during the file transferring, I added an attribute "mUpdatingByMTP" in DbEntry to indicate the if the entry is updating by MTP. According to the file transferring flow, we set "mUpdatingByMTP" as true when we create the entry in beginObjectSend() and set it as false while corresponding getObjectInfo is called().

We needn't to worry about that if another query request before the query request in the step 4. Since MTP guarantees that doing one thing at the same time, before file transferring completion, no other request will be executed.

Dave, cloud you give any comments or concerns about this solution? Thanks.

Comment 20

[Alphan Chen [:alchen]]

One more idea, how about we add a updateEntry function to replace deleteEntry and addEntry when receiving "modified" event?

updateEntry : update the latest information into specify entry without changing the handle number.

Comment 21

[Alphan Chen [:alchen]]

Attachment: (0105) Add an UpdateEntryAndNotify for modified event

Here is my idea.
I add UpdateEntryAndNotify for modified event.

If we have this handle, use UpdateEntryAndNotify.
Otherwise, use "CreateEntryForFileAndNotify".

Comment 22

[Jan Varga [:janv]]

Sorry I didn't work much around holidays, do you still need my help ?

Comment 23

[Ben Tian (inactive)]

Hi Jan, Dave is also back from PTO so we'll wait for him a couple of more days. Thanks anyway:)

Also can we request your review on other Firefox OS device storage patches afterwards? We usually request Dave's review but wonder if you're available as well in case Dave is in PTO.

(In reply to Jan Varga [:janv] from comment #22)
> Sorry I didn't work much around holidays, do you still need my help ?

Comment 24

[Jan Varga [:janv]]

(In reply to Ben Tian [:btian] from comment #23)
> Also can we request your review on other Firefox OS device storage patches
> afterwards? We usually request Dave's review but wonder if you're available
> as well in case Dave is in PTO.

I would say yes for simple patches, since this is not my primary area of expertise.

Comment 25

[Dave Hylands [:dhylands]]

(In reply to Eden Chuang[:edenchuang] from comment #14)
> Hi Dave
> 
> I tried the solution mentioned in comment 11 and comment 12. But the problem
> is not resolved.
> Following is the log of fail case
> 
> 942 12-15 05:11:21.150   208  1456 I MozMtp  : beginSendObject: Handle:
> 0x00000006 Parent: 0xffffffff Path: '/storage/sdcard/IM    G_3883.JPG'
> 943 12-15 05:11:21.370   208  1456 I MozMtp  : endSendObject: Handle:
> 0x00000006 Path: '/storage/sdcard/IMG_3883.JPG'
> 944 12-15 05:11:21.370   208   208 I Gecko   : DSF (parent)
> file-watcher-update: mStorageType 'sdcard' mStorageName 'sdcard' mR   
> ootDir '' mPath 'IMG_3883.JPG' mFile->GetPath '/storage/sdcard/IMG_3883.JPG'
> 945 12-15 05:11:21.370   208   208 I MozMtp  : Observe: file-watcher-update:
> file IMG_3883.JPG modified
> 946 12-15 05:11:21.370   208   208 I Gecko   : DSF (parent)
> file-watcher-update: mStorageType 'pictures' mStorageName 'sdcard'    
> mRootDir '' mPath 'IMG_3883.JPG' mFile->GetPath
> '/storage/sdcard/IMG_3883.JPG'
> 947 12-15 05:11:21.370   208   208 I MozMtp  : Observe: file-watcher-update:
> file IMG_3883.JPG modified
> 948 12-15 05:11:21.370   208  1467 I MozMtp  : FileWatcherUpdate: file
> /storage/sdcard/IMG_3883.JPG modified
> 949 12-15 05:11:21.370   208  1467 I MozMtp  : FileWatcherUpdate: About to
> call sendObjectRemoved Handle 0x00000006 file /stora   
> ge/sdcard/IMG_3883.JPG
> 950 12-15 05:11:21.380   208  1456 E MozMtp  : getObjectInfo: Handle
> 0x00000006 is invalid
> 951 12-15 05:11:21.380   208  1456 E MozMtp  : getObjectInfo: Handle
> 0x00000006 is invalid
> 952 12-15 05:11:22.390   208  1467 I MozMtp  : CreateEntryForFileAndNotify:
> About to call sendObjectAdded Handle 0x00000007 fil    e
> /storage/sdcard/IMG_3883.JPG
> 
> At line 950, after file transferring finishes, MTP server will ask to
> execute getObjectInfo() to get the new object information by the object
> handler created in beginSendObject(). I found that we cannot change the
> entry number before the getObjectInfo() executed.

That's correct. According to the spec, we're not allowed to change the entry number for any files which we've told the host about in the current session.

We can cheat with files that were modified by the device, and make that modification look like a delete of the original file and an add of the new (modified file).

> We can avoid changing the entry number for the first modified event(line
> 945) which broadcasted in endSendObject() by solution mentioned in comment
> 11 and 12. However, the one of observers seem will trigger another modified
> event(line 947), and the entry number is still changed before
> getObjectInfo() and get an invalid entry number.

I think we need to do something to differentiate modified by host and modified by device events.

Comment 26

[Dave Hylands [:dhylands]]

Comment on attachment 8543877 [details] [diff] [review]
(0105) Add an UpdateEntryAndNotify for modified event

Review of attachment 8543877 [details] [diff] [review]:
-----------------------------------------------------------------

This looks good except for the locking. I'd like to see the function with proper locking.

Right now, the lock checking only happens in debug builds, so please test this in a debug build.

I'm not sure if the logging has improved yet to the point where we get useful information from mMutex.AssertCurrentThreadOwns() (in the ProtectedTArray class). When I wrote this it would just kill the program with no indication why, and I had to patch the NSPR logging to get useful assertions out.

::: dom/system/gonk/MozMtpDatabase.cpp
@@ +206,5 @@
>  
> +void
> +MozMtpDatabase::UpdateEntryAndNotify(MtpObjectHandle aHandle, DeviceStorageFile* aFile, RefCountedMtpServer* aMtpServer)
> +{
> +  RefPtr<DbEntry> entry = mDb[aHandle];

We need to be really careful about owning the mutex here.

You need to own the mutex BEFORE you can call mDb[Handle]

To be consitent with the other functions, lets split this into 2 functions, UpdateEntry (which should acquire the lock, do the update, and do the log.

Then UpdateEntryAndNotify will just call UpdateEntry and then call sendObjectAdded (it can use aHandle, since dereferencing entry->mHandle requires holding the lock).

@@ +323,2 @@
>      if (entryHandle != 0) {
> +      MTP_LOG("About to call Uodate Handle 0x%08x file %s", entryHandle, filePath.get());

nit: Update

Comment 27

[Dave Hylands [:dhylands]]

Comment on attachment 8541579 [details] [diff] [review]
bug1107146_do_not_modify_the_Mtp_DbEntry_while_it_is_being_updated_from_the_host

Review of attachment 8541579 [details] [diff] [review]:
-----------------------------------------------------------------

The problem I see with this is that it relies on the host calling getObjectInfo, and that isn't required by the spec. So we might wind up leaving mUpdatingByMtp set to true when it shouldn't be.

::: dom/system/gonk/MozMtpDatabase.cpp
@@ +1197,5 @@
>    }
>  
> +  if (entry->mUpdatingByMTP) {
> +    entry->mUpdatingByMTP = false;
> +  }

nit: I don't think we need to check. just set it to false

Comment 28

[Alphan Chen [:alchen]]

Attachment: (0113) Add an UpdateEntryAndNotify for modified event

Update a new version.

Comment 29

[Alphan Chen [:alchen]]

Change assignee.

Comment 30

[Dave Hylands [:dhylands]]

Comment on attachment 8548010 [details] [diff] [review]
(0113) Add an UpdateEntryAndNotify for modified event

Review of attachment 8548010 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good. Sorry to take so long to review. I should be caught up now.

Comment 32

[Alphan Chen [:alchen]]

Attachment: Add an UpdateEntryAndNotify for modified event. r=dhylands

Try server result looks fine.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=53c6bdb701ea

Comment 33

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/b2g-inbound/rev/fd5c7ee88faa

Comment 34

[Alphan Chen [:alchen]]

Comment on attachment 8555762 [details] [diff] [review]
Add an UpdateEntryAndNotify for modified event. r=dhylands

[Approval Request Comment]
Bug caused by (feature/regressing bug #): It is a bug of MTP implementation.
User impact if declined: User may meet problem when add a folder which has lots of files inside.
Testing completed: MTP testcases(http://goo.gl/sBCqy0) are passed. 
Risk to taking this patch (and alternatives if risky): (low risk) It is a correction.
String or UUID changes made by this patch: none

Comment 35

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/fd5c7ee88faa

Comment 36

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/83e718d1bc64

Comment 37

[Ryan VanderMeulen [:RyanVM]]

Looks like this still needs a b2g34 approval request given the 2.1+ blocking status?

Comment 38

[Alphan Chen [:alchen]]

Yes, we need to pick other 3 patches for 2.1. (Bug 1076715, Bug 1074593, Bug 1084180)
I will request b2g34 later.
Thanks for your reminder.

Comment 39

[Alphan Chen [:alchen]]

Attachment: (Bug-1076715) Add B2G Supported Playback Formats for device info. r=dhylands

[Approval Request Comment]
Bug caused by (feature/regressing bug #): It is some needed information by media player.
User impact if declined: User cannot detect mtp device by media player.
Testing completed: MTP testcases(http://goo.gl/sBCqy0) are passed. 
Risk to taking this patch (and alternatives if risky): (low risk) It just provides some needed information.
String or UUID changes made by this patch: none

Comment 40

[Alphan Chen [:alchen]]

Attachment: (bug 1074593) Add AddEntryAndNotify and RemoveEntryAndNotify for file/folder change when MTP in use. r=dhylands

[Approval Request Comment]
Bug caused by (feature/regressing bug #): It is a lack of MTP implementation.
User impact if declined: User cannot see new born folder immediately. He need to refresh again.
Testing completed: MTP testcases(http://goo.gl/ZiMnMu) are passed. 
Risk to taking this patch (and alternatives if risky): (low risk) It is a patch for the lack.
String or UUID changes made by this patch: none

Comment 41

[Alphan Chen [:alchen]]

Attachment: (bug 1107146) Refine RemoveEntry: Not only remove this entry but also its children if exist. r=dhylands

[Approval Request Comment]
Bug caused by (feature/regressing bug #): It is a bug of MTP implementation.
User impact if declined: User may meet problem when add a folder which has lots of files inside.
Testing completed: MTP testcases(http://goo.gl/ZiMnMu) are passed. 
Risk to taking this patch (and alternatives if risky): (low risk) It is a correction.
String or UUID changes made by this patch: none

Comment 42

[Alphan Chen [:alchen]]

Comment on attachment 8555762 [details] [diff] [review]
Add an UpdateEntryAndNotify for modified event. r=dhylands


[Approval Request Comment]
Bug caused by (feature/regressing bug #): It is a bug of MTP implementation.
User impact if declined: User may meet problem when add a folder which has lots of files inside.
Testing completed: MTP testcases(http://goo.gl/ZiMnMu) are passed. 
Risk to taking this patch (and alternatives if risky): (low risk) It is a correction.
String or UUID changes made by this patch: none

Comment 43

[Shally Li（leave from Mozilla）]

This bug has been successfully verified on latest Flame v2.2&3.0.
See attachment: verified_v2.2&3.0.mp4.
Reproduce rate: 0/5

STR:
1. Enable MTP on device.
2. Plug in USB cable. 
3. Open Windows media player on PC.
4. Go to sync options and sync a song to flame. 
5. Open Music on device.
**Files are synced successfully.

Flame 2.2 build:
Gaia-Rev        d6141fa3208f224393269e17c39d1fe53b7e6a05
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/f7414413e3a5
Build-ID        20150201002504
Version         37.0a2
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150201.043120
FW-Date         Sun Feb  1 04:31:31 EST 2015
Bootloader      L1TC000118D0

Flame 3.0 build:
Gaia-Rev        ab69ae06a7f2b54e60ab63b1b44c8d19d5d20d94
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/c2359a6a6958
Build-ID        20150201010217
Version         38.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150201.044915
FW-Date         Sun Feb  1 04:49:25 EST 2015
Bootloader      L1TC000118D0

----------------------------------------------------
Leaving "verifyme",waiting for flame v2.1 and firefox38 to verify.

Comment 44

[Shally Li（leave from Mozilla）]

Attachment: verified_v2.2&v3.0.mp4

Comment 45

[bhavana bajaj [:bajaj]]

Comment on attachment 8556838 [details] [diff] [review]
(bug 1074593) Add AddEntryAndNotify and RemoveEntryAndNotify for file/folder change when MTP in use. r=dhylands

[Triage Comment]

Comment 46

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/7209703b3339

Comment 47

[Shally Li（leave from Mozilla）]

This bug has been successfully verified on latest Flame v2.1.
See attachment: verified_v2.1.mp4.
Reproduce rate: 0/5

Flame 2.1 build:
Build ID               20150204002437
Gaia Revision          17bf14f12e43043654498330d610d469b8b55e64
Gaia Date              2015-02-03 05:19:41
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/bdebcc47ec7a
Gecko Version          34.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150204.035620
Firmware Date          Wed Feb  4 03:56:31 EST 2015
Bootloader             L1TC000118D0

Comment 48

[Shally Li（leave from Mozilla）]

Left for "firefox38".

Comment 49

[Vincent Liu[:vliu]]

https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/7209703b3339

Comment 50

[Shally Li（leave from Mozilla）]

This bug has been successfully verified on latest v2.1S.
Reproduce rate: 0/5

2.1S (256m) build:
Build ID               20150210002201
Gaia Revision          7dd130a312f12c89b2d41948f8557effa56afbf6
Gaia Date              2015-02-10 06:09:14
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/5017c32553c7
Gecko Version          34.0
Device Name            scx15_sp7715ga
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150210.040821
Firmware Date          Tue Feb 10 04:08:33 EST 2015

2.1S (512m) build:
Build ID               20150210161202
Gaia Revision          7dd130a312f12c89b2d41948f8557effa56afbf6
Gaia Date              2015-02-10 06:09:14
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/df6f80e36912
Gecko Version          34.0
Device Name            scx15_sp7715ea
Firmware(Release)      4.4.2
Firmware(Incremental)  122
Firmware Date          Thu Feb  5 12:42:58 CST 2015