Ropieee display periodically requires extension restart since 1.4

Audio Gear Talk RoPieee
1

Hey Harry @spockfish , ever since 1.4 I have had several displays not “wake up” occasionally when starting music. A restart of the extension always fixes the problem (reboot not required).

Feedback from latest: db4dd87917475441

Do you know what is going on?

Happy holidays.

2

Hi @Nathan_Wilkes,

I’ll look into this. Haven’t noticed it myself, so I’ll keep an eye.

Happy holidays!

3

Thanks Harry.

Another example: b313b5016a37e757

4

Different end point: e820f79d418bc71d

5

@spockfish , any ideas on what is going on here? Would there be any harm in setting up a cron job to restart the extension periodically? The problem occurs most evenings (when I am home to notice).

NB, this is only a problem of the display RoPieee adjusting to music now being played by the zone the display is monitoring. The music endpoints (also running RoPieee) don’t exhibit any strange behaviour.

I appreciate the help.

6

Example from a few minutes ago: eaee92e743c12f07

7

So what exactly happens? The logs seem fairly normal, except that I see a Roon core that’s gone (but comes back).

So by ‘wake up’ you mean:

  • the screen is in screensaver mode (the clock)
  • when you start playing music on the configured zone nothing happens
  • when you restart the extension in Roon the display starts showing the right information

That’s about it?

8

Harry, yes that is it. Display is either clock or dark, and when the related zone starts playing the display does not fire up. A restart of the extension always works.

Obviously it goes without saying that the display and the other RoPieee endpoint connected to the DAC are connected the same way infrastructure-wise, eg same switch.

I appreciate your help.

9

Just to be sure, because I see you’ve got quite a few zones: is this is simple single zone? or a grouped one?

10

Happens both ways. The latest log was a single zone.

Last night, we were playing music in a grouped zone (kitchen and livingroom). Since we were sitting in the kitchen, I restarted that display. Some time later (after dinner and discussion), we relocated to the living room, and I had to restart that display. Music continued to play unabated.

The zones are named somewhat consistently:

KitchenPi
KitchenDisplay

LivingRoomPi
LivingRoomDisplay

And so on.

11

Ok. And by ‘restart that display’ you mean: restart the extension right?

12

Harry, yes, restart the extension.

Sorry about my imprecise use of language. (Says the sheepish Canadian to the Netherlander.)

13

Whoohahaaa! Don’t worry :wink:

Can it be that this happens everytime you switch to a different display?

So you start in the kitchen, but when you continue in the living room you need to restart it?

14

I don’t think so. It happens with a single zone, like this morning (last feedback given).

For clarity, regarding last night:

  1. Start music in grouped zone.
  2. Music starts playing in both.
  3. Kitchen display blank, so restarted extension.
  4. Music plays for a few hours.
  5. People relocate to Living Room.
  6. Music is still playing.
  7. Living Room display is blank, so extension is restarted.
  8. Music continues to play for the evening. Displays stay “connected” for duration.

At no time does the display lose a connection while music is playing, irrespective of duration. The display must be in “sleep” mode (clock or dark, depending on setting) for it to fail to “wake up”.

**

I just ran a test, grouping 3 zones. My son’s display woke up fine, connected to the same switch as the core. The other didn’t, which is connected to a different switch (the kitchen and living room displays). BTW, these are all ethernet.

So, this leads me to suspect some issue with this network segment. It is interesting that it is the display which fails, not the playing of music, and the failure is related to noticing that the watched zone has started. Also, interesting that the extension restart never fails (eg its mechanism is more fault tolerant somehow).

15

Hmmm…

Thanks for the very elaborate information.

This might indeed be a networking issue. Audio (these days) uses TCP (and thus survives routing), but the extension framework I’m not sure about (I need to investigate)…

That still does not explain why after a restart things start working again.

16

Update

I decided to write a simple bash script that restarts the extensions of the displays every 4 hours during the normal listening day. I am pleased that this seems to have masked whatever the problem was that was occurring.

Thanks.