[prev in list] [next in list] [prev in thread] [next in thread]
List: amarok-devel
Subject: Re: Review Request: [GSoC] Amarok integration with gpodder.net
From: Lucas Lira Gomes <x8lucas8x () gmail ! com>
Date: 2011-10-17 20:58:56
Message-ID: CAH50j27oGiUZpStfM0LKCunvGehG46qoB=CD0SkqtBNXvT2Gqw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi Stefan,
we can do this way, but I think it isn't efficient.
We only want to know where we stopped, so there is no need to make more tha=
n
one episode action.
Unless something like play history is a to-do for Amarok (Bart should know
^^).
Regards, Lucas Lira Gomes.
On 17 October 2011 17:31, Stefan K=C3=B6gl <stefan@skoegl.net> wrote:
> Hi,
>
> On 10/16/2011 12:20 AM, Stefan Derkits wrote:
> > It uploads an EpisodeAction::PLAY every minute, which is not correct.
> > Play should only be sent once to the Webservice, when I
> > stop/pause/seek (not sure about seek, @stefankoegl can you clarify?)
> > and not every minute.
>
> The play-actions are intended to record one interval that has been
> played by the user at once.
>
> I'll illustrate this with an example.
>
> * User starts playing from the beginning
> create action 1 with start 00:00
>
> * User plays to 05:00 then seeks to 10:00
> set position to 05:00 in actions 1 and send it
> create action 2 with start 10:00
>
> * User plays to 15:00 and stops playback
> set position to 15:00 in action 2 and send it
>
> gPodder also skips actions if the time plays (difference between stop
> and start) is below some threshold (maybe 5 sec), but you are free to
> ignore such optimizations or invent your own (if they fit into the
> overall concept).
>
> Repeating the same interval periodically doesn't make much sense. The
> server will not try to merge these actions and they will clutter the
> user's history view.
>
>
> -- Stefan
>
[Attachment #5 (text/html)]
<div>Hi Stefan,<br></div><div><br></div><div>we can do this way, but I think it \
isn't efficient. </div><div>We only want to know where we stopped, so there is no \
need to make more than one episode action. </div><div>Unless something like play \
history is a to-do for Amarok (Bart should know ^^).</div> \
<div><br></div><div>Regards, Lucas Lira Gomes.</div><br><div class="gmail_quote">On \
17 October 2011 17:31, Stefan Kögl <span dir="ltr"><<a \
href="mailto:stefan@skoegl.net">stefan@skoegl.net</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"> Hi,<br>
<div class="im"><br>
On 10/16/2011 12:20 AM, Stefan Derkits wrote:<br>
> It uploads an EpisodeAction::PLAY every minute, which is not correct.<br>
> Play should only be sent once to the Webservice, when I<br>
> stop/pause/seek (not sure about seek, @stefankoegl can you clarify?)<br>
> and not every minute.<br>
<br>
</div>The play-actions are intended to record one interval that has been<br>
played by the user at once.<br>
<br>
I'll illustrate this with an example.<br>
<br>
* User starts playing from the beginning<br>
create action 1 with start 00:00<br>
<br>
* User plays to 05:00 then seeks to 10:00<br>
set position to 05:00 in actions 1 and send it<br>
create action 2 with start 10:00<br>
<br>
* User plays to 15:00 and stops playback<br>
set position to 15:00 in action 2 and send it<br>
<br>
gPodder also skips actions if the time plays (difference between stop<br>
and start) is below some threshold (maybe 5 sec), but you are free to<br>
ignore such optimizations or invent your own (if they fit into the<br>
overall concept).<br>
<br>
Repeating the same interval periodically doesn't make much sense. The<br>
server will not try to merge these actions and they will clutter the<br>
user's history view.<br>
<font color="#888888"><br>
<br>
-- Stefan<br>
</font></blockquote></div><br>
_______________________________________________
Amarok-devel mailing list
Amarok-devel@kde.org
https://mail.kde.org/mailman/listinfo/amarok-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic