Closed pascalla closed 3 years ago
@pascalla My idea on the cause of this is that the first time a song with this ID was registered in the songs
table, it was registered exactly as you're seeing it, which is with a "Title" field but no "Artist". Since we depend on that table to pull song information in the absence of a StationMedia
entry, it would just always rely on that previous entry in the songs
table.
Believe it or not, this is actually a holdover from the pre-2016 era of AzuraCast, when it was just a silly pony thing. The idea was that we would manually drop into the database, edit how the song was represented in the songs
table, and then any time it showed up on any station, it would appear "correctly". Of course, in AzuraCast there is no way to manage the contents of the songs
table, so it's largely an unnecessary appendage.
We have some large changes planned as part of our Hacktoberfest work, and that will include removing this now-vestigial functionality inside the application, which should also fix this issue and other ones related to it.
@pascalla Our most recent series of commits should resolve this issue by decoupling the old "Songs" table and having each history record maintain its own internal text/artist/title listing.
@SlvrEagle23 Updated to latest f4b410f. No artist, is still empty. Not only the new tracks for Azuracast, every tracks is now artist empty. Same for Public Page and Dashboard page.
@pascalla This should be fixed as of the newer updates.
@mellis85 Are you sure you're having the exact same issue that was reported here, i.e. with titles showing "Artist - Title"? That shouldn't be happening because of our NowPlaying library and the protections built into it for that kind of thing.
Updated today and the issue still seems to persist. It's been fine with AutoDJ media still.
@pascalla Seems this is caused by a scenario where only a hyphenated title
metadata field is sent and no text
value is present, which short-circuited the logic in our NowPlaying library and kept it from de-hyphenating things correctly.
This should be fixed as of the latest update.
As of #838debe it seems that all is working correctly! Thanks for the wonderful work once again :) <3
EDIT: As of recently I notice the mysqld usage is higher than previously, I assume this is due to the new songs table.
@pascalla Good to hear.
As for the MariaDB load, we actually removed the Songs table in favor of putting its data in other places to avoid having a huge volume of "un-trimmable" and un-modifiable data in the DB.
We also switched from InfluxDB to doing direct analytics from the DB, which would bump the load up, but only on the hourly analytics runs at the top of the hour, and even then it shouldn't be that significant of a bump, but if you're noticing that task take an unusually long time let me know and I can look into optimizing it.
Using Docker installation method Yes
AzuraCast version Rolling Release #ac0dc6e (2020-09-29 16:59) • Docker • PHP 7.4
Host Operating System Ubuntu 16.04
Describe the bug Now Playing API does not have artist.
To Reproduce
Expected behavior I was seeing some webhooks failing on my end due to an 500 error. This was due to missing items that it was expecting from Azura.
A selection of songs come through into liquidsoap with the artist and title correctly, however somewhere along the line the songs get bundled together into just being a title. This means when my API is expecting the artist/title seperately it fails. (This part is on me but >.> <.<).
Screenshots/Logs
![image](https://user-images.githubusercontent.com/22846433/94945037-ff219900-04d1-11eb-92a6-1cdb8f72db91.png)
Additional context I'm trying to find out what causes the song to have this state. My current working theory is songs that aren't in the media browser.