Closed Bug 782460 Opened 12 years ago Closed 12 years ago

Gaia video app doesn't play videos when run OOP

Categories

(Core :: Audio/Video, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla17
blocking-basecamp +

People

(Reporter: dhylands, Assigned: cjones)

References

Details

(Whiteboard: [LOE:S])

Attachments

(1 file, 2 obsolete files)

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.
blocking-basecamp: ? → +
The music app and gallery apps seem to be able to use mediastorage + IDB just fine when OOP.  Why is Video different?
Summary: Video shows black screen when run OOP → Gaia video app doesn't seem to find any videos when run OOP
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.
Whiteboard: [LOE:S]
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?
Assignee: nobody → dale
Summary: Gaia video app doesn't seem to find any videos when run OOP → Gaia video app doesn't play videos when run OOP
Possibly related to bug 778300.
Assignee: dale → nobody
Component: General → Video/Audio
OS: Linux → Gonk
Product: Boot2Gecko → Core
Hardware: x86_64 → ARM
Whiteboard: [LOE:S] → [LOE:?]
Guys, audio and video seems completely broken from content processes on Gonk.  Assigning to myself, but we could really use some help here.
Assignee: nobody → jones.chris.g
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.
Attached patch Hack (obsolete) — Splinter Review
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 ...
Attachment #654304 - Attachment is obsolete: true
Attachment #655354 - Attachment is obsolete: true
Attachment #655361 - Flags: review?(justin.lebar+bug)
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.
Attachment #655361 - Flags: review?(justin.lebar+bug) → review+
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.
Attachment #655361 - Attachment description: part 1: 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 → 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
Whiteboard: [LOE:?] → [LOE:S]
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.
https://hg.mozilla.org/mozilla-central/rev/af3d98089970
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: