Funkwhale: updated playback approach to always use search based #3362
Conversation
| playListen = async (listen: Listen | JSPFTrack): Promise<void> => { | ||
| const listenFromFunkwhale = FunkwhalePlayer.isListenFromThisService(listen); | ||
|
|
||
| if (listenFromFunkwhale) { | ||
| const funkwhaleURL = FunkwhalePlayer.getURLFromListen(listen); | ||
| if (funkwhaleURL) { | ||
| await this.playFunkwhaleURL(funkwhaleURL); | ||
| return; | ||
| } | ||
| } | ||
|
|
||
| // If not a direct Funkwhale URL, search for the track | ||
| // For Funkwhale, we always search for tracks by name since | ||
| // listens from history may contain federation URLs or library URLs | ||
| // that don't work well for direct playback | ||
| await this.searchAndPlayTrack(listen); |
There was a problem hiding this comment.
I wonder if it would make sense to try to play using the URL from the listen, keeping in mind that it may well be broken or unavailable to the user, in which case we fall back to doing the search.
It would probably mean that we would wrap the call to playFunkwhaleURL in a try...catch block, and avoid showing a toast message to the user.
In the catch block, we call searchAndPlayTrack like usual.
There was a problem hiding this comment.
i tried this but it wont worked i even tried different hardcoded combinations like /api/v1/tracks/id but this also wont work! the approach above you mentioned is failing for me because he URL stored in fw listens are web interface URL which returns HTML not audio stream URL and also audio URL require authentication and these are temporary, Every direct attempt will return HTML instead of audio, so it will always fall back to search.
There was a problem hiding this comment.
You might have to walk me through this more if I am being thick or not understanding some of the details, but I think this should be possible, after looking into the API a bit more.
From my understanding, equipped with a track ID from a specific instance, you should be able to GET /api/v1/manage/library/tracks/$trackID/ to fetch track information, which includes listen_url that you should then be able to use for playback, like we do for other, right?
I am struggling to set up oauth for testing (I think I don't have appropriate permissions), so you might have to try it yourself, but here's the info I got while inspecting my network requests on the MetaBrainz dev funkwhale instance before I broke it :
{
"listen_url": "/api/v2/listen/5c78a908-23e7-4a71-b876-ad8960e7a696/",
"description": null,
"id": 10,
"fid": "https://funkwhale-dev.metabrainz.org/federation/music/tracks/5c78a908-23e7-4a71-b876-ad8960e7a696",
"mbid": "1a23d65e-0b85-44fb-8536-8df2245ebd36",
"title": "Happy Nation",
"is_playable": true,
[ rest omitted for brevity ]
}Of particular interest here is the listen_url with which I am sure you should be able to figure out playback.
There's also the fid but I guess that's what you meant by web interface URL, it's a sort of permalink to the track.
I do see its using api v2 but the v1 docs say the same thing.
There was a problem hiding this comment.
I think I understand "when instances update their API or change their URL structure, all historical track links break permanently", but that doesn't sound to me like a reason to remove direct access entirely if we fallback to search anyway.
That being said I have little experience with funkwhale, so please let me know what your experience was to arrive at the conclusion that the track information cannot be used reliably.
There was a problem hiding this comment.
/api/v1/manage/library/tracks/$trackID/ i'll kook into this endpoint once, but talking about trackID we can also useapi/v1/tracks/id but the thing is the even we will use these two endpoint it will be little complicated like we have to keep track of trackid! i tried to use this but i got another problems with trackid.
Like when a user rebuild their server with same host_url and but when they upload song again and this time trackid will be different! and even with same host_url there will be track mismatch like the trackid saved in lb and the trackid available in funkwhale will be different and then it will simply play random songs if trackid availabale on fw side! even we change our host_url then also there is chance of track mismatch because of trackId mistmatch!
when i tried different and random stuffs i faced this issue like changing my host_url from dev-mata.... to open.audio if we use trackid then if we play same songs using two different host_url then it simply play the random song availabale on that trackid if not then switch to next priority source!
There was a problem hiding this comment.
yes this sound good until you don't consider funkwhale versions, and as far i know v2 is still in develop phase even if its available most of the user will be using older versions of funkwhale! so if we do it gonna be problem and have to handle this if we wants to use v2 to older version! we can't develop something taking consideration of a particular versions. As of now we just wanna make sure user should able to play tracks at least. Like we are still at older version of funkwhale which we were using for integrating fw and now there are some major changes happened like that athentication error fixed on latest version and even on their latest they dont have that nested artist credit which we have discussed before because of this when i play song with open.audio then artist name is not displaying, but when i use https://funkwhale-dev.metabrainz.org/ then it does!
for this also i'm also thinking making frontend more dynamic to accept both with nested artist credit and without so it should work fine with both newer and older versions!
There was a problem hiding this comment.
"origin_url": "https://open.audio/federation/music/tracks/9864e839-86b3-4ebe-8e9f-977e439a509b",
"recording_msid": "75f85c4e-9cc6-47a1-b6f6-39f96cdc6264",
"submission_client": "BrainzPlayer"
},
"artist_name": "Jasleen Royal & Stebin Ben",
-------
"origin_url": "https://open.audio/federation/music/tracks/d5c6e77f-bc22-420b-83e1-527bf4385ee6",
"recording_msid": "02d08d1e-3b7c-4e6b-bd9d-cb9437a7fece",
"submission_client": "BrainzPlayer"
},
"artist_name": "Aditya Rikhari",i've tried playing using https://open.audio and as you can see neither of sahiba song uuid is matching with https://funkwhale-dev.metabrainz.org/federation/music/tracks/d82a81cf-e082-4638-8f02-cfda4c3cf7db(pasted both as i dont know which sahiba song you mentioned) just because the both server are different and these id's are local not global!
There was a problem hiding this comment.
yes this sound good until you don't consider funkwhale versions, and as far i know v2 is still in develop phase even if its available most of the user will be using older versions of funkwhale! so if we do it gonna be problem and have to handle this if we wants to use v2 to older version! we can't develop something taking consideration of a particular versions. As of now we just wanna make sure user should able to play tracks at least. Like we are still at older version of funkwhale which we were using for integrating fw and now there are some major changes happened like that athentication error fixed on latest version and even on their latest they dont have that nested artist credit which we have discussed before because of this when i play song with
open.audiothen artist name is not displaying, but when i usehttps://funkwhale-dev.metabrainz.org/then it does!for this also i'm also thinking making frontend more dynamic to accept both with nested artist credit and without so it should work fine with both newer and older versions!
the issue i mentioned above is already created by @RustyNova016, i'm thinking of fixing by this week! i'll kook how can i accept both nested artist credit and without nested artist credit response!
There was a problem hiding this comment.
i've tried playing using
https://open.audioand as you can see neither of sahiba song uuid is matching withhttps://funkwhale-dev.metabrainz.org/federation/music/tracks/d82a81cf-e082-4638-8f02-cfda4c3cf7db(pasted both as i dont know which sahiba song you mentioned) just because the both server are different and these id's are local not global!
Indeed you can't use the UUID from one pod to try to play from another pod, as you say the IDs are local.
However the pods can be federated, and you should be able to play a track from pod 2 if you hit the API of pod 1, provided you have the right authorizations on both pods and the pods are federated (linked together).
There was a problem hiding this comment.
for this also i'm also thinking making frontend more dynamic to accept both with nested artist credit and without so it should work fine with both newer and older versions!
the issue i mentioned above is already created by @RustyNova016, i'm thinking of fixing by this week! i'll kook how can i accept both nested artist credit and without nested artist credit response!
That's great, thank you!
| }; | ||
|
|
||
| extractTrackIdFromURL = (url: string): string | null => { | ||
| const trackMatch = url.match(/\/tracks\/(\d+)/); |
There was a problem hiding this comment.
I will note that currently, this regexp does not match UUIDs and only expects a numerical ID.
We could have two different regexps to match either /tracks/$numerical_id or /tracks/$UUID for federated links.
Another option would be to match more segments of the URL:
https://regex101.com/r/kN6E9y/1
/\/federation\/music\/tracks\/([0-9a-f]{8}-[0-9a-f]{4}-[0-5][0-9a-f]{3}-[089ab][0-9a-f]{3}-[0-9a-f]{12})/ will match a UUID for a federated link like https://funkwhale-dev.metabrainz.org/federation/music/tracks/d82a81cf-e082-4638-8f02-cfda4c3cf7db
There was a problem hiding this comment.
i think will face same problem for uuid as like trackid? like both are locally assigned not globally? have to look more about this. Getting more complicated :)
There was a problem hiding this comment.
The problem with this specific regex is that if the url is for example https://open.audio/federation/music/tracks/9864e839-86b3-4ebe-8e9f-977e439a509b, it will return the ID 9864, the first numerical segment of the UUID until it hit a letter, which is an incorrect match regardless of how we end up using IDs or search.
There was a problem hiding this comment.
Got it but i think we need this when we take uuid in consideration? i'll add this while implementing rest or should i create a new pr?
MonkeyDo
changed the title
|
So I'm not exactly sure where we are at now, but I am convinced there are perfectly good use cases for playing directly from a federated URI instead of relying on search. At the very least, if I am signed into a FW instance in LB and I try to play a listen which has an For the rest, you will need to spend more time testing how federation works in FW. To summarize, I don't think we should entirely remove direct track playback, there are use cases where it saves data and makes sure we are playing the right track. |
Sounds good to me but i think we have to wait and explore more about this definitely we can make a fallback mechanism, but i'm thinking of giving this a bit more time as i can see the funkwhale is working fine for me and to other users as well haven't seen any issue reported by anyone by now except that artist name one! i'll ask assistance from funkwhale community and try to debug, and thinking of creating a issue as well if someone know funkehale better can assist us a bit, wat you say? |
There was a problem hiding this comment.
OK, thanks for the discussions and patience, I think we are getting somewhere:
- I think there are some aspects of FW federation neither of us arefamiliar enough with to take a decision
- I think some aspects of FW federation are tied to their API v2, and maybe are in development
- I think we can still improve the mechanism to allow some direct playback, and fallback to search
- It is a great idea to ask the FW team how to do our specific scenario, but first we need to understand how pods are federated between themselves, otherwise we are missing some information I think.
|
|
||
| if (listenFromFunkwhale) { | ||
| const funkwhaleURL = FunkwhalePlayer.getURLFromListen(listen); | ||
| if (funkwhaleURL) { |
There was a problem hiding this comment.
Thanks for your patience, these discussions we had about FW and our different use-cases and issues have been very useful.
For this PR, I think instead of removing this section to play directly from a FW URL, all we need is to add a check right here that the URL partially matches my FW instance.
Considering the issue is that my FW track URLs will only work reliably for my instance, we can check if it's a match.
That way, if I go to my own listens page on LB I have higher chances of being able to play the exact right track from my own instance.
If that fails, or if the FW URL does not match my won instance (i.e. the track URL is on another FW instance) we can fall back to the search mechanism.
So to be clear
- if a listen comes in that has
track_metadata.additional_info.music_servicecontaining "funkwhale",listenFromFunkwhalewill be true. - Now calling
getURLFromListenwill return eithertrack_metadata.additional_info.funkwhale_idif it exists, ortrack_metadata.additional_info.origin_urlif it is a FW URL. - Now I can check that this matches the value of
getFunkwhaleInstanceURL.- sanitize the instanceURL, ignoring
http:///https://and trailing slash: https://regex101.com/r/s9kTxs/1 - then something like FWListenURL.includes(sanitizedInstanceURL)
- sanitize the instanceURL, ignoring
- If yes, use
playFunkwhaleURL. - If no, or if
playFunkwhaleURLfailed, continue to search mechanism.
2 participants
Track based approach was creating multiple problems. Unlike centralized services like Spotify where every user accesses the same, fw allows each user to have their own personal music library on the same server, and different servers can federate with each other, which means tracks id for individuals can be mismatched. track id are specific to individual libraries and servers, if a user switches to a different fw server, all their listens songs will break and whenever he tries to play songs he'll get errors like server error, because the server or trackid don't exist or mismatch on the newer server, and also when users share listens with others on different instances, those track often point to music that doesn't exist in the others accessible library, causing constant track not found errors. Federation URLs can become broken links when servers go offline or change their federation settings.
Even on the same server, trackid from one user's library may not be accessible to another user, leading to permission errors and track mismatches. when instances update their API or change their URL structure, all historical track links break permanently.........
So its better to search a song each time, as of now this is best option for us.
[off] thanks to
datasourceRecordsListensxd;