That None comes from an internal process, gcrk. lucifer is going to fix that now. hopefully that fixes the problem we saw earlier.
gcrk
alright, so I will stop debugging :)
ruaok
we *think* that is the problem. we'll have to confirm that .
lucifer
outsidecontext: gcrk: could you share the json payload from funkwhale debug output for which the mbid was "None" in LB? that would help me debug and validate the fix faster.
outsidecontext
lucifer: I can't because I could not reproduce the issue, but maybe gcrk can
lucifer
ah ok.
gcrk: just listening to the same file would sending its log should do methinks.
ruaok wonders if alastairp's brain is leaking out yet
alastairp
gnnngh
ruaok
heh
alastairp
it's mostly things like "I can't have the fan on in my office because the noise comes through if I need to talk, so I'm melting"
ruaok hands alastairp a cheap manual fan from the china shop
actually, that's not a bad idea
texke` joined the channel
ruaok
I carry one with me starting this time of year
esp if I need to wait for a metro
alastairp
nah, things are going well. I don't need to give much input, and the feedback from the reviewers has been pretty good til now
we have about 4-5 hours to present 3 years of work, so not like we can get into much detail in any of it
texke has quit
texke` is now known as texke
gcrk
lucifer, I would, but currently my storage backend is down and I cannot play any file
ruaok
yep, I still hate influx.
lucifer: mapping writer is now running with 3 threads, doing 40 listens/s
128 days to complete the mapping.
lucifer
gcrk: ah ok! no worries.
ruaok: oh nice! :DD that's much better. also, i had taken a look at the query you shared, no idea on how to speed that up but thanks for trying.
(more seriously - neat, every bit helps, probably :) )
lucifer
outsidecontext: could it possibly be an older version of the plugin? i am viewing those 5000 rows which have "None" mbid and a large number of them have that "source": "P" thing.
outsidecontext
unlikely. there is basically only one version, the entire commit history is exactly 2 commits :D
the very initial version did send "recording_mbid" even if it was empty, so you could have received "recording_mbid": null in the JSON
I guess source "P" is something else then
lucifer
right, that's the issue according to my current hypothesis.
if recording_mbid is None, then it passes as a valid mbid and at a later step gets serialized into json where it become "None".
outsidecontext
the screenshot monkey shared earlier shows the payload from what gcrk had listened to, but the source is not visible in that view
or it does not show the payload, but the data you have in the LB database actually
lucifer
right, that was the frontend view. i am checking the data in db.
outsidecontext
can you see if that one also had source P?
lucifer
yes it has
let me clean up the file and i'll share it with you.
outsidecontext
ok, that definitely must be a bug elsewhere. the FW plugin never sent anything else then "Funkwhale" as source
gcrk: lucifer and I found something. the issue happens if you configure the Last.fm plugin in FW using the compatibility endpoint in ListenBrainz. If you instead configure the actual ListenBrainz plugin it will work as expected.
It's a bug on LB side, probably with the last.fm compatibility proxy, but lucifer knows better
lucifer
ruaok: gcrk: outsidecontext: i tried some things with the LB api again and wasn't able to reproduce the issue. The issue only exists when using a Last.fm plugin to submit using the proxy api.
ruaok
oddly specific.
lucifer
that too when using the deprecated api compat endpoint.
that's with the audioscrobbler 1.2 API. don't know whether this also is a problem with 2.0
but probably yes
but that also means it is not funkwhale specific but affects all clients using the compat proxy
at least if they send an empty value for MBID, which they probably should not do
yyoung joined the channel
lucifer
ruaok: there's another issue though. if the payload contains recording_mbid: null or "" we retain it even in the LB api. should we do something about it?
ruaok
I think we should drop the key if empty/null
lucifer
makes sense. we also have a lot data in the db which already has such mbid fields so we should modify that as well methinks.
are there plans to make acousticbrainz binaries for arm/arm64?
lucifer
alastairp: ^
outsidecontext: i see, i think we do handle it correctly. the issue is something more subtle. i'll setup a funkwhale instance and try to reproduce the issue with the proxy api.
but i am still not sure how this went through our checks.
ok! i see that now. we do not validate proxy api listens.
time to dig into the AS spec and see how to propogate errors. 😞
outsidecontext
lucifer: or don't fail but ignore the faulty MBID. not sure, but given the many clients out there that's maybe safer?
especially considering this is legacy API
also last.fm itself seems to accept such requests
lucifer
yeah, i am not sure if much of the clients using legacy apis are even maintained.
outsidecontext
this
lucifer
last.fm probably doesn't verify mbids so it accepts the invalid stuff. we process this during msid calculation so its somewhat of an issue.
considering all this, its probably best to drop invalid mbid fields but still accept the listens.
ruaok: any suggestions?
outsidecontext
I think so
alastairp
tandy[m]: hi, good question. We had a look at building binaries for raspberry pi, but it didn't have sse support at the time we were looking and this had a potential to result in different calculation. we should definitely look at more "mainstream" arm chips, especially M1 but have no timeline for that yet
ruaok
lucifer: agreed, drop invalid MBIDs, accept listens.
lucifer
👍
nulachi joined the channel
tandy[m]
<alastairp "tandy: hi, good question. We had"> fair enough, i was interested in being able to run it on my server which i use to manage my music (an sbc similar to a pi, pine64 rockpro64)
kepstin
well, "sse" is a specific intel-architecture extension, arm chip floating point vector extensions are something different.
getting bit-exact floating point is a real pain across architectures. Things that really need it often end up using software floating point in order to get exact behaviour :/
(this is about acousticbrainz?)
i think even on x86 platforms, different compiler versions or optimizations were causing variations in the floating point output which is why binaries were provided in the first place.
ruaok: opening a ticket for fixing existing listens, a simple update query would lock the entire table methinks degrading services so we'll have to come up with a better solution.
zas
bitmap, alastairp, ruaok: we lack of disk space on williams, can you check if you have stuff you can remove?
ruaok
lucifer: how many rows are affected?
zas: I already cleaned up.
zas
ok, thanks
alastairp
zas: nothing I can see from my end
lucifer
ruaok: 5000 rows have mbid "None". probably many other have mbid null or "".
zas
bitmap, yvanzo: please have a look at williams
ruaok
I doubt updating 5000 rows would lock the whole table.
bitmap
ok
ruaok
but if you write a script to update row by row, it should be fine.
zas
ruaok: no news from hetzner, right?
ruaok
nothing.
long 1-2 days wait time we're waiting.
lucifer
ah row by row makes sense.
ruaok
I guess our beer swilling friends have a different sense of time than we do
bitmap
zas: I should probably limit the number of concurrent backups stored to 1 until we have more space
lucifer
i was wondering why we didn't start migrating williams as boingo was cleared out days ago :)
