Sometimes I notice the current song and the song that follows it in a playlist, playing at the same time. Whilst I am aware that some overlap may be deliberate as we transition from one to the next, on occasions, I notice that concurrent playback happens for long periods Today I noticed it at about 09:58 am
PlexAmp Public Release 4.10.1.1254
iPhone 13 Pro
iOS 17.4.1
Using Apple CarPlay
I thought i should mention this. Low priority issue
I believe it was these two tracks - extract from the log
Apr 12, 2024 09:57:29.536 [Javascript] INFO - Player: Sending state changed [A] Tony Bennett - Body and Soul (214/200071) in state playing with artwork true.
Apr 12, 2024 09:57:29.554 [Javascript] INFO - Player: Sending state changed [A] Amy Winehouse - October Song (214/204904) in state playing with artwork true.
I’ve added you to the external testers group, you should have access again. Feel free to DM me an email and I can invite you into the plexamp slack channel if you wish.
Thanks for the reply. OK so it is just long fade-out/in’s.
That 12 second overlap was another day. I was not aware overlaps could be that long.
Looking at the plexamp logs, there is a lot that had more than 3-4 seconds - which is where I expected it to be at. I did not expect overlaps for fading to get as high as that.
Looking at the 6 log files, we have
stream (playQueueItemId)
overlap band
overlap (sec)
462170
6 to 12
12.2
462171
2 to 4
2.9
462172
6 to 12
6.4
462173
6 to 12
6.7
462174
5 to 6
5.4
462175
6 to 12
9.6
462176
2 to 4
3.6
462177
6 to 12
12.8
462178
4 to 5
4.7
462179
4 to 5
4.7
462180
6 to 12
6.5
462181
6 to 12
7.6
462182
6 to 12
8.9
462183
4 to 5
4.6
462184
6 to 12
8.5
462185
4 to 5
4.6
462186
2 to 4
3.3
462187
6 to 12
10.7
462188
6 to 12
8.9
462189
6 to 12
7.3
462190
2 to 4
3.4
462191
6 to 12
7.9
462192
5 to 6
5.7
with a lot over 6 seconds
overlap band
count
%
2 to 4
4
17%
4 to 5
4
17%
5 to 6
2
9%
6 to 12
13
57%
PS: if one needs to find out what the tracks were to investigate afterwards, it is not possible because the stream (playQueueItemIds) appear to get purged from the PMS database - would help if we also logged the metadataID on this log line
The current max overlap is 15 seconds (we lowered it from what it used to be). There’s an argument it should be lower. What kind of music are you listening to? It’s possible with e.g. classical the overlap might not work well at all.
They’re purged when the next play queue is created by the specific client; we don’t have the actual metadata item ID at the point where that information is logged.
