Announce : BBC Sounds Plugin

[ken_s]

Hi

Great plugin, but having some issues listening to on demand.
The track info get rushed through , so if the show last an hour the last song is displayed after about 15 minutes.

Viewing the tracklist, I can see it starts some minutes in, eg 00:03:30. I guess that's the news (which isn't heard).
I don't now if that makes a difference.

Listening outside of UK.

regards

ken

[expectingtofly]

Hi

Great plugin, but having some issues listening to on demand.
The track info get rushed through , so if the show last an hour the last song is displayed after about 15 minutes.

Viewing the tracklist, I can see it starts some minutes in, eg 00:03:30. I guess that's the news (which isn't heard).
I don't now if that makes a difference.

Listening outside of UK.

regards

ken

A few things to consider here :

• For Audio On Demand, for some programmes, they first release it with the news at the start, then repackage without the news later. They sometimes include the news in the times, the sometimes don't, but I have noticed they never change the tracklist when they do the repackaging
• The plugin uses the same tracklist that you see in the menus, so if that is wrong, it will be wrong when displaying the track on the player when the item is playing
• The BBC themselves don't use the tracklist in the way the plugin is using it in their own apps, they just display a list for Audio on demand, not replay it out with the audio. So they have no incentive to get the times accurate, only the order accurate.
• The plugin might be out by a few seconds or so, as it tries to display it on the controller in synch with what's playing out of the players buffer, but it might not be spot on.

So, in short, as long as the plugin is displaying the track more or less as is you see in the tracklist, that's the best I can do (If it's not, please provide an example). It's not really the BBC's fault either, as it the tracklist information is being used in a way they don't intend (sometimes they don't even include the times, just a list)

[DecTenToo]

Intermittent skip in BBC sounds programs

I'm listening back to 2 programmes on BBC R4 (Counterpoint and Just a Minute) anf am getting intermittent skips

Internet speeds and pings are normal for me, and I'm not seeing any issues otherwise. I'm not hearing any skips if I listen on BBC sounds via the web.

I also have a Pi4 running PiCore 7 and am getting the same issue.

Logitech Media Server Version: 8.1.1 - 1610364019 on Synology Nas
Player Model: Squeezebox Radio on Firmware: 8.0.1-r16835
BBC sounds Release 2.14.0
Listening outside the UK

bbcsounds.txtbbcsounds.txt

Log file attached if it is any help.

Any suggestions?

[expectingtofly]

I'm listening back to 2 programmes on BBC R4 (Counterpoint and Just a Minute) anf am getting intermittent skips

Internet speeds and pings are normal for me, and I'm not seeing any issues otherwise. I'm not hearing any skips if I listen on BBC sounds via the web.

Player Model: Squeezebox Radio on Firmware: 8.0.1-r16835
?

I find the The community firmware AAC decoder has some issues with high bitrate AAC streams. It is being worked on.
Try disabling native AAC in Settings->Advanced->File types so that it gets transcoded to flac. That fixes it for me.

[DecTenToo]

Try disabling native AAC in Settings->Advanced->File types so that it gets transcoded to flac. That fixes it for me.

Oh yes, spot on

Thank you very much.

[slartibartfast]

I find the The community firmware AAC decoder has some issues with high bitrate AAC streams. It is being worked on.
Try disabling native AAC in Settings->Advanced->File types so that it gets transcoded to flac. That fixes it for me.

I think the only time I have noticed playback issues in the UK was when I skipped back half an hour in a live programme and immediately afterwards the sound stuttered for a few seconds before settling down.

Sent from my Pixel 3a using Tapatalk

[expectingtofly]

I think the only time I have noticed playback issues in the UK was when I skipped back half an hour in a live programme and immediately afterwards the sound stuttered for a few seconds before settling down.

Sent from my Pixel 3a using Tapatalk

The issue pertains to getting enough data into the output buffer : https://forums.slimdevices.com/showt...=1#post1011552
So, the network conditions of your set up probably mean that most of the time you don't tip over the edge into an underrun.

[ken_s]

A few things to consider here :

