Re: [mafw-lastfm-devel] [ANN] maemo-scrobber 1.0 for last.fm + libre.fm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2010-06-03 at 12:39 +0300, Felipe Contreras wrote:

> Ah, I didn't reply:
> 
> > 1. No now-playing notification
> 
> Not a blocker IMO. 

That's *your* opinion. For me, moving to a library that causes loss of
functionality is a no-go unless there are very good reasons to do it,
which was not the case, IMO.

> In fact at least last.fm seems to understand just
> fine that the last scrobbled song is "Now Playing" due to the
> timestamp. So I fail to see what functionality users will miss.

Not really. A very recently scrobbled track will be displayed as "Just
played". The only way to display a track as "now playing" is through the
now playing notification.

> > 2. No scrobbling right after the track has finished.
> 
> I'm not sure what that means, but if it's related to the fact that I
> decided to scrobble songs each 10 minutes. First, I told you that it's
> not a limitation of libscroble, it's up to the client
> (maemo-scrobbler/mafw-lastfm) to call sr_session_submit() when it sees
> fit[1]. And second, I changed maemo-scrobbled back in January to do
> what you wanted[2]. Also, in the pathches for libscrobble I sent I
> called sr_session_submit() right after metadata_callback(). Therefore,
> as I mentioned, there's no change.

Well, it makes a huge difference to know when a problem doesn't exist
anymore. You could have said this back then when I commented it, but it
seems you were expecting me to follow your progress or dig into your
code just because you deserve it.

> > I haven't worked on this yet, because I was fixing other issues that
> > were more important. I list them below, even when I am sure that you
> > know already.
> 
> Yes, and I don't agree with the priorities. To me, as a user, I don't
> care if I cannot scrobble from certain proxified connections to
> last.fm, because even if I do, it would only be to last.fm.

But *you* are not the average user, so please excuse me for not
following your needs to set my priorities. After all, you've shown
enough skills to supply for your needs yourself :)

> So, mafw-lastfm provides at best 50% of what I need (more like 40%);
> that's not acceptable.

Not acceptable for *you*. It's perfectly fine if you disagree on what's
necessary or not for a piece of software, just please don't come to me
telling me what I need to focus on just because something doesn't work
as you expect it.

> > I have fixed all the issues with the network handling for at least a
> > month now (these were released in 0.0.5).
> 
> Well, that's easy to say. I would need to review the code to even be
> slightly confident that that's true. And of course, even if I don't
> see any problems... that's not a guarantee that _all_ the problems are
> fixed.

Do you really want to go into this sort of non-constructive debate? I
don't. And I obviously meant that I fixed all issues known. And that no
new issues have arose since then.

> 
> > I also implemented support for
> > scrobbling behind proxies[1], which is in a branch in gitorious waiting
> > to get some testing from users.
> 
> Yes, as I said before, I don't think that's important.

That's, once again, *your* opinion. I'll kindly ask you to please stop
pretending I should treat it specially, just because you can write some
code.

> > I have also implemented permanent storage during last week and it's
> > working fine. I am planning to do a release including this during this
> > week, but I was waiting for some translations to come in first [2].
> 
> Perhaps it's working fine, or perhaps it has issues with UTF-8, or
> perhaps (quite likely) it's implemented in a non-extensible way which
> would require many changes once multi-scrobbling is supported. I can
> tell you from experience that the latter is quite likely.

Yes, "perhaps" a lot of things. What is your goal with this speculative
arguing?

UTF-8 is working fine, since I soup_uri_escape() tracks' data before
serializing it. If changes are required to support multiscrobbling, then
changes will be made then, I fail to see what's your point here, other
than to speculate for the sake of doing it.

> 
> In any case, you _knew_ libscrobbler supported this, and yet, instead
> of adding the missing features to libscrobbler, you decided to
> implement this yourself.
> 
> >> 4) Video clips are ignored
> >>    Small feature, but important.
> >
> > In the same email I link above, I replied to you that I wasn't against
> > implementing this if there was broader interest from users. Since I
> > didn't get much more feedback on this regard it was low in my
> > priorities.
> 
> Well, I saw many more users asking for this than proxy support.

Proxy support is a feature that is not debatable (meaning, no one would
argue whether it's needed or not). Not scrobbling videos is debatable.
Therefore I decided to implement first what's non debatable, waiting for
more input in other stuff before moving.

> >
> > I don't how to take this. Unfortunately, I was waiting for your feedback
> > on my comments. I apologize if you were expecting something different.
> 
> Yes, I forgot to reply to your last mail. However, it's clear you
> didn't even took a look at libscrobble, as you yourself mentioned, and
> as you didn't know   that some drawbacks where not there. It's also
> clear to me that you were not seriously considering it since you
> started fixing your queue problems (already done in libscrobbler), and
> implementing permanent storage. Not to mention the fact that you
> didn't reply to my patches to merge libscrobbler, or provide any
> feedback at all related to the API or implementation.

Well, I didn't look further because features I considered important were
missing, and I said so. If you knew that I was overlooking something you
could have pointed it out. Just staying silent is not gonna make me
realize that I'm missing something. Keep in mind that, in the end, if
you wanted to convince me to use your code you need to make an effort in
communicating as well, not only in coding.

> Maybe the problem is miss-communication, or whatever

Yes, I believe the problem is miscommunication, but by now (and I'm also
taking into consideration your reply to Menno Jansz to say this) you're
turning it into a rampage because I didn't do things as you expected.

>  as a user, I
> want those features NOW, so I have been running maemo-scrobbler
> manually. I don't see why not share it with other people.

I have absolutely no problem with you sharing what you have created with
other people. But if you come to the mailing list of a competing project
and start spreading half-truths about it, start telling its developers
what should they work on, and moreover disrespecting their work, then
don't expect people to be willing to collaborate with you. I hope you
can understand this.

> 
> > I don't know if it was necessary for you to go your own way and
> > implement your own scrobbler, but in the end it's up to you. In a normal
> > case I'd be glad to see alternative software, because competition is
> > healthy, but in this case I find it a bit ridiculous – it's such a small
> > software that it barely makes sense to offer people two different ones
> > that in the end will obviously do the same. But that's your way, and
> > you're free to do it.
> 
> Yes, I agree, it's ridiculous that we can't have a single project.
> However, the _only_ problem you have mentioned about maemo-scrobbler
> is the lack of "Now Playing" support. I don't think it's important, in
> fact I don't think it makes *any* difference, but if you do, you could
> have spent a few hours trying to implement it in my libscrobble.
> Considering the amount of time I spent in your code, I would have
> considered that good manners.

For someone who is not showing good manners at all in the way you refer
to others' work, it's a bit surprising that you expect them from others.

> In any case, I'm much happier with the code-base/architecture of
> maemo-scrobbler/libscrobbler, so I would rather add the features
> mafw-lastfm has that users want (not sure what those are, actually),
> rather than try to deal with mafw-lastfm (I believe I did too much of
> that already).

Good for you. Have fun.

> Usual disclaimer: I'm don't have any hard feelings, I just like to
> express my concerns loudly and clearly.

Feel free to express your concerns loudly and clearly; I'll feel free to
ignore the clearness because of the loudness.

Claudio


_______________________________________________
maemo-users mailing list
maemo-users@xxxxxxxxx
https://lists.maemo.org/mailman/listinfo/maemo-users



[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]    

  Powered by Linux