search

michaelherger / RadioParadise

Listen to Radio Paradise in lossless FLAC quality on your Squeezebox (Lyrion Music Server - fka. Logitech Media Server)
7 stars 4 forks source link

time and title display wrong after resume #6

Closed IDC-Dragon closed 2 years ago

IDC-Dragon commented 2 years ago

Like written here: https://github.com/Logitech/slimserver/pull/699#issuecomment-1191306836 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 commented 2 years ago

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

IDC-Dragon commented 2 years ago

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

=> 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 commented 2 years ago

Heh... interesting. With this description this reminds me more of what https://github.com/Logitech/slimserver/pull/797 tries to fix, than the issue where you reported this initially. I'll play around with this. Thanks!

michaelherger commented 2 years ago

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 commented 2 years ago

SB2, can do test on Touch, too.

IDC-Dragon commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

IDC-Dragon commented 2 years ago

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

michaelherger commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.