• For Audio On Demand, for some programmes, they first release it with the news at the start, then repackage without the news later. They sometimes include the news in the times, the sometimes don't, but I have noticed they never change the tracklist when they do the repackaging
• The plugin uses the same tracklist that you see in the menus, so if that is wrong, it will be wrong when displaying the track on the player when the item is playing
• The BBC themselves don't use the tracklist in the way the plugin is using it in their own apps, they just display a list for Audio on demand, not replay it out with the audio. So they have no incentive to get the times accurate, only the order accurate.
• The plugin might be out by a few seconds or so, as it tries to display it on the controller in synch with what's playing out of the players buffer, but it might not be spot on.

So, in short, as long as the plugin is displaying the track more or less as is you see in the tracklist, that's the best I can do (If it's not, please provide an example). It's not really the BBC's fault either, as it the tracklist information is being used in a way they don't intend (sometimes they don't even include the times, just a list)

Thanks expectingtofly.

I understand you have to use what bbc provides.
I have removed track title from the display and instead open the tracklist to see the songs (if needed).

regards

ken

[ericj]

Oh yes, spot on

Thank you very much.

Fixed my similar issue. Occurred when skipping past content, say the news on R3 lunchtime concert. Now back to usual, reliable self.

Thanks so much!


Sent from my iPhone using Tapatalk

[simoh]

I know zero about the UPnPBridge plugin, but are there any settings in there to make it work? Look for settings on gapless playback (I think that was mentioned that earlier in the thread). Someone else might be able to help

It might be worth asking on the UPnPBridge thread for help, I suspect if there is a combination of upnp devices that don't work for repeating streams, other people would now how to fix it. BBC Sounds, Pandora and Slacker are examples of plugins that use "RepeatingStreams"

Thanks again expectingtofly,

There's a number of options for 'HTTP mode' 'Gapless' and 'Seek on Resume' to try. I'll post in the UPnP thread if I can't get it working.

[15:57:14.588106] _SyncNotifState:671 LUMIN T2:LUMIN: uPNP playing
[15:57:14.590039] sendSTAT:169 [0x100928400]: STAT:[STMs] msplayed 0
[15:59:50.746122] output_http_thread:289 [0x100928400]: draining (6968995 bytes)
[15:59:50.805287] output_http_thread:241 [0x100928400]: self-exit 
[15:59:50.805634] output_http_thread:372 [0x100928400]: end thread 0 (6968995 bytes)
[16:00:06.129025] _SyncNotifState:643 [0x1009aeab0]: uPNP stop
[16:00:06.129309] slimproto_run:752 [0x100928400]: Track shorter than expected (172000/0)
[16:00:06.129354] sendSTAT:169 [0x100928400]: STAT:[STMu] msplayed 172000
[16:00:06.129429] sendSTAT:169 [0x100928400]: STAT:[STMd] msplayed 172000

[expectingtofly]

Release 2.14.2

Release 2.14.2 contains some changes to help the Community Firmware AAC Decoder on the Squeezebox radios play out glitch free.

For those interested in the technical details, a data throttle has been added that manages the amount data available when a stream starts so that decoding can be prioritised over buffering.
An adjustment to the throttle is available in the settings, so it can be turned off by setting to zero. However, I would recommend leaving at the default setting as the change should be transparent to all other players.

[philippe_44]

BBC Sounds presents live radio as a "RepeatingStream" as LMS calls them. Which has a track per programme. When one track ends it should should automatically call to get the next track, and seamlessly carry on.
It appears that the UPnPBridge or Lumin streamer or the combination of the two is not behaving correctly. I haven't got a way of testing the Upnpbridge, but I have tested on the chromecast bridge, for example, and that behaves correctly.

I know zero about the UPnPBridge plugin, but are there any settings in there to make it work? Look for settings on gapless playback (I think that was mentioned that earlier in the thread). Someone else might be able to help

It might be worth asking on the UPnPBridge thread for help, I suspect if there is a combination of upnp devices that don't work for repeating streams, other people would now how to fix it. BBC Sounds, Pandora and Slacker are examples of plugins that use "RepeatingStreams"

[scratch that: Do you serve the method "isRepeatingStream"? I did not see it in the protocolhandler and this is an important information for the upnpbridge to not miss tracks then (as it is trying to do gapless). Chromecast behaves differently as there is no gapless]

