Closed mihawk90 closed 3 years ago
Works fine for me with soundcloud, are you sure this is not an issue with pretzel? I did update the supported format options though.
Hm I'll have to look into that again later then 🤔
OK so the artist was indeed an issue with my Pretzel implementation. That's what I get for not copy/pasting code for once ;) I didn't realise Tuna expected an array of artists.
So that's fixed now in the linked commit.
However, I can still not get the Album to show, and that doesn't seem to be working in your Screenshot either. The soundcloud code clearly defines and sends the album:
But it is not in the JSON either.
Is this dependant on 8861a41 ? I wouldn't think so as Artist works just fine without it as well.
No I think those are only used for the format dialog right now.
Updated the issue title since it's only the album title now.
Artist was resolved because of my mistake and track number isn't supported at all (which arguably is fine because I don't think any web player even lists track numbers). But it doesn't seem Album is working properly.
Okay, so the metadata is checked when writing the song to json, which should probably be simplified a bit. Album is just plain missing here, which is an easy fix.
Mh coming back to this, if I understand correctly just copying and changing the blocks above should be enough right? But that gets me thinking are we using album
? album_url
? both? The browser script still has mixed usage. scratch that, it's not mixed, but just confusingly named, the value is sometimes URL sometimes name though.
I could technically do both, but the file-write only supports one of them anyway (whichever that is).
I could technically also check for both and use whatever is available (preferring album
over album_url
?).
Ideally we should probably clean up the Browser script though if one of them is unused (as per your comment here), or decide on actually using both if available.
What's your preference?
The capability is called cover but I think that cover_url is more precise, as it will always either be http(s)://link.to/cover.png
or file:///link/to/cover.png
. So it should probably be cover_url
everywhere which would require changes here:
album_url
is being sent by the user script, but it's never parsed. It's just the link to the album on Spotify or whatever service is used. #130 technically could make use of that, but for now it's unused.Yeah cover makes sense, that's not a question :)
I was more referring to album
and album_url
. Should I include another block for album_url
so we can eventually use both? Or just leave it out for now (and therefore only sending album
makes sense in the script)?
edit:
Actually, I'm dumb... there's no set_album_url()
or anything anyway so I couldn't even do that...
Tuna version: 1.6.1 (just updated)
Describe the bug Currently no song information (except title) is returned for information coming from the Web browser source. This affects both the file-writing ability, as well as the JSON returned for the Widget. This unfortunately renders the Web browser source essentially non-functional. This actually also breaks the Widget completely (until #155 is merged).
To Reproduce
Title: %t Artist: %m Track Number: %n Album: %a Progress: %p Length: %l Time Left: %o
%t
).Expected behavior Ideally all submitted format options would be written to file and returned as JSON
Screenshots Funny enough, this is actually the only option that works:
Log Not much Tuna related in there, but here we go: https://obsproject.com/logs/p3BL6-QoW79TwE9a