After update, `group.get.trackplus` is not parsing URI streams

[jolexa]

Description

I updated node-red-contrib-sonos-plus and not group.get.trackplus fails. It has reliable worked before with no changes done to my automation. I'm abit green with node in general so let me know what else would help with triage!

Here is part of the stack

group.get.trackplus:uri.replace is not a function :: Details: {"stack":"TypeError: uri.replace is not a function\n    at Function.ParseDIDLTrack (/config/node_modules/@svrooij/sonos/lib/helpers/metadata-helper.js:56:29)\n    at AVTransportService.parseValue (/config/node_modules/@svrooij/sonos/lib/services/base-service.js:253:46)\n    at /config/node_modules/@svrooij/sonos/lib/services/base-service.js:246:30\n    at Array.forEach (<anonymous>)\n    at AVTransportService.parseEmbeddedXml (/config/node_modules/@svrooij/sonos/lib/services/base-service.js:245:14)\n    at AVTransportService.handleRequestAndParseResponse (/config/node_modules/@svrooij/sonos/lib/services/base-service.js:205:21)\n    at processTicksAndRejections (node:internal/process/task_queues:95:5)\n    at AVTransportService.GetMediaInfo (/config/node_modules/@svrooij/sonos/lib/services/av-transport.service.js:127:60)\n    at Object.groupGetTrackPlus [as group.get.trackplus] (/config/node_modules/node-red-contrib-sonos-plu...

What node/command (topic)/state (payload)

node: Universal command: group.get.trackplus state:

In case of a bug: Are you able to reproduce the error

In my case, it fails only when I'm playing a direct uri and not a station (which I normally do).

Versions and Infrastructure

what system: Linux 6.6.16-haos x86_64 node-red-contrib-sonos-plus version: 6.7.6 Node-RED version: 3.1.7 NodeJS version: v18.19.1

[hklages]

Hi. What track did you play: name? From what source: Youtube, Spotify, Radioplayer?

On Mon, Mar 25, 2024 at 8:25 PM Jeremy Olexa @.***> wrote:

Description

I updated node-red-contrib-sonos-plus and not group.get.trackplus fails. It has reliable worked before with no changes done to my automation. I'm abit green with node in general so let me know what else would help with triage!

Here is part of the stack

group.get.trackplus:uri.replace is not a function :: Details: {"stack":"TypeError: uri.replace is not a function\n at Function.ParseDIDLTrack @./sonos/lib/helpers/metadata-helper.js:56:29)\n at AVTransportService.parseValue @./sonos/lib/services/base-service.js:253:46)\n at @./sonos/lib/services/base-service.js:246:30\n at Array.forEach ()\n at AVTransportService.parseEmbeddedXml @./sonos/lib/services/base-service.js:245:14)\n at AVTransportService.handleRequestAndParseResponse @./sonos/lib/services/base-service.js:205:21)\n at processTicksAndRejections (node:internal/process/task_queues:95:5)\n at AVTransportService.GetMediaInfo @./sonos/lib/services/av-transport.service.js:127:60)\n at Object.groupGetTrackPlus [as group.get.trackplus] (/config/node_modules/node-red-contrib-sonos-plu...

What node/command (topic)/state (payload)

node: Universal command: group.get.trackplus state: In case of a bug: Are you able to reproduce the error

In my case, it fails only when I'm playing a direct uri and not a station (which I normally do). Versions and Infrastructure

what system: Linux 6.6.16-haos x86_64 node-red-contrib-sonos-plus version: 6.7.6 Node-RED version: 3.1.7 NodeJS version: v18.19.1

— Reply to this email directly, view it on GitHub https://github.com/hklages/node-red-contrib-sonos-plus/issues/285, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEDZCH2T2H2I3U4U62JTNYLY2B2ZHAVCNFSM6AAAAABFHTCZHCVHI2DSMVQWIX3LMV43ASLTON2WKOZSGIYDMNJSGEYDSNQ . You are receiving this because you were assigned.Message ID: @.***>

[jolexa]

Currently I'm playing this stream https://kexp.streamguys1.com/kexp160.aac (https://kexp.org)

via group.play.streamhttp command and then in a seperate automation I issue the group.get.trackplus command and then it fails with the error above

[hklages]

... same error at my test installation.

But that is only this stream - you others streams work fine. Does the command work for "http://www.fritz.de/live.m3u"?

On Mon, Mar 25, 2024 at 9:12 PM Jeremy Olexa @.***> wrote:

Currently I'm playing this stream https://kexp.streamguys1.com/kexp160.aac (https://kexp.org)

via group.play.streamhttp command and then in a seperate automation I issue the group.get.trackplus command and then it fails with the error above

— Reply to this email directly, view it on GitHub https://github.com/hklages/node-red-contrib-sonos-plus/issues/285#issuecomment-2018826877, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEDZCH4D2KEA5LVIVRZAWQLY2CAJRAVCNFSM6AAAAABFHTCZHCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJYHAZDMOBXG4 . You are receiving this because you were assigned.Message ID: @.***>

[jolexa]

I have the same error for the fritz stream with group.get.trackplus

[hklages]

Hi. I have to report the bug to the ts-sonos - a library I use for this project.

Workaround: In the Android/iPhone app go to serach tab search for KEXP in category station select KEXP, use the 3 dot menu, more and add it to My Sonos

You can then use "group.play.mysonos" with "KEXP" and start the station. Then "group.get.trackplus" should work. I tested it on my system and it works.

Does it work for your?

[jolexa]

Yes, that workaround will work.

Do you know how to downgrade packages in the node red palette? I’d like to find when this broke.

Thanks for filing upstream, please link here so I can follow it. I appreciate your help.

[hklages]

Thanks for your feedback.

bug report to ts-sonos

downgrade: It was often request but still it isn't implemented in Node-RED.

To downgrade you need to use the console, go to the node-red home directory and use npm commands. Description to downgrade

[jolexa]

Well, I'm still not sure..

I downgraded all the way to this version:

addon-node-red@ /opt
└─┬ node-red-contrib-sonos-plus@6.0.0
  └── @svrooij/sonos@2.5.0-beta.5

and I still have the error... 😕 Maybe the stream changed at the worse time? However, I see a similar Github issue was raised after mine, hmm. Maybe I'm testing the downgrade wrong?

[hklages]

I prefer the "My Sonos" usage. Then SONOS stores the data and ensures that everything is ok. I can export/import these data. In case of "group.play.streamhttp" the package "ts-sonos" or I have to "suggest" the metadata and that can easily go wrong.

Most likely you did the downgrade right (at least the snippet looks fine).

Can you provide another stream or album where the error occurs?

On Tue, Mar 26, 2024 at 4:05 PM Jeremy Olexa @.***> wrote:

Well, I'm still not sure..

I downgraded all the way to this version:

addon-node-red@ /opt └─┬ @. └── @@.

and I still have the error... 😕 Maybe the stream changed at the worse time? However, I see a similar Github issue was raised after mine, hmm. Maybe I'm testing the downgrade wrong?

— Reply to this email directly, view it on GitHub https://github.com/hklages/node-red-contrib-sonos-plus/issues/285#issuecomment-2020683409, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEDZCHYVBXLUW2H4ELJQFT3Y2GFEJAVCNFSM6AAAAABFHTCZHCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRQGY4DGNBQHE . You are receiving this because you were assigned.Message ID: @.***>

[jolexa]

I understand the workaround. I submitted this issue in case it helps to make this project more robust. 😄 I previously used TuneIn in Sonos App and that still works just fine with group.get.trackplus. In the past, TuneIn was degraded for a few hours and I decided to switch to using direct streams (when possible) instead. Afterall, Tunein (or Sonos Radio) just uses a stream anyway, so I decided to cut out the middleman and make my home more robust. If the stream is down, then tunein or sonos will be down as well and I can switch to Spotify or something. I'm not sure, but I also think the stream is better quality then other options.

I don't have other examples right now. I'm following ts-sonos issue and it looks promising (null object) but I can't confirm.

[jolexa]

For the record, I found another stream is also having this error https://nis.stream.publicradio.org/nis.mp3

So, IMO, that rules out that a stream changed and points to an issue in some package. I’ve had these automations for 6+months without changes.

[hklages]

in release 6.7.7 both streams work (you have to submit once the group.play.streamhttp) and after having done that the group.get.trackall does not throw any error.

Does it work in your environment?

[jolexa]

Ok, updated and confirmed the fix.

Here is the group.get.trackplus debug output in case it helps anything. (from the publicradio stream link, just now)

{
  "artist": "MPR News",
  "album": "",
  "title": "Angela Davis",
  "artUri": "",
  "mediaData": {
    "NrTracks": 1,
    "MediaDuration": "NOT_IMPLEMENTED",
    "CurrentURI": "x-rincon-mp3radio://https://nis.stream.publicradio.org/nis.mp3",
    "CurrentURIMetaData": {
      "Title": "0",
      "ItemId": -1
    },
    "NextURI": {},
    "NextURIMetaData": {},
    "PlayMedium": "NETWORK",
    "RecordMedium": "NOT_IMPLEMENTED",
    "WriteStatus": "NOT_IMPLEMENTED"
  },
  "queueActivated": false,
  "serviceId": "",
  "serviceName": "",
  "stationArtUri": "",
  "positionData": {
    "Track": 1,
    "TrackDuration": "0:00:00",
    "TrackMetaData": {
      "Artist": "MPR News",
      "Title": "Angela Davis",
      "UpnpClass": "object.item",
      "ItemId": -1,
      "ParentId": -1,
      "TrackUri": "x-rincon-mp3radio://https://nis.stream.publicradio.org/nis.mp3",
      "ProtocolInfo": "x-rincon-mp3radio:*:*:*"
    },
    "TrackURI": "x-rincon-mp3radio://https://nis.stream.publicradio.org/nis.mp3",
    "RelTime": "0:00:03",
    "AbsTime": "NOT_IMPLEMENTED",
    "RelCount": 2147483647,
    "AbsCount": 2147483647
  }
}

[hklages]

Thanks for reporting the bug and for final feedback.