Bug 299218

Summary:	Amarok script API track signals are unreliable, undocumented
Product:	[Applications] amarok	Reporter:	Marcelo Vanzin <mmvgroups>
Component:	Tools/Script Manager	Assignee:	Amarok Developers <amarok-bugs-dist>
Status:	CONFIRMED ---
Severity:	wishlist	CC:	darthcodus, m.israprabhu, madhurya.dgp, saggieb12
Priority:	NOR	Keywords:	junior-jobs
Version:	2.7.0	Flags:	myriam: Usability-
Target Milestone:	later
Platform:	Ubuntu
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Bug Depends on:	313283
Bug Blocks:

Description Marcelo Vanzin 2012-05-02 06:57:26 UTC

Not sure if the component is correct; but I'm talking about the script API's signals related to track events (Amarok.Engine.trackChanged and friends).

I have a script that I use to control my playlist. I though I had gotten it right with 2.4, but I've been trying to debug it on 2.5 and I can't seem to understand what's going on with the track changed events. For the same UI actions, I get different combinations of events with different states of the Amarok properties I can query from the engine.

Allied to the fact that none of the signals are documented aside from their existence, it's kinda hard to know what to do.

For example: what happens when amarok finishes playing the last track on the playlist?

Some times I get a track finished signal. Sometimes I don't. Sometimes amarok will start playing the first track, and I'll get two trackChanged signals. Sometimes it won't, and I get just one trackChanged with different amarok state. I've been trying to figure out a pattern so I can make my script work (http://kde-apps.org/content/show.php?content=104462 for the curious) but so far it's been impossible.

It would be nice if, in the very least, amarok would be consistent, and that the behavior is both (i) documented and (ii) kept consistent across amarok releases, which has definitely not been the case since I started that script in amarok 2.0.

Better yet, I'd like to suggest improvements to the signals, so that script writers can make more informed decisions about what's going on. Specifically for the trackChanged signal, it would be nice to know:

. the previous track that was playing, if any
. the track that will start playing after the event is handled
. the reason for the track change (previous track finished, previous track was skipped, user double-clicked new track in UI, etc)

Similarly, other signals could also benefit from more detailed info; e.g., trackFinished could also have a reason (stop button vs. "stop after current track" vs. playlist finished, for example).

FYI, the documentation I'm following is this one:
http://amarok.kde.org/wiki/Development/Script_API

It just lists the signals. It has no info about in which case the signals are triggered (which would seem obvious but, from evidence I collected in testing, is definitely not), what information about the signal can be collected, and what actions are safe during signal handling (I've had different issues with trying to update playlists or do things like start playing a different track during signal handling).

Let me know if there's more info that I can provide that could help in debugging things. I'm filing this as a wishlist item because it kinda feels like these signals are an afterthought, based on the different behavior I've seen in different versions of amarok, and I'd really like to see them become something more stable that script writers can use reliably.

Reproducible: Always

Comment 1 Anmol Ahuja 2013-04-21 20:09:48 UTC

Is this bug report still valid as of the latest Amarok build?

Comment 2 Myriam Schweingruber 2013-04-22 12:05:33 UTC

Yes, partially, nobody had time to write that documentation. There are snippets out there, see http://community.kde.org/Amarok/Development#Scripting

Comment 3 Anmol Ahuja 2013-04-23 17:45:59 UTC

I meant the signal behavior problem, actually. I doubt it has been fixed.
I get double playPaused and trackChanged signals on track changes for instance, but the behavior seems pretty consistent, though admittedly not desirable.

Comment 4 Marcelo Vanzin 2013-04-24 02:25:57 UTC

The situation got a lot better in some update (I actually think it was an update to a phonon library, not amarok itself); my script is mostly functional with the current packages I have.

But most of my feedback still stands, since I'm mainly asking for documentation (and that the documented behavior be kept consistent across releases), and, separately, for better information provided by the signals.

Comment 5 Anmol Ahuja 2013-04-24 15:10:34 UTC

So should this be marked as duplicate of 313283?
PS- Documentation of the scripting API is part of my GSoC proposal.

Comment 6 Myriam Schweingruber 2013-04-24 21:44:03 UTC

(In reply to comment #5)
> So should this be marked as duplicate of 313283?
> PS- Documentation of the scripting API is part of my GSoC proposal.

No, as it already depends on it, check the dependency tree/graph of this bug

Comment 7 Prabhakar Misra 2014-06-24 14:10:01 UTC

Is this still open? I am new to the open source community and looking for a "junior job". Any suggestions about if this would be a good starting point would be helpful.

Comment 8 Myriam Schweingruber 2014-06-25 10:26:55 UTC

(In reply to comment #7)
> Is this still open? I am new to the open source community and looking for a
> "junior job". Any suggestions about if this would be a good starting point
> would be helpful.

Well, yes, it is still open, else the wish would be closed :)

If you want to work on this, you should be aware that this is not a coding task, but a documentation one. Please join the amarok-devel@kde.org mailing list if you would like to work on this. You can find all Amarok documentation starting from http://community.kde.org/Amarok and http://community.kde.org/Amarok/Development

Comment 9 mg 2015-12-24 13:02:54 UTC

how can I access the code to work on fixing this bug?

Comment 10 mg 2015-12-24 13:03:19 UTC

how can I access the code to work on fixing this bug?

Comment 11 Myriam Schweingruber 2015-12-26 11:36:53 UTC

(In reply to mg from comment #10)
> how can I access the code to work on fixing this bug?

Please see the links I gave in comment #8, every necessary information is there :-)

Comment 12 Sagnik Bhattacharya 2016-06-05 15:17:53 UTC

I'm new to the open source environment. Can you please guide me as to how I should go about this bug, I mean what should I do now and how I am expected to fix the bug. Any help would be appreciated.

Comment 13 Myriam Schweingruber 2016-06-05 16:33:47 UTC

(In reply to Sagnik Bhattacharya from comment #12)
> I'm new to the open source environment. Can you please guide me as to how I
> should go about this bug, I mean what should I do now and how I am expected
> to fix the bug. Any help would be appreciated.

Same for you, please see the links I gave in comment #8, everything is there :-) And as told in another comment: this is not a coding bug, but a documentation one ...

@all: please read the comments in a bug report if you are interested in fixing it, there are enough clues on how to proceed. And if a bug report doesn't contain enough information, use your search engine, all KDE projects are well documented and everything can be found online.