search

AzuraCast / AzuraCast

A self-hosted web radio management suite, including turnkey installer tools for the full radio software stack and a modern, easy-to-use web app to manage your stations.
https://www.azuracast.com/
GNU Affero General Public License v3.0
3.01k stars 557 forks source link

Now Playing API has empty artist #3226

Closed pascalla closed 3 years ago

pascalla commented 3 years ago

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

  1. Play songs that are new to the azura system ( I think they can't be on the AutoD)
  2. Check the nowplaying API

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 image

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.

BusterNeece commented 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.

BusterNeece commented 3 years ago

@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.

hdman commented 3 years ago

@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.

BusterNeece commented 3 years ago

@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.

pascalla commented 3 years ago

Updated today and the issue still seems to persist. It's been fine with AutoDJ media still.

image image

BusterNeece commented 3 years ago

@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.

pascalla commented 3 years ago

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.

BusterNeece commented 3 years ago

@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.