Azuracast: The playlist field of the nowplaying API result is sometimes empty

[Vaalyn]

Installation method
Docker

Host OS (for Docker installations)
Debian 9

Describe the bug
The nowplaying API sometimes returns an empty string for the playlist field of the current_song, playing_next and song_history.

Expected behavior
If the song is from a playlist the playlist field should be set.

Screenshots
http://prntscr.com/lr8hby

[macbroadcast]

Thanks, for reopening seems not fixed :smile:

[Vaalyn]

Did some debugging to get an idea about where this issue is coming from exactly. Here is what I gathered so far:

• All StationMediaPlaylistMedia have a StationPlaylist
• SongHistory has ~300 entries where playlist_id is NULL
• SongHistory has ~70000 entries where playlist_id is not `NULL'
• Entries with NULL are not all new but spread over the whole id range of the existing entries
  
  
  
  • can't be a new problem then
  
  
• Too few entries to completely explain the missing playlist value in the API result
• Following SongHistory entity has no value for playlist in API result but database entry has a playlist_id

SELECT id, song_id, playlist_id, sent_to_autodj FROM song_history WHERE station_id = 1 ORDER BY id DESC LIMIT 3;

| id    | song_id                          | playlist_id | sent_to_autodj |
+-------+----------------------------------+-------------+----------------+
| 71093 | b2b31d029e3159a7f067ea27abd8d2aa |           1 |              0 |
| 71088 | 6b35e83859b79703978a2c0d785bc96c |           1 |              1 |
| 71085 | 4ce1a7af456875634d04dac9fb40306c |           1 |              1 |
+-------+----------------------------------+-------------+----------------+

"playing_next": {
    "sh_id": 71093,
    "played_at": 0,
    "duration": 221,
    "playlist": "",
    "is_request": false,
    "song": {
        "id": "b2b31d029e3159a7f067ea27abd8d2aa",
        "text": "PinkiePieSwear - Winter Wrap Up (Late Again)",
        "artist": "PinkiePieSwear",
        "title": "Winter Wrap Up (Late Again)",
        "album": "",
        "lyrics": "",
        "art": "http://mydomain.com/api/station/1/art/2bbd3344795cc13a725ea029.jpg",
        "custom_fields": []
    }
},

To summarize what I can see from this is that there are actually 2 problems. The first one is that sometimes, rather rarely, a SongHistory entry is saved without a playlist_id to the DB. The second one is that for some SongHistory entities the playlist is not populated when retrieved from the DB for the API result.

I couldn't pinpoint where either of these problems is originating from exactly yet. Has anyone an idea what could be the culprit here?

[replayfactory]

I noticed this issue a long time ago. It always happens (for me) on playlist change, on the first played song.

Before playlist was implemented to the azuracast API, I used this "dirty" SQL query to retrieve the playlist name.

php SELECT name FROM azuracast.song_history sh, azuracast.station_playlists sp WHERE sh.timestamp_start != '0' AND sh.station_id = $args AND sh.playlist_id = sp.id ORDER BY sh.id DESC LIMIT 1;

hope this will help for debugging...

[SlvrEagle23]

@Vaalyn @macbroadcast @replayfactory This should be fixed now.

Long story short, when you initially set a related value using Doctrine, it sets the value itself but not the identifier for the value, i.e. it sets $this->playlist but not $this->playlist_id. Since the API generator was looking for the latter, it would only exist if the record was queried later from the database instead of being returned immediately upon generation.