The default bug view has changed. See this FAQ.

Gaia video app doesn't play videos when run OOP

RESOLVED FIXED in mozilla17

Status

()

Core
Audio/Video
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: dhylands, Assigned: cjones)

Tracking

unspecified
mozilla17
ARM
Gonk (Firefox OS)
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-basecamp:+)

Details

(Whiteboard: [LOE:S])

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

5 years ago
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?
Blocks: 745143
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
Created attachment 654304 [details]
logcat output showing segfault and related debug output from running cubevid oop
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.

Comment 17

5 years ago
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?

Comment 18

5 years ago
We should capture a stack for this.
Depends on: 730765
Depends on: 782456
Created attachment 655354 [details] [diff] [review]
Hack

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?
Created 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

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 21

5 years ago
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]
https://hg.mozilla.org/integration/mozilla-inbound/rev/af3d98089970
Duplicate of this bug: 779156
Duplicate of this bug: 779153
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.

Comment 30

5 years ago
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
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
You need to log in before you can comment on or make changes to this bug.