SqueezeAMP and odd pause/restartbehaviour

[mherger]

I've been using SqueezeAMP for almost two weeks now daily. I did notice
one oddity: I control it through a Radio which is sitting on my desk. I
power up my favorite radio station in the morning pressing one of the
presets. Before leaving I "power off" the unit by pressing the Radio's
Power button. So far so good.

Next morning/later in the day I'd do the same again: press preset #1.
Playback would start as expected.

BUT: the display's status would not update until the first title change.
It would stick with what was played last in the previous session until
there's some new information _while_ playing.

I've done the same with a pCP based player for years. And I'm using a
similar setup in another place (pCP with display controlling the
Transporter). But I've never seen this behaviour before. Unfortunately I
haven't found the time yet to really investigate this. Therefore my wild
guess: could there be some slimproto missing telling LMS about the
player's state?

Because there's one other oddity I'd like to blame slimproto for: after
unplugging the SqueezeAMP and leaving it powered off (because I f... it
up somehow and need to re-flash it using serial...) it would not
disappear from LMS. Other players disappear after a few minutes.
SqueezeAMP just stays there in the player list.

--

Michael

[philippe_44]

I've been using SqueezeAMP for almost two weeks now daily. I did notice
one oddity: I control it through a Radio which is sitting on my desk. I
power up my favorite radio station in the morning pressing one of the
presets. Before leaving I "power off" the unit by pressing the Radio's
Power button. So far so good.

Next morning/later in the day I'd do the same again: press preset #1.
Playback would start as expected.

BUT: the display's status would not update until the first title change.
It would stick with what was played last in the previous session until
there's some new information _while_ playing.

I've done the same with a pCP based player for years. And I'm using a
similar setup in another place (pCP with display controlling the
Transporter). But I've never seen this behaviour before. Unfortunately I
haven't found the time yet to really investigate this. Therefore my wild
guess: could there be some slimproto missing telling LMS about the
player's state?

Because there's one other oddity I'd like to blame slimproto for: after
unplugging the SqueezeAMP and leaving it powered off (because I f... it
up somehow and need to re-flash it using serial...) it would not
disappear from LMS. Other players disappear after a few minutes.
SqueezeAMP just stays there in the player list.

--

Michael

I will try to reproduce that but from the point of view of slimproto, squeezelite-esp32 (so squeezeamp) is the main version. The changes I’ve made are around either codecs (and most of them are now in squeezelite official) or around some internal ipc tricks which should not impact at all the way slimproto answers. I will recheck to see if there a chance that the first slimproto play confirmation messages is missing, but that would be surprising. The stocky player is even more surprising ... basically if the device is off, LMS (as you know :-)) has timer for when it does not receive a keep alive message, so that should have nothing to do with squeezeamp which does not send a message because it’s dead ... unless you have a ghost somewhere

[mherger]

Could there be some kind of timing issue in when the stream's headers
are being parsed in direct play mode? Unfortunately I'm away from the
unit right now, but I should have tested direct vs. proxied streaming.

In direct streaming mode the player would parse the headers, potentially
returning metadata to LMS. I was wondering whether it's that main issue
here. It then would mostly happen with online radio streams, not with
music services or local music. But as that's what I've stored in my
presets I didn't even think about this possibility before.

(and then I always tested it with the one stream I have a custom
metadata provider for - might further narrow down the issue...)

FWIW: the issue is also visible in the web UI, not limited to
controlling the unit using a Radio or other.

--

Michael

[philippe_44]

Could there be some kind of timing issue in when the stream's headers
are being parsed in direct play mode? Unfortunately I'm away from the
unit right now, but I should have tested direct vs. proxied streaming.

In direct streaming mode the player would parse the headers, potentially
returning metadata to LMS. I was wondering whether it's that main issue
here. It then would mostly happen with online radio streams, not with
music services or local music. But as that's what I've stored in my
presets I didn't even think about this possibility before.

(and then I always tested it with the one stream I have a custom
metadata provider for - might further narrow down the issue...)

FWIW: the issue is also visible in the web UI, not limited to
controlling the unit using a Radio or other.

--

Michael

Do you have a different settings in LMS for what to do when powering off and resuming that player? I think I remember now that there are various options there.

[mherger]

> Do you have a different settings in LMS for what to do when powering off
> and resuming that player? I think I remember now that there are various
> options there.

I compared with the pCP based unit, and they both use what I think is
the default settings.

I'm really starting to think it might be an issue with my metadata
plugin. I only see the issue when playing that station. But it's just
not hurting enough right now to give it the necessary priority...

--

Michael

[sle118]

> Do you have a different settings in LMS for what to do when powering off
> and resuming that player? I think I remember now that there are various
> options there.

I compared with the pCP based unit, and they both use what I think is
the default settings.

I'm really starting to think it might be an issue with my metadata
plugin. I only see the issue when playing that station. But it's just
not hurting enough right now to give it the necessary priority...

--

Michael

Michael,

Have you tried one of the more recent versions from my repo, and is this will an issue?

[mherger]

> Have you tried one of the more recent versions from my repo, and is this
> will an issue?

I'm sorry to say no, I haven't. I switched to the master branch a few
weeks ago. And ever since there have only been updates to the nvs
branch... It's my understanding that I'd have to use the serial cable
and terminal to switch again. Am I right? (I simply haven't found the
time to even touch the keyboard over the weekend...)

--

Michael

[sle118]

> Have you tried one of the more recent versions from my repo, and is this
> will an issue?

I'm sorry to say no, I haven't. I switched to the master branch a few
weeks ago. And ever since there have only been updates to the nvs
branch... It's my understanding that I'd have to use the serial cable
and terminal to switch again. Am I right? (I simply haven't found the
time to even touch the keyboard over the weekend...)

--

Michael

Michael,

We're getting close to an initial release, so I think it would be safe to get your TTL adapter out and program the latest release from my master branch to see if the problem persists.

Thank you!

[mherger]

> We're getting close to an initial release, so I think it would be safe
> to get your TTL adapter out and program the latest release from my
> master branch to see if the problem persists.

Thanks! I'll try to do that today.

--

Michael