Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Recently Played Anomaly
16-07-2022, 19:35
Post: #1
Recently Played Anomaly
I am very much enjoying having the recently played list addition to Minimserver. I have come across a small anomaly.
I am using Minimserver with Linn hardware and Linn Kazoo and the Linn App mostly on iPad. If I add tracks to a new playlist with say TrackA first in the list and then play through the playlist to the end the recently played list is built correctly however SOMETIMES TrackA is recorded as the last track played (even though it was the first). I am sorry I cannot give an exact use case that reliably demonstrates this. I believe it is something to do with the fact that when a playlist is completed the pointer indicating the next track moves to the first track in the list.
Has anyone else noticed this?
I will keep an eye on this and try and identify a reproducible example.
Find all posts by this user
Quote this message in a reply
17-07-2022, 09:58
Post: #2
RE: Recently Played Anomaly
MinimServer doesn't know if a track has been played by the user, only that the renderer has requested the stream from the server. For some reason, Linn renderers can request a stream in the circumstances that you have described and read a small amount of data without playing the stream. In this case, MinimServer doesn't know that the streaming request was internally generated by the renderer and didn't come from the user.
Find all posts by this user
Quote this message in a reply
17-07-2022, 19:38
Post: #3
RE: Recently Played Anomaly
When the playlist reaches the end, it goes back to the beginning and displays the artwork for the first track in the playlist but does not play the track.
It might be the request for the artwork, artist, album, track name that adds to the recently played index.
Find all posts by this user
Quote this message in a reply
17-07-2022, 20:52
Post: #4
RE: Recently Played Anomaly
I tried this. When the renderer had finished reading the last track (about 24 seconds before the track finished playing), it started reading the first track again. The renderer read about 14% of the audio data in the first track but didn't play any of this audio.
Find all posts by this user
Quote this message in a reply
17-07-2022, 21:35
Post: #5
RE: Recently Played Anomaly
Thanks Simon. I suspected it was something to do with the way Linn process the end of the playlist. I will post this in the Linn Development Forum just so they know but I suspect this is fundamental to the way Linn works...
Find all posts by this user
Quote this message in a reply
21-07-2022, 09:10
Post: #6
RE: Recently Played Anomaly
Linn have confirmed that this behaviour is normal as it is part of their strategy for implementing gapless playback. As such it cannot be changed. I suppose in part this comes down to the definition of 'played'. I wonder if it would be easy for you to implement a check to only record as played tracks that stream for more than say 30secs. This would also do away with the occasions when I accidentally click on a track whilst browsing. If it's not easy it's no big problem and I am personally more than happy with the functionality as it stands.
Find all posts by this user
Quote this message in a reply
21-07-2022, 12:23 (This post was last modified: 21-07-2022 13:04 by simoncn.)
Post: #7
RE: Recently Played Anomaly
The present approach is simple and reliable although it can sometimes result in false positives. To do as you suggest could create false negatives where a track is less than 30 seconds long or when a track is deliberately played and stopped after less than 30 seconds for some reason. Also, some people might be OK with 30 seconds and some might want a longer or shorter cut-off. On balance I think the present simple approach is best.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)