Closed Bug 836643 Opened 11 years ago Closed 11 years ago

Here Maps voice navigation cuts out after a few seconds

Categories

(Tech Evangelism Graveyard :: Preinstalled B2G Apps, defect)

Product:
Tech Evangelism Graveyard
Component:
Preinstalled B2G Apps
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: cjones, Assigned: andy.tjin)

References

Details

(Whiteboard: [nptob]) 

STR
 (1) Choose route from A to destination B
 (2) (While bug 836640 is outstanding, choose the "walking" directions)
 (3) Wait for route to be computed, press "Play" (">") button

The audio starts to tell me initial instructions, but after a few seconds cuts out.
Blocks: b2g-maps
Retested on Unagi 20120702 and the audio seems to be playing correctly right now. Please confirm.
Chris Jones - Can you retest?
Flags: needinfo?(jones.chris.g)
I don't have time to test this outdoors, but I haven't received an update so I don't know what would have changed.
Flags: needinfo?(jones.chris.g)
Aha: I was lucky enough to get a GPS fix from inside my apartment, and I see the same bug.
The maps app reports its version as 1.8.44, if that helps.
Can you tell us which device and FW you are on? 
We can now replicate on Unagi 20120211070202. So there must have been a regression in the playing of audio files.
Does this issue happen already on the first instruction? "Start your journey and head [direction]"
Related to https://bugzilla.mozilla.org/show_bug.cgi?id=836814 , which is the cause of this issue.
Yes, that seems to be the symptom I'm seeing (hearing).  Reproduces on unagi and otoro.
Nominating along with bug 836814. Voice nav is unusable with this bug.
blocking-b2g: --- → tef?
Note for triagers: I see now that voice nav is only available for walking directions, not for driving, so this seems somewhat less critical to me.
Since this is a walking feature only for now, we won't block but can track and take a low-risk fix for uplift to v1-train.
blocking-b2g: tef? → -
status-b2g18: --- → affected
status-b2g18-v1.0.0: --- → wontfix
status-b2g18-v1.0.1: --- → wontfix
tracking-b2g18: ? → +
blocking-b2g: - → leo+
We have removed this functionality from the HERE Maps app, until https://bugzilla.mozilla.org/show_bug.cgi?id=836814 has been fixed.
Not sure if blocking on 836814 is the right fix here.  We could simply require that OGG files in the maps app have an Ogg Skeleton Index (see bug 836814 comment 23) and we'd be done (as soon as bug 848639 lands, and it's close).  

If we take this route we'll still be imposing a developer burden--app's .zip files will need to make sure that they don't compress media files.  I'm not sure if that's more or less of an impediment to developers (no one on IRC seems to know how hard it is to make a zip file where some files are compressed and others aren't. We know that the zip format supports it).   Dietrich, do you have any idea which of these requirements is less sucky?