I've tried and the problem is because I'm not getting a duration (it's 0) and so because it's a remote stream (although repeating, I missed it initially), then I cannot decide properly what to do when the stream ends. It's a bit complicated to explain, but to signal LMS that the bridge is ready to receive the next track, I need

- streaming to be finished
- decoding to be finished
- all data to be sent to the UPnP player

In addition, when a track is remote, I need to wait to be "close" to the end (like 15s) before informing LMS that we are ready for track N°1.

That's because some UPnP players have very large buffers, so there can be a large period between receiving last byte of track N and querying track N+1. So if I tell LMS that I'm ready as soon as player has accepted everything, LMS will grab the next track from the streaming service, fill its buffers and... wait till the UPnP player request for that N+1 track. That wait can be so long that services like Deezer think the HTTP connection is stalled and close it.

So, long story short, I need the duration to tell LMS to send me the next track "not too early" ... the joy of bridges

I have a workaround to ignore that 15s mechansim with a repeating stream when duration is 0 but that's really not pretty. It would be much cleaner if you could have the duration *before* you start streaming the next stream item.

[expectingtofly]

I've tried and the problem is because I'm not getting a duration (it's 0) and so because it's a remote stream (although repeating, I missed it initially), then I cannot decide properly what to do when the stream ends. It's a bit complicated to explain, but to signal LMS that the bridge is ready to receive the next track, I need

- streaming to be finished
- decoding to be finished
- all data to be sent to the UPnP player

In addition, when a track is remote, I need to wait to be "close" to the end (like 15s) before informing LMS that we are ready for track N°1.

That's because some UPnP players have very large buffers, so there can be a large period between receiving last byte of track N and querying track N+1. So if I tell LMS that I'm ready as soon as player has accepted everything, LMS will grab the next track from the streaming service, fill its buffers and... wait till the UPnP player request for that N+1 track. That wait can be so long that services like Deezer think the HTTP connection is stalled and close it.

So, long story short, I need the duration to tell LMS to send me the next track "not too early" ... the joy of bridges

I have a workaround to ignore that 15s mechansim with a repeating stream when duration is 0 but that's really not pretty. It would be much cleaner if you could have the duration *before* you start streaming the next stream item.

Many thanks for the explanation.
As this is live radio with each programme as a track, when the stream is started on the first track, its would be very tricky to set the duration before the track started, as it is starting at the current live point, so it does that once the stream is up and going and it has all the information about what point it is in the current live programme. However, it's much easier for the subsequent follow on tracks. Which I think is what you need . I'll make that change and send out a release.

[philippe_44]

Many thanks for the explanation.
As this is live radio with each programme as a track, when the stream is started on the first track, its would be very tricky to set the duration before the track started, as it is starting at the current live point, so it does that once the stream is up and going and it has all the information about what point it is in the current live programme. However, it's much easier for the subsequent follow on tracks. Which I think is what you need . I'll make that change and send out a release.

Unfortunately it might not solve the problem. I played more tracks today and even when duration is known playback might still stop because duration is reported incorrectly (not blaming your plugin, probably something with the BBC site) and tracks happen to be shorter than expected so the bridge is still taken by surprise... I don't have a good solution but I'm tempted to try again to not use that duration-base system that I've always disliked. Maybe Deezer have corrected their problem. I'll do that and see feedback.

[expectingtofly]

Unfortunately it might not solve the problem. I played more tracks today and even when duration is known playback might still stop because duration is reported incorrectly (not blaming your plugin, probably something with the BBC site) and tracks happen to be shorter than expected so the bridge is still taken by surprise... I don't have a good solution but I'm tempted to try again to not use that duration-base system that I've always disliked. Maybe Deezer have corrected their problem. I'll do that and see feedback.

It's only the live radio that uses the repeatingstreams so a track can represent each programme, and its the plugin that is deciding the exact duration for those. (The audio-on-demand tracks aren't provided with an absolutely accurate duration, so for those it does have to adjust once the stream is underway, but those don't use repeatingstreams).
I've had a quick look, and it should be relatively straight forward for me to add the duration at the "getNextTrack" stage, so I'm going to try and set up something to test that on the upnpbridge later. I may as well still have a go at that, I'll let you know how that goes.