Should we add cover arts to this since it's just gonna be the local storage?
Overall I feel we can complete the tagger with the cover arts+tags+songs lookup
It even makes sense. Otherwise around January I myself had a hard time understanding the functionality of the tagger when I first used it on the app.
I think Picard desktop does a great job at fetching the albums from the server with the cover arts included
With this addition and the bug fixes, the app tagger should be good to go. Any comments lucifer ?
lucifer
akshaaatt[m]: sure, I think adding cover arts support to KTagLib makes sense but it'll need much work. We can look into that after other parts of the Tagger are done.
akshaaatt[m]
Cool
lucifer
also, Kotlin Native is in much better shape now it might be easier to work with it. JNI is scary.
akshaaatt[m]
Ikr!
monkey
lucifer: I think having eslint checks as inline annotations is the best. As we're moving to actions I think it wouls be a good improvement!
Heads up! The eff article about has been published. There may be more traffic etc
Zas: ^^
+us
yyoung
Hi yvanzo, about error handling, I decide to add an extra property named 'target' on the validation result of URLCleanup, indicating the target of error. The 3 targets of errors are link, relationship and entity, the default option is link if URLCleanup
URLCleanup's validate function simply returns {result: false}
And if there're existing error messages I'll add the target according to that.
Also, the default error message "This URL is not allowed for the selected link type, or is incorrectly formatted." will be splitted
I would like to have your opinion since it would require a lot of work if I start updating URLCleanup.js :)
zas
ruaok: ok ;)
yvanzo
hi yyoung, ‘link’ is ambiguous as it can mean either ‘relationship’ or ‘URL‘
yyoung
yvanzo: OK, so I'll change it to URL
yvanzo
’entity’ target seems to be a special case for ’URL’
yyoung
Initially I thought of sorting by error type, e.g. invalid url, incompatible entity, inappropriate relationship type, but that seems too much
Here by URL I mean the URL is invalid or inappropriate page for this type of relationship
Still seems controversial for messages like, "Please link to the main page for the artist, not a specific release."
monkey
That's a really nice concise article !
yvanzo
yyoung: Adding a ’target’ property is fine at least. ’URL’ and ‘relationship’ too. Not sure ‘entity’ helps with anything.
(’URL’ and ‘relationship’ as values)
The default should probably be no value though as it might affect either URL or relationship or both.
yyoung
'entity' is because we haven't decide the target of incompatible entity error, or should I just assign an arbitrary target for that and decide later?
<The default should probably be no value> Sure but I believe that would introduce a lot of extra code :)
yvanzo
I doubt that all current errors can be mapped to either ’URL’ or ’relationship’ (or ’entity’), so better have a fallback, that will make transitioning easier.
That fallback can be either a catch-all value ’any’ or no value (that is no ’target’) by default.
Because there are some new rules in place of reading the contents of a file on android. The hack that I know of is, you temporarily copy the file to a new location and then use the contents of that copy to manage/edit everything
If I understand how that JNI guy did this hack, there would be no stopping us 🤓
lucifer
akshaaatt[m]: we used JAudioTagger before TagLib but it was limited than Taglib so we went replaced it with taglib. JAudioTagger uses java's image apis under the hood which are not available on Android (because Android is not truly Java which sucks 😞 )
akshaaatt[m]
Oof lmao
lucifer
in short, we'll need to rewrite entire JAudioTagger image handling code to make it work on android
akshaaatt[m]
Tbh why are these libraries so complicated
lucifer
this issue plagues many android libraries because Android does not support all Java apis.
one reason is this that there are a large number of media formats all of which require special cased handling.
akshaaatt[m]
The jaudiotagger did let me fetch all the audio files and some metadata though
lucifer
yes, that'll work the image part is what won't work.
if you browse, the git history you'll find a version of app using JAudioTagger
akshaaatt[m]
However I agree there must be something to what you are saying. Plus these libraries are humongous and I don't see if that's doing the justice to the work done under the hood
So we stick with the TagLib?
lucifer
yes, i dont know of a viable alternative as of now.
one issue why we dont have such libraries in Java is because JNI is hard. things will become so much easier with Project Panama
but Android might never support that so who knows
akshaaatt[m]
Damn
I think Apple won't even allow for the tagger feature then]
iOS app will be way limited then
I think the main highlights of our apps are gonna be the lookups, listen service, critiques, collections and our varied database.
Wow ListenBrainz is so cool! Kudos to all the developers!
shivam-kapila
Its my favorite OSS project till now :)
akshaaatt[m]
I think before today I had a tough time understanding the website a bit of how to get started. I connected my spotify account today and voila
Amazing.
So tell me, under the hood we use the Spotify API for getting the listens to the backend?
shivam-kapila
Yeah. The spotify reader gets a list of connected accounts and then queries the Spotify API to fetch new listens
akshaaatt[m]
Wow that's amazing!
So do we have a tie up with spotify for this or we pay them some cut for doing this?
lucifer
no, there's no tieup. we just use their public api for this.
akshaaatt[m]
Okayy! Interesting
shivam-kapila
Nope. When a user connects their account we get the tokens and those are enough to authorize. Dont need a tie up as we are just using the public API.
akshaaatt[m]
Since we are an open sourced organziation, can't spotify just fork the work and directly add it to their interface?
<shivam-kapila "Nope. When a user connects their"> Cooool
alastairp
lucifer: interesting. is that because we have been building from github?
lucifer
alastairp: could be. probably a wrongly set environment variable.
akshaaatt[m]
Btw can we add a feature on the listenbrainz website to search for other users by their username?
And lucifer are we going to add this gem of listenbrainz directly into the android app?
All these charts and analytics
This would basically create a social media of music listeners
We could setup people on blind dates based on their music tastes XD 😇
lucifer
akshaaatt[m]: i had begun adding listens submission to the app. its currently in the alpha state. adding other lb things is also on the cards in the near future if we want
shivam-kapila
> We could setup people on blind dates based on their music tastes XD 😇
lucifer
we had disucssed the social media aspect of LB in the last summit, jasondk's SoC project is also a step in that direction.
shivam-kapila
TinderBrainz
akshaaatt[m]
No but once we have linked our account to listenbrainz, why do we need a service running on the app? Isn't the backend already fetching the data?
<shivam-kapila "TinderBrainz"> I am up
<lucifer "we had disucssed the social medi"> Wow cool
lucifer
for spotify, we have a spotify reader service which runs on MeB server and polls listens from spotify accounts for users.
we also have an api, using which users can submit listens from different apps.
the app submits listens from different apps using the api.
akshaaatt[m]
Right
lucifer
ruaok, should we add a metric for listens imported by spotify reader?
akshaaatt[m]
Niceeee. I think the data can also reflect the source of the listens?
lucifer
yes, there's a field for specifiyng source of listens.
shivam-kapila
lucifer: that would be helpful in studying why unique listens is only a fraction out of all the incoming ones