Possible fix for Starting song radio from queue creates a queue based on the wrong song #263

[Millencolin]

What is it?

• New feature (user facing)
• Update to existing feature (user facing)
• Bugfix (user facing)
• Codebase improvements or refactors (dev facing)
• Other

Description of the changes in your PR

This is a possible fix for #263.

However:
It would probably be better to call startRadioSeamlessly with mediaMetadata as parameter and handling the logic of selecting the right songs in there.

Also adding another method in queueBoard to handle adding the songs and start it without interrupting the currently playing song would probably be cleaner than calling queueBoard.addQueue / queueBoard.setCurrQueuePosIndex.

I didn't want to start modifying too many things and let you use this code as a base to fix the issue

[mikooomich]

Ah. I see you've stumbled upon mymultiqueue mess.

Other than continuation not being supported, seamless switching (I didn't know this existed) isn't either. For non-seamless, it isn't hard, just do this and queueboard should already handle it fine.

playerConnection.playQueue(YouTubeQueue.radio(song.toMediaMetadata()))

For seamless, media items in player can be updated with player.replaceMediaItems() without interrupting playback, then sync with queueboard as you said ---> the add function in queueboard needs to be modified for seamless...... and that should be it(?)

Also adding another method in queueBoard to handle adding the songs and start it without interrupting the currently playing song would probably be cleaner than calling queueBoard.addQueue / queueBoard.setCurrQueuePosIndex.

I think shuffle, enqueue, reorder all modify the player seamlessly, but do so in different ways. Would it be better to have one function to handle all this instead?

[Millencolin]

I updated the code:

It now uses playerConnection.playQueue(YouTubeQueue.radio(song.toMediaMetadata())) to start playback from the android auto song radio toggle as well ( I saw that you already changed that in one of the calls using startRadioSeamlessly )

To make seamless playback work I did the following:

Modified QueueBoard::setCurrQueue:

• If the currently playing song matches the first item of the media items that we are adding => seamless playback: I remove all songs from the player except the currently playing one and add the new items. (player.replaceMediaItems does not work since it seems to stop playback)

• If the first item of the media items does not match the currently playing song it replaces the whole list of media items in the player which matches the current behavior

[mikooomich]

@Millencolin I added continuation back (so radio is endless now), and did some tinkering with the seamless stuff to accommodate that. In short, seamless works for any case where the current song == song to play after switching queues. Let me know your thoughts.

[Millencolin]

I think it is not working properly, didn't have time to look into the code for details

Example

1. Start a radio -> It adds 51 songs
2. Manually start playing a song in the queue (eg. pos 4) and then click on start radio -> It creates a new queue and starts a radio seamlessly but the new queue has more than 51 songs in it. At the same time the queue from 1) suddenly has a few additional songs. I would have expected the old queue to be untouched and the new one to have 51 songs from the new song radio.

Other thing for seamless playback:
When it reaches the end of the queue it adds additional songs, in my case it adds another ~100 songs, why not ~50 like a normal radio? Also the first song of the additional songs matches the last one in the existing queue -> twice the same song in a row, probably the first song from the additional song radio songs has to be removed

[Millencolin]

Found the issue for the additional songs in the queue...
It came from the caching of the playerIndex in the refactoring. The player index becomes the first item after the first if clause... since the songs before it have been removed => It does not clear all songs

val playerIndex = player.player.currentMediaItemIndex
// player.player.replaceMediaItems seems to stop playback so we
// remove all songs except the currently playing one and then add the list of new items
if (playerIndex> 0) {
    player.player.removeMediaItems(0, playerIndex)
}
if (playerIndex < player.player.mediaItemCount - 1) {
    player.player.removeMediaItems(playerIndex + 1, player.player.mediaItemCount)
}

[mikooomich]

Shouldn't be duplicates anymore (oops by bad). I'll probably squash all the fix seamless commits, so we're left with initial seamless, improved seamless, and continuation as 3 commits only so the commit history is more readable

Let me know when ready to merge

[Millencolin]

Hmm, i could still see the duplicate song somehow. I pushed a small fix which I think fixes it. To reproduce the issue: Start a radio, click on the second last song so that the queue expands, you will see the last song twice

One thing that I also just saw is that when you use continuation multiple times it is adding the same list of songs again
YouTubeQueue(WatchEndpoint(songId)).nextPage() probably returns the same list

For me it is ok to reorder and squash commits

[mikooomich]

SIGH. now it should no longer load the same mix over again

[Millencolin]

I think it looks good now.

BTW: Continuation stops working if you close and reopen the app. Probably because is does not persist the playlistId yet

  /**
     * Song id to start watch endpoint
     * TODO: change this in database too
     */
    var playlistId: String? = null,

[mikooomich]

I think it looks good now.

BTW: Continuation stops working if you close and reopen the app. Probably because is does not persist the playlistId yet

  /**
     * Song id to start watch endpoint
     * TODO: change this in database too
     */
    var playlistId: String? = null,

eh? I thought I just fixed that (old queues will have to be removed and re-created)

[Millencolin]

Your fixes work fine.

However if you play a song radio with continuation and then force close the app and reopen it, continuation is not working

[mikooomich]

now I think all the bugs have been squashed. Coding the initial radio while sick was a mistake.

[Millencolin]

Haha, works fine now