Additional information: during the time between rebooting the device and the
media player applet going broken, I connected and disconnected A2DP/AVRCP
headphones several times. So, the bug may be somehow related to the broken
AVRCP support.

Comment 2 Andre Klapper 2010-02-22 14:28:16 UTC

Hi,

> EXTRA SOFTWARE INSTALLED:

This section was deleted. Which other desktop widgets are installed?

(In reply to comment #2)
> > EXTRA SOFTWARE INSTALLED:
> This section was deleted. Which other desktop widgets are installed?
OMWeather. Nothing else.

*** This bug has been confirmed by popular vote. ***

Another piece of information:
When I start playback in the full Media Player application, I can pause it with
the applet. But trying to resume playback from the applet fails.

Created an attachment (id=2391) [details]
DBus messages log for non-working applet

This is a log of DBus messages sent by the *non-working* Media Player Applet
when I click on PLAY icon.

Created an attachment (id=2392) [details]
DBus messages log for working applet

This is the DBus messages log from *working* Media Player applet, when I click
on PLAY and it starts playing the mp3 file. To get this log, I had to remove
the non-working Media Player applet from the desktop and add it again.

*** Bug 10055 has been marked as a duplicate of this bug. ***

dbus-monitor --session output on tap of play button if not working

method call sender=:1.31 -> dest=com.nokia.mafw.playlist serial=453
path=/com/nokia/mafw/playlist/1; interface=com.nokia.mafw.playlist;
member=get_size
method return sender=:1.69 -> dest=:1.31 reply_serial=453
   uint32 215
method call sender=:1.31 -> dest=com.nokia.mafw.playlist serial=454
path=/com/nokia/mafw/playlist/1; interface=com.nokia.mafw.playlist;
member=get_item
   uint32 179
method return sender=:1.69 -> dest=:1.31 reply_serial=454
   string
"localtagfs::music/songs/%2Fhome%2Fuser%2FMyDocs%2F.sounds%2FMusik%2FThe%20Subways%2FThe%20Subways-All%20or%20Nothing%2F07%20I%20Won%27t%20Let%20You%20Down.m4a"

looks somewhat different from a normal dbus-call when playback works


all other things work, rew, fwd and opening mediaplayer do their job.

Removing the widget and adding it again crashes home and removes all 3rd party
widgets on restart.

3rd party widgets in home are:
Simple FMTX desktop widget + FM boost (fm boost is not on the desktop as init
works from FMTX)0.5.0
3x Desktop Command Execution widget 0.9
ForecaWeather widget (OMweather crashed the whole desktop when I tried it)
0.9.5
Countdown Home Desktop Widget 0.6-1

other widgets are:
calendar
mediaplayer

3rd party in desktop:
3G/2G/Dual Mode Selection Applet 0.4-2
Load Applet 0.4.6-5
Flashlight 0.3-7
Custom Operator Name Widget 0.1
Simple Brightness Applet 1.1-1maemo0
tweakr 0.0.17-2

Comment 10 Andre Klapper 2010-05-01 16:23:05 UTC

*** Bug 10075 has been marked as a duplicate of this bug. ***

Comment 11 Eero Tamminen 2010-05-05 13:37:04 UTC

Internal comment:
------------
For some reason something is blocking answer from policy. Probably home-applet
is guilty for that.

I made test applet which had only policy requesting and it works. Also it works
if home-applet is alone in desktop. ( At least omweather or touchsearch caused
problems after boot).
------------

Does omweather applet do any D-BUS stuff?

(As all applets are run in same process, they could mess up D-BUS handling for
the other applets, this has happened also in earlier Maemo releases, but is
very rare.)

Comment 12 Andre Klapper 2010-05-05 13:56:01 UTC

I didn't expect it to be, but in that case it's probably the same issue as bug
7909 though I'd prefer to keep this here because we have less noise.

Wishful thinking: A system to find out which exact desktop widget screws up
things in Maemo5 would be really appreciated. Not the first time.

Comment 13 Eero Tamminen 2010-05-05 15:11:07 UTC

(In reply to comment #12)
> Wishful thinking: A system to find out which exact desktop widget screws up
> things in Maemo5 would be really appreciated. Not the first time.

Unfortunately there really isn't an easy way to do this.  Code has uncountable
ways in how it can screw up things and when these components are in the same
process, there's no good way to find out the culprit fast, especially as the
issue can sometimes appear even a long time afterwards (even after you've
removed the widget, if home wasn't restarted).

One just needs to try to isolate which of the applet(s) cause the issue and
then disable that + complain to upstream.  If one has lots of applets and it
takes several hours/days to re-produce the issue, best is to use binary search:
disable half, restart home, retest.  If issue still appears repeat that, if
not, take half of the disabled widgets back and retest (when adding, no need to
restart home).

-> Community QA should include much longer testing, at least for applets.

Btw. The reason for having them in the same process is mainly memory usage. 
Overhead from each new Hildon UI process is 1-2MB (localization, themeing,
fonts and other non-shared parts from the libraries, gtk_init() etc).  If you
have lots of applets, having them as separate process would of course increase
the startup time too.

(In reply to comment #13)
> One just needs to try to isolate which of the applet(s) cause the issue and
> then disable that + complain to upstream.  If one has lots of applets and it
> takes several hours/days to re-produce the issue, best is to use binary search:
> disable half, restart home, retest.  If issue still appears repeat that, if
> not, take half of the disabled widgets back and retest (when adding, no need to
> restart home).
Well, I am in a unique position to find this out: I only have OMWeather and
that little wall calendar widget running. Disabling OMWeather right now. =)

Comment 15 Eero Tamminen 2010-05-06 10:28:10 UTC

Remember to restart hildon-home too, to get rid of all the possible harm done
by the applet within that process...

I've tried to find the source of that bug in OMWeather, but failed. I've
commented all dbus functions in OMWeather but that didn't help. And I have
found that RSS-applet(Nokia) is blocking Media Player Applet too.

(In reply to comment #16)
> I've tried to find the source of that bug in OMWeather, but failed. I've
> commented all dbus functions in OMWeather but that didn't help. And I have
> found that RSS-applet(Nokia) is blocking Media Player Applet too.
I can confirm that OMWeather applet does indeed cause the Media Player applet
problem. The same behavior has been reported on t.m.o for the USSD applet.

Also note that it is only the PLAY functionality that stops working. PAUSE,
PREV, and NEXT functions work as expected.

Comment 18 Eero Tamminen 2010-05-17 13:41:52 UTC

(In reply to comment #16)
> I've tried to find the source of that bug in OMWeather, but failed. I've
> commented all dbus functions in OMWeather but that didn't help.

What about libosso, libplayback or other libraries that use D-BUS to do things?
 It could be enough for a component to re-route the callbacks wrong...


> And I have found that RSS-applet(Nokia) is blocking Media Player Applet too.

We've internally found some issues in RSS-applet (NB#160415) which can cause
issues like this.  RSS-applet was doing some funny things with sockets/file
descriptors.  Maybe OMWeather has also something similar?

NOTE: whenever testing Home applet issues, restart Home after changing applets,
otherwise you don't get rid of the effects of the previous applets.

I did listen to music using the widget.
Stopped music with widget button.
Did a SIP call.
Widget does not start music anymore.

It is like a random bug, like it sometimes starts itself after a call (happend
to me too). For PR1.2 I have to check again as nothing played me yet.

Comment 20 Andre Klapper 2010-06-23 15:11:06 UTC

So does this still happen in 10.2010.19-1?

(In reply to comment #20)
> So does this still happen in 10.2010.19-1?
It does, albeit less frequently (or so it seems). Actually, the Media Player
Applet is stuck *right now*, and I've rebooted the device just a few hours ago.
In my case, running OMWeather applet seems to be the main cause, but you can
see above that other causes are also possible.

Comment 22 Andre Klapper 2010-09-02 12:28:29 UTC

*** Bug 11240 has been marked as a duplicate of this bug. ***

Comment 23 Andre Klapper 2010-12-18 16:28:52 UTC

*** Bug 11483 has been marked as a duplicate of this bug. ***

Comment 24 Andre Klapper 2011-05-10 21:03:13 UTC

*** Bug 12221 has been marked as a duplicate of this bug. ***

(In reply to comment #24)
> *** Bug 12221 has been marked as a duplicate of this bug. ***

Ok, so there has been three bugs marker as duplicates, mine among them, and
rightly so - I have filed a duplicate. Now here is a question: WHY IS THIS
ISSUE STILL NOT RESOLVED BY NOKIA, as it has been a substantial amount of time
between the original bug report and when I have encountered the problem more
than a year later.

Comment 26 Andre Klapper 2011-05-16 08:37:15 UTC

(In reply to comment #25)
> (In reply to comment #24)
> Ok, so there has been three bugs marker as duplicates, mine among them, and
> rightly so - I have filed a duplicate. Now here is a question: WHY IS THIS
> ISSUE STILL NOT RESOLVED BY NOKIA

Because Nokia maybe does not focus that much on Maemo5 anymore? Anyway, you
should ask that question to Nokia (e.g. via customer care). In bugs.maemo.org
you likely won't receive an answer, plus it's not a discussion forum either.

- works-for-me - PR1.3 CSSU - as most of the time when widgets play up I would
point somewhere else than in Nokia directions to fix it as many 3rd party
widgets crash/freeze/slow hildon-home and/or other widgets. 

Test procedure in this case is simple but annoying. You need to remove all
widgets but one plus mediaplayer-widget and restart hildon-home (or reboot) try
for at least one day then add another widget. 

Sometimes the widget is "just" unresponsive, the desktop seems to behave normal
but the widget takes ages to respond to taps, that is mostly due to stuff run
in the background hogging the device so you may look for your CPU usage at the
time the widget does not do as you expect it.

Comment 28 Eero Tamminen 2011-05-16 14:57:28 UTC

(In reply to comment #18)
> > And I have found that RSS-applet(Nokia) is blocking Media Player Applet too.
> 
> We've internally found some issues in RSS-applet (NB#160415) which can cause
> issues like this.  RSS-applet was doing some funny things with sockets/file
> descriptors.

The RSS applet issue (related to FD handling of the device internet heart beat
(access synchronization) socket) was fixed in PR1.3.

Any of the remaining issues with Media applet are assumed to be caused by 3rd
party applets, not Nokia ones.

I think i found the problem in this case. I had PR 1.3 installed over my N900
and then too I was facing this problem. Initially my Media Player widget was
working fine. But as soon as I installed the application 'Headset Control' the
widget got corrupted and was behaving in the same way as mentioned above. I
updated my firmware further with CSSU firmware to PR 1.3 - 14.1 but then too
this problem was there in my tablet. One day I un-installed the application
'Headset Control' from the phone and reapplied my widget on the Desktop. Ever
since then my media player widget is working fine and it never stops
automatically.

(In reply to comment #28)
> (In reply to comment #18)
> > > And I have found that RSS-applet(Nokia) is blocking Media Player Applet too.
> > 
> > We've internally found some issues in RSS-applet (NB#160415) which can cause
> > issues like this.  RSS-applet was doing some funny things with sockets/file
> > descriptors.
> 
> The RSS applet issue (related to FD handling of the device internet heart beat
> (access synchronization) socket) was fixed in PR1.3.
> 
> Any of the remaining issues with Media applet are assumed to be caused by 3rd
> party applets, not Nokia ones.

Perhaps it's time to get more aggressive about applets that break this or other
applets and remove them from Extras until they can be demonstrated not to cause
problems?

I just had to do a reboot and again found the media player applet dead. So as
OMWeather has been implicated as a problem, I removed it then rebooted again -
media player applet working fine.

So if OMWeather causes problems for other applets, should it be allowed in
Extras?