Bug 5420 (int-153658)

Summary: Don't show hildon banner every tap when browsing UPnP shares
Product: [Maemo Official Platform] UI Specification Reporter: Ryan Abel <rabelg5>
Component: GeneralAssignee: unassigned <nobody>
Status: RESOLVED FIXED QA Contact: media-player-bugs
Severity: normal    
Priority: Low CC: andre_klapper
Version: 5.0/(3.2010.02-8)   
Target Milestone: 5.0/(10.2010.19-1)   
Hardware: All   
OS: All   

Description Ryan Abel (reporter) maemo.org 2009-10-13 23:19:40 UTC


1. Enable a UPnP server.
2. Open Media player.
3. Browse your UPnP server.

Device-stabbing inducing hildon banners don't pop up with every tap to tell you
it's connecting to the server.

Hildon banners pop up for every single tap while browsing UPnP shares.


The correct indicator to use is the little rotating processing wheel next to
the application title. This damn near induces epileptic seizures.

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_1; en-US)
AppleWebKit/531.9+(KHTML, like Gecko, Safari/528.16) OmniWeb/v622.10.0
Comment 1 Andre Klapper maemo.org 2009-10-14 16:43:12 UTC
Please provide the exact text of these banners (makes it way easier to query
for issues filed already).
Comment 2 Ryan Abel (reporter) maemo.org 2009-10-14 19:35:17 UTC
(In reply to comment #1)
> Please provide the exact text of these banners (makes it way easier to query
> for issues filed already).

"Contacting servers"

Which is another bug, since there's only actually one server involved.
Comment 3 Andre Klapper maemo.org 2010-01-05 16:40:03 UTC
I assume this still happens in PR1.1?
Comment 4 Andre Klapper maemo.org 2010-01-13 21:15:08 UTC
Ryan, does this still happen in PR1.1?
Comment 5 Ryan Abel (reporter) maemo.org 2010-01-13 22:44:59 UTC
(In reply to comment #4)
> Ryan, does this still happen in PR1.1?

Dunno, I've yet to see any sign of UPnP functioning in PR1.1.
Comment 6 Ryan Abel (reporter) maemo.org 2010-01-13 23:44:34 UTC
(In reply to comment #4)
> Ryan, does this still happen in PR1.1?

Bizarrely, updating to 10.6.2 made it work. Maybe it was just the restart. . .

Anyway, yeah, still valid for 51-1.
Comment 7 Andre Klapper maemo.org 2010-02-09 18:57:26 UTC
INVALID as per internal comment:

"For me it shows banner: "Refreshing library". I tested with PR1.1 and PR1.2.
It is implemented as spec says: When starting the data fetching from media
server, the information banner is shown to the user and same time the Hildon
Touch Progress indicator widget is shown in the title area. The banner can hide
after the default timeout, but the progress indicator should stay visible until
the fetching is finished."

Ryan, feel more than welcome to reopen and move against UI Spec if you have
good arguments why this is not reasonible...
Comment 8 Ryan Abel (reporter) maemo.org 2010-02-09 19:54:37 UTC
OK, here's the problem. No other application implements a system like this.
When activity is occurring a spinning indicator is shown in the title area.
MicroB does not throw a hildon banner to explain that it's connecting to a
server and loading. h-a-m does not show a hildon banner to explain that it's
refreshing the apt catalog, the image viewer does not throw a banner to
indicate that it's loading pictures.

Clearly the spec is INCONSISTENT with the rest of the platform and should be
changed. It's also epilepsy inducing.
Comment 9 Andre Klapper maemo.org 2010-03-09 22:22:46 UTC
This has been fixed in package
mediaplayer 1.2-14+0m5
which is part of the internal build version
(Note: 2009/2010 is the year, and the number after is the week.)

A rotating processing wheel next to the application title is shown while
loading the folders/files in UPnP.

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.

To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
Comment 10 Andre Klapper maemo.org 2010-03-15 20:56:46 UTC
Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).