So the fix for bug 836814 is going to require that apps bundle media elements in an uncompressed format. :mwu and :roc tell me that this will not increase download size (media resources are usually already compressed).  But it will require that app devs be able to create .zip files with some content compressed and some uncompressed (:mwu says the zip format supports this, but we're unclear if existing tools make it easy or not)
Flags: needinfo?(dietrich)
marking leo? as it seems we might be able to avoid blocking on this (see my previous comment).

My uninformed gut sense is that requiring the maps app to use cpearce's index tool to generate ogg indexes is the fastest route to win here.
blocking-b2g: leo+ → leo?
I don't understand why compressing the Ogg file would be a problem as long as it provides an Ogg skeleton index.

As long as the file contains that index wouldn't that mean that the media code wouldn't need to get the duration and so things would without the seekable stream?
Yes, as long as we provide an Ogg index we can still use compression for exactly the reasons mentioned in comment 16.

We *either* need to require an index (and make bug 848639 a leo+ blocker), *or* we need to require uncompressed media files (and leo+ bug 836814 and bug 849049).  It seems like requiring indexes is easier to me--bug 848639 is almost done (r+'d) and the developer burden seems about the same.
Maps app will contain audio files with indices in the next release, so you will be able to make use of it.
> Maps app will contain audio files with indices in the next release

Is that happening soon enough that we can mark this bug NPOTB, and make this no longer depend on bug 836814 and bug 849049?
Flags: needinfo?(dietrich)
Are we going to have next release of Maps app by the time we ship leo+ bugs?
Flags: needinfo?(andy.tjin)
(In reply to AndyT from comment #18)
> Maps app will contain audio files with indices in the next release, so you
> will be able to make use of it.

Given Andy is working on a fix here -- do we still have any blockers or will voice just work now?
If we'll have the new Maps app in the leo timeframe, we need to add a block on bug 848639 here, and we can remove blocking on bug 836814 and bug 849049.
When does leo+ ship?
FYI: we can switch on voice navigation in Maps as soon as the audio feature is working properly on the platform side and then we can release within 2 weeks. 

So: give us a sign when https://bugzilla.mozilla.org/show_bug.cgi?id=848639 is fixed, and we will act asap.
Flags: needinfo?(andy.tjin)
Based on comment 23, blocking on bug 848639 instead of bug 836814--once we have OGG indexes we won't need seekable JAR stream for Maps to work.
Depends on: 848639
No longer depends on: 836814
Drivers: please mark this leo+ again: I accidentally marked it leo? in comment 15 (which actually belongs in bug 836814).  Very sorry! :/
Restoring leo+ per comment #25.
blocking-b2g: leo? → leo+
update bug component category
Component: Gaia → General
AndyT, seem like you are working on this. mind taking this? as bug 848639 is fixed
Flags: needinfo?(andy.tjin)
we will check our fix as soon as we find the fix for bug 848639 in our OTA updates. [Will keep you posted here.]
Flags: needinfo?(andy.tjin)
Assigning to AndyT since he appears to be the person working on this issues from the Here Maps side of things.
Assignee: nobody → andy.tjin
Whiteboard: [nptob]
blocking-b2g: leo+ → ---
status-b2g18: affected → ---
status-b2g18-v1.0.0: wontfix → ---
status-b2g18-v1.0.1: wontfix → ---
tracking-b2g18: + → ---
Component: General → Preinstalled B2G Apps
Product: Boot2Gecko → Tech Evangelism
Version: unspecified → Trunk
We've verified the fix for bug 848639 and the latest version of HERE Maps from Marketplace (1.8.58) has Voice Navigation feature enabled again. Could you please recheck it?
(In reply to pawel.wojciechowski from comment #31)
> We've verified the fix for bug 848639 and the latest version of HERE Maps
> from Marketplace (1.8.58) has Voice Navigation feature enabled again. Could
> you please recheck it?

If you guys are claiming this is fixed now with new app on marketplace, then I think that's good enough to close. If someone happens to see this not working, then we'll follow up.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
(In reply to pawel.wojciechowski from comment #31)
> We've verified the fix for bug 848639 and the latest version of HERE Maps
> from Marketplace (1.8.58) has Voice Navigation feature enabled again. Could
> you please recheck it?

Keep in mind this fix only will work on 1.1. You'll need a way to keep this disabled in 1.01, given that this fix isn't uplifted on that branch.
(In reply to Jason Smith [:jsmith] from comment #33)
> (In reply to pawel.wojciechowski from comment #31)
> > We've verified the fix for bug 848639 and the latest version of HERE Maps
> > from Marketplace (1.8.58) has Voice Navigation feature enabled again. Could
> > you please recheck it?
> 
> Keep in mind this fix only will work on 1.1. You'll need a way to keep this
> disabled in 1.01, given that this fix isn't uplifted on that branch.

Could you give us some more reasons why we need to keep audio feature disabled in 1.01? It will help us to prioritize it properly.
(In reply to pawel.wojciechowski from comment #34)
> (In reply to Jason Smith [:jsmith] from comment #33)
> > (In reply to pawel.wojciechowski from comment #31)
> > > We've verified the fix for bug 848639 and the latest version of HERE Maps
> > > from Marketplace (1.8.58) has Voice Navigation feature enabled again. Could
> > > you please recheck it?
> > 
> > Keep in mind this fix only will work on 1.1. You'll need a way to keep this
> > disabled in 1.01, given that this fix isn't uplifted on that branch.
> 
> Could you give us some more reasons why we need to keep audio feature
> disabled in 1.01? It will help us to prioritize it properly.

Oh wait, disregard. I was wrong. The issue cited over in bug 848639 doesn't affect 1.01. So you are okay then.
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.