[DLNA] [NextTrack] [Gapless] Fix 5644 and 5294

[ssenart]

[DLNA] [NextTrack] [Gapless] Fix 5644 and 5294

Fix 5644 : [DLNA] [Music] Next track command from any DLNA device does not do anything
Fix 5294 : gaps between tracks ...

Changes

Implement the new DLNA message SetNextAVTransport() that permits to the renderer to prefetch the next track to play in the list.
It will have an effect if the renderer implement that feature :

• On my Sonos, it works perfectly.
• On my Marantz, I have to select 'replay once' option for it to work => strange.
• On JRiver Player, it works perfectly.
• On BubbleUPnP Android Player, it does not work at all : Possibly SetNextAVTransport() feature is not supported.

The other positive effect is that it removes the gap between tracks.

Feedbacks on other renderers are welcome !

Issues

Fixes #5644
Fixes #5294

[BaronGreenback]

Note to whomever: SetNextAVTransport isn't supported by all devices - so when mentioning gapless playback in any documentation should be qualified with "if supported".

[BaronGreenback]

Not particular to this change, and would welcome comment as I may be over cautious - but shouldn't all playlist array lookups be behind some form of locks.

Only say this as it would be possible for the dlna devices trigger events which effect the list at the same time.
eg. OnDevicePlaybackStopped clears the playList - so theoretically cause an index out of bounds.

[BaronGreenback]

Nice bit of coding. However, I suspect this will fix #5664 only under certain conditions; namely the device supporting this command, and the command having enough time to be transmitted and processed by the device. I suspect clicking next/next/next/next will cause some issues on a slow server, and #5564 will return.

Hadn't seen #5664, but I suspect the underlying issue is with the next/last/random functionality in the SendPlayCommand method. The version in the playTo plugin (https://github.com/BaronGreenback/Jellyfin-DLNA-PlayTo/tree/master/Jellyfin.Plugin.DlnaPlayTo/Main) is a modified verson which seems to work for me.

[ssenart]

Not particular to this change, and would welcome comment as I may be over cautious - but shouldn't all playlist array lookups be behind some form of locks.

Only say this as it would be possible for the dlna devices trigger events which effect the list at the same time.
eg. OnDevicePlaybackStopped clears the playList - so theoretically cause an index out of bounds.

Since all is coroutine (async/await), should not all this code be executed by the same single thread ?

[BaronGreenback]

Not particular to this change, and would welcome comment as I may be over cautious - but shouldn't all playlist array lookups be behind some form of locks.
Only say this as it would be possible for the dlna devices trigger events which effect the list at the same time.
eg. OnDevicePlaybackStopped clears the playList - so theoretically cause an index out of bounds.

Since all is coroutine (async/await), should not all this code be executed by the same single thread ?

Again - confusing with the callbacks on the next version.

[ssenart]

I agree. SetNextAVTransport() support is mandatory on Device side. Otherwise, it behaves as before without the fix.

You're right, clicking next/next/next/next without waiting few seconds between may do nothing. The explanation is still with this Timer that resynchronize with the Renderer every 10 seconds (hardcoded). The click on next button is taken in account just at resynchronization time and a new SetNextAVTransport() message is then sent.