I I launch the video app OOP, then all I see is a black screen with the status bar (wifi/battery/time) When run non-OOP I see a list of videos to play.

The music app and gallery apps seem to be able to use mediastorage + IDB just fine when OOP. Why is Video different?

Nothing interesting in logcat, except I do see a surprising number of cycle collections on startup. No string in ((close)*(restart)*(go-to-homescreen)*(open-task-switcher)*)* that I've tried shows me video entries.

Bug 783184 doesn't make this work.

The video app is the neglected child of the media apps and its device storage code is out of date. Dale is working on it as we speak. This is probably just a Gaia bug. Adding dale to the cc list.

It works in-process. Do you have some sort of race condition in mind, maybe?

I haven't thought about why in process vs oop would break it, and I haven't looked at the code, but I thought you should know that Dale is currently in the middle of changing all that code.

Since gallery and music seem to be able to find files OOP, I'm going to assume whatever is bugging video is small and dumb. Maybe a gaia-only issue.

The app now find videos oop but doesnt play them, as david said I will be looking into it / fixing it / filing issues. I have a bunch of code to PR later today

Not playing videos is almost certainly a separate bug. Was the fix for finding videos all on the gaia side? If so, we can morph this bug into "videos not playing OOP", but the work estimate will change.

Yeh I didnt actually do anything, I had already switched Video to MediaDB locally and that 'just worked', repurposing this makes sense

(In reply to dale@arandomurl.com from comment #10) > Yeh I didnt actually do anything, I had already switched Video to MediaDB > locally and that 'just worked', repurposing this makes sense Done. Dale, are you the best owner here?

Possibly related to bug 778300.

Guys, audio and video seems completely broken from content processes on Gonk. Assigning to myself, but we could really use some help here.

cubevid seems to have the same (or similar) problem. Works on process, but fails (with segfault!) when run OOP. See attachment

This may be a separate bug from video playback, if the video app doesn't behave similarly.

I don't know much about B2G architecture - what's the difference between the browser app and the apps where video doesn't work? I can play videos fine in the browser. When did this issue start happening? Do you have a regression range?

We should capture a stack for this.

When testing bug 782456, I had a patch equivalent to this that forced all content processes to run with inherited privileges. With this patch, we find the list of videos, and without it, we don't. WTF?

Now need to see why things don't work when we're unprivileged ...

Comment on attachment 655361 [details] [diff] [review] Fix hal enum serializers, make wake lock permission checking match the DOM's, and log a message when an app process fails a backstop permission check Trivial. Stealing.

We're failing at rv = tmpFile->CreateUnique(nsIFile::NORMAL_FILE_TYPE, 0700); NS_ENSURE_SUCCESS(rv,rv); in nsMediaCache.cpp. The problem is /data/local/tmp # ls -l drwx------ root root 2012-08-25 15:03 mozilla-media-cache something has created the cache dir as root, and unprivileged content processes can't create files in there. Deleting the cache and then relaunching the video app makes it work OOP.

doublec, this is going to be a icky little footgun. Is there a reason we create a directory in which to store the cache files? Just cleanliness? We might need to create this as |mozilla-media-cache-$UID|.

Comment on attachment 655361 [details] [diff] [review] Fix hal enum serializers, make wake lock permission checking match the DOM's, and log a message when an app process fails a backstop permission check There's only one part here, thankfully.

Maybe I should have fixed those serializer bugs when I found them, instead of relying on the presumed owners to fix them. Sorry, Chris.

S'ok. They weren't The Real Bug here, I just stumbled across them in gdb.

Chris Pearce would know more about the reasoning behind the cache operation. Pinging him. Chris Pearce, please see comment 23.

Let's take that discussion to bug 785662.