time and title display wrong after resume

[IDC-Dragon]

Like written here: LMS-Community/slimserver#699 (comment)
Radio Paradise (interactive) always resumes to the beginning of a song.
Fine with me if there is a limitation, however the time display thinks it is where left off, and runs with an "offset" from then on. This affects also the title display, will show already the next title when the time hits the track end. Everything is shifted, until a manual track skip fixes it. Also, the announcements seem to be barriers.

[michaelherger]

Can you please provide exact steps how to reproduce this behaviour?

[IDC-Dragon]

• have resume enabled in the player settings: "Pause at power off / Resume at power on"
• title display as screensaver with short timeout when playing helps to see
• play Radio Paradise interactive stream
• leave it playing, say, 2 minutes into a track
• cut player power
• wait long enough for LMS to give up the player (and RP to play something different meanwhile)
• power up the player

=> playback resumes from the beginning of a track, but the time display shows the previous 2 minute position

• let it play until the (wrong) time hits the end of the current track

=> title display changes, shows the next, upcoming song and time counts from 00:00, despite in fact still playing the previous for 2 more minutes. This time offset will stay during upcoming playback, titles change too early. Especially annoying if it was more than 2 minutes, rather the length of the resumed song, in that case title display is completely off.

[michaelherger]

Heh... interesting. With this description this reminds me more of what LMS-Community/slimserver#797 tries to fix, than the issue where you reported this initially. I'll play around with this. Thanks!

[michaelherger]

What kind of player are you using? I'm currently testing with Squeezeplay, and that seems to behave as expected after some short testing. I see you mention a SB2 and a SB Touch. Do they really behave the same?

[IDC-Dragon]

SB2, can do test on Touch, too.

[IDC-Dragon]

Test on SB Touch confirmed same behaviour: I've cut the power at 3 minutes, restored it like half an hour later. New title was played from the beginning but displayed 3 minutes within, title change was shown 3 minutes too early. The offset stayed, continued after the next song, too.

[michaelherger]

Ok, I think I've been able to reproduce. Probably didn't wait long enough in yesterday's attempt - or there is a difference between Squeezeplay and the Touch.

So when the new track starts playing after the re-connect, track info is correct except for the time.

[michaelherger]

Hehe... turns out this is a LMS issue after all... any source which doesn't support seeking would fail this way. But as RP probably is one of the most prominent example this hadn't surfaced yet. Thanks for insisting! Should be fixed in the next 8.3.0 build.

[IDC-Dragon]

Sorry to say, case not closed for Radio Paradise. (No long term test yet.)
Now we are trapped in a block of songs, which will start over on each resume.
Setting the saved time to zero means start of block?

So it seems, RP could resume, playing from the start of the track was somewhat artificial? If this is still desired, the saved time would need to somehow be rounded down to the track start.

Maybe with some longer break that block of songs won't be available any more, don't know how to distinguish.

[michaelherger]

I don't understand the "trapped in a block" part. Yes, it would pick up the same block it was playing before. But once that block has finished playing it would fetch the next block as expected.

Sure, if you pull the plug within the first track of the block after resuming, you'd repeatedly resume on the same track. But what do you expect? The resume function is supposed to resume from where you left.

[IDC-Dragon]

Yesterday we got the same group of songs again and again, 3 times. Felt like groundhog day (but wasn't Sonny and Cher ;-).
A block size seems to be larger than our normal listening time. Needed active skipping to go past.
Maybe it is just coincidence that RP was able to play out the same block. I thought this is because of setting the saved time to zero has changed the playback behaviour.

Even if I pull the plug during the last track of the block, it resumes with the first. Was that different, did a seek happen?

[michaelherger]

Ok, I can confirm that it would resume on the first track of a block. That's a limitation which might be hard to work around. I didn't notice before, as I always pulled the plugin in the first track. RP tends to play longish tracks makes testing more tedious 😂.

I run another test where I pulled the plugin on the second to last track in the block. It resumed on the first, but correctly fetched a new block once it had played through. I can't reproduce Groundhog Day. Did you get the same block over and over again without any new interruption?

[IDC-Dragon]

It is not repeating the block by itself. What I meant, our average listening time may be 20 minutes, powering off after that. When powering on next time, we hear the same 20 minutes again.

[michaelherger]

"powering off" as in pulling the plug? Or soft-power off?

[IDC-Dragon]

As in pulling the plug. The SB2 is slave to the stereo power, so it gets cut when switching that off.

[michaelherger]

Ok, that's a rather specific use case... but this sounds like something automated. Then I wonder: why use the interactive stream at all? I'd recommend you use the regular FLAC stream instead. This is too much of a corner case to try to fix...

[IDC-Dragon]

Naa, we're not that automated. ;-)
Interactive is essential, Radio Paradise sometimes has a wider scope of taste than us. It is a real great unique feature to have radio where you can skip songs.

I still wonder if yesterday's groundhog day was a coincidence. Before the change, does the nonzero saved position affect the playback behaviour, or only the display? If it does seek, how come it played always from the beginning of a track?

[michaelherger]

I don't think it was a coincidence, it actually makes sense, considering the implementation's limitations and your use case: one block can be anything from one to a dozen or so tracks. Which means it could be a few seconds (a RP jingle) or an hour long. If you happen to be in a block longer than 20 minutes, and you hard shut down the player every 20 minutes, you'll end up in the situation you're describing. As the block as a whole is considered the stream by LMS, and it can't seek to the latest position, it'll start over on each resume.

My next suggestion would be not to hard power down the player all the time...

[IDC-Dragon]

Let's see how it behaves in the long run. Maybe RP didn't give me the same block again in the past, just yesterday, and I'm hunting ghosts, sorry for the confusion.
Technically asking, my question is still open: Does a nonzeo saved position affect the playback of a block?

[michaelherger]

Let's see how it behaves in the long run. Maybe RP didn't give me the same block again in the past, just yesterday, and I'm hunting ghosts, sorry for the confusion.

See my previous response. You're not hunting ghosts.

Technically asking, my question is still open: Does a nonzeo saved position affect the playback of a block?

Yes. It causes the time offset issue you reported.