vasanth Reporter
	Description • 10 years ago

Steps to reproduce:

1) Load multiple clips onto the SD card
2) Launch Video app and play few videos
3) Close the video app
4) Remove the SD card
5) Launch Video app again

Actual result: Thumbnails of earlier content is displayed for few seconds before enumerating the thumbnails of present content

Expected result: Thumbnails of the earlier content shouldn't be displayed.

	Preeti Raghunath(:Preeti)
	Comment 1 • 10 years ago

Vasanth,

Can you please help with a video here?

Also do we know if this is a regression?

	Preeti Raghunath(:Preeti)
	Comment 3 • 10 years ago

Vasanth

What is the tolerance allowed? One sec doesn't seem long.

What does Android time at?

	vasanth Reporter
	Comment 4 • 10 years ago

(In reply to Preeti Raghunath(:Preeti) from comment #3)
> Vasanth
> 
> What is the tolerance allowed? One sec doesn't seem long.
Its not long however clearly visible.

> What does Android time at?
Android never shows older clip thumbnails after old sdcard is removed.

	Preeti Raghunath(:Preeti)
	Comment 5 • 10 years ago

Dave

Seems like a new feature for SD card hot swapping. Please review

	Dave Hylands [:dhylands]
	Comment 6 • 10 years ago

This sounds like something similar to bug 1017144.

I think that the media db will get immediate notification that the media is missing.

However, even with immediate notification, and assuming somebody actually removes all of the entries from the database, it will still take time for that to happen.

So we probably need some logic in the mediadb and/or the apps using it to prune the list of available media when the media goes away.

Ultimately, you probably shouldn't even need to quite from the media app in question. Removing the sdcard should probably cause the display to immediately update minus the media that disappeared.

I think that this is a new feature and not a regression.

	Sandip Kamat
	Comment 7 • 10 years ago

Sri/Dave, can you pls assess the ETA of this one? In users' eyes, this would still be a bug.

	Sri Kasetti
	Comment 8 • 10 years ago

As Dave has indicated this is similar to 1017144.
In 1017144 we indicated that it is an enhancement request.
While I understand this has user experience impact, I don't think 
we can make this change for 2.0

	bhavana bajaj [:bajaj]
	Comment 9 • 10 years ago

(In reply to Sri Kasetti from comment #8)
> As Dave has indicated this is similar to 1017144.
> In 1017144 we indicated that it is an enhancement request.
> While I understand this has user experience impact, I don't think 
> we can make this change for 2.0

I think you meant 2.1.

GIven our offline discussion on email, I am NI jim to explain the risks/anaalysis that was communicated in our discussion.

	Jim Porter (:squib)
	Comment 10 • 10 years ago

This was in the context of the gallery bug, but the same thing probably applies here. I'll just quote my email:

I'm not entirely clear on what the goal is here, but "remove all of the old media when an sdcard is removed" sounds like what we're already doing:
https://github.com/mozilla-b2g/gaia/blob/master/apps/gallery/js/gallery.js#L325-L339

I'm also unsure that this improves security in a meaningful way, since it's probably not going to wipe anything if you remove the SD card while the gallery app *isn't* open. I'm reasonably sure that gallery stores thumbnail copies of images on internal memory (by way of indexedDB), so unless the gallery app gets notified of an SD card removal, an attacker would still be able to get access to (thumbnails of) the pictures. There's also the MediaDB itself, but I'm not sure what we put in there for gallery.

Probably the right way to fix this would be to have MediaDB be a daemon process of some kind that continually listens for file events and updates things appropriately, but I bet that would cause all sorts of chaos on low-memory devices. This would also have the happy consequence of eliminating the need for any of the media apps to actively "scan" for media.

	bhavana bajaj [:bajaj]
	Comment 11 • 10 years ago

CAF is removed this from 2.1 but they would like to see this fixed in the next FxOS release and looks like JIm has some thoguths.., not sure what the best way to put this in your product backlog is, so NI you so this is not lost.

	Hema Koka [:hema]
	Comment 12 • 10 years ago

I have added it to the 2.2 backlog for discussion and feasibility. Will update bug once planning is done. 

Thanks
Hema

	David Flanagan [:djf]
	Comment 13 • 10 years ago

As Dave and Jim have mentioned this is basically a MediaDB bug and is related to similar bugs that have been filed for Gallery. I've marked this as depending on bug 1046995 in which I hope to be able to resolve a lot of these issues.

For this particular bug, I think it must be on hardware that has both internal and external storage.  On devices that have only a single storage area, we should see a "no sdcard overlay" immediately when the app is started with the sdcard removed.

For devices that have two storage areas, the app can still run with the sdcard removed, and we just wait for the scan to happen to figure out which files are no longer accessible.  We could improve that process when enumerating files in the indexed db however. Each filename should identify the storage volume that is is part of. If that volume is not mounted, we can just not enumerate it (and possibly remove it from the db entirely).

	Sri Kasetti
	Comment 14 • 10 years ago

Added both 1021609 & 1046995 to the 2.2 list

	Stephany Wilkes
	Comment 15 • 10 years ago

I am the "new Sri" since he left Mozilla. Since then, the timeline for 2.2 has been cut to three sprints, so we can no longer commit this to the 2.2 backlog. We will, however, take it as we have time.

	BMO Automation
	Comment 16 • 7 years ago

Firefox OS is not being worked on