Metadata in FLAC streams

[philippe_44]

Surely if you just “tune in” to http://stream.radioparadise.com/flacm as opposed to using the plugin then the metadata must be in the stream?

I will recheck but I had a quick look and I think there is a polling timer to query the RP API in //

[d6jg]

I have two "identical" pcp 4b/4g server players.

One updated the metadata, one didn't.

After a happy Sunday morning trying to get them to behave in the same manner, and co-incidentally wondering how Radio Paradise does it, I noticed (this morning) that RP appeared to be using flac/flac decoding whereas native ogg/flac was enabled on one of my server players. I disabled native ogg/flac (forced flac/flac) on the failing server/player and this resolved the metadata updating issue for me.

Looking forward to hearing your station when it goes "live".

YMMV.

I'm back from my few days away now.
Confirmed that disabling OGG-FLAC on a pCP Player/Server allows metadata updates to work correctly.
This change is NOT necessary where the pCP is a Player only !!!
Yet to try the change on a server where I have an SB Touch available.

[philippe_44]

I'm back from my few days away now.
Confirmed that disabling OGG-FLAC on a pCP Player/Server allows metadata updates to work correctly.
This change is NOT necessary where the pCP is a Player only !!!
Yet to try the change on a server where I have an SB Touch available.

Can we still try your web station?

[d6jg]

Can we still try your web station?

Yes. There are now mp3, AAC & Flac options to try at https://jukeradio.double6.net/ - hopefully I will have the cover art etc on the website tomorrow

[d6jg]

Now confirmed that disabling OGG-FLAC also fixes update on SB Touch

[philippe_44]

Now confirmed that disabling OGG-FLAC also fixes update on SB Touch

So I had a better look, started to get some logs and review code but your servers probably thought I was getting to close and decided to fight back and stopped streaming

But so far, what I found is that the icy metadata is here even when using oggflac (and it is sent in full at every metaint which is not necessary, it can be sent only when changed or just from time to time, otherwise 1 single byte needs to be inserted). But, when LMS detects that metadata is present in the stream, it request a change with a delayed callback (look for setDelayedCallback and getStreamDelay) that should only happen once some of the player's internal buffers are emptied (it's a bit weird as there is hardcoded sample rate to measure time instead of using tracks' sample rate ...).

So I'm not sure, but I suspect something is happening here and the difference with just flac is that bitrate and other items used for evaluating the delay are not set the same way with oggflac vs flac. The callback might in fact never be called - eg, I don't know what EV::Timer does with a timer set to '0', maybe the EVent is just discarded

[edit]: as the server is still replying "a bit" (not streaming any data), I think I was able to get a better information. In fact, I suspect the bitrate indicated in the HTTP headers is wrong and is set to a ridiculously low ~1Kbps. So the "delayed timer" is in fact called but the delay (I've logged that) is a ridiculous 2700s or more ... so it never happens.

Set the loglevel database.info to info and scan.scanner at debug to track all that, but I would not be surprised if you find our this is the issue

[pkfox]

So I had a better look, started to get some logs and review code but your servers probably thought I was getting to close and decided to fight back and stopped streaming

But so far, what I found is that the icy metadata is here even when using oggflac (and it is sent in full at every metaint which is not necessary, it can be sent only when changed or just from time to time, otherwise 1 single byte needs to be inserted). But, when LMS detects that metadata is present in the stream, it request a change with a delayed callback (look for setDelayedCallback and getStreamDelay) that should only happen once some of the player's internal buffers are emptied (it's a bit weird as there is hardcoded sample rate to measure time instead of using tracks' sample rate ...).

So I'm not sure, but I suspect something is happening here and the difference with just flac is that bitrate and other items used for evaluating the delay are not set the same way with oggflac vs flac. The callback might in fact never be called - eg, I don't know what EV::Timer does with a timer set to '0', maybe the EVent is just discarded

[edit]: as the server is still replying "a bit" (not streaming any data), I think I was able to get a better information. In fact, I suspect the bitrate indicated in the HTTP headers is wrong and is set to a ridiculously low ~1Kbps. So the "delayed timer" is in fact called but the delay (I've logged that) is a ridiculous 2700s or more ... so it never happens.

Set the loglevel database.info to info and scan.scanner at debug to track all that, but I would not be surprised if you find our this is the issue

Wow good work Phillippe

[d6jg]

So I had a better look, started to get some logs and review code but your servers probably thought I was getting to close and decided to fight back and stopped streaming

But so far, what I found is that the icy metadata is here even when using oggflac (and it is sent in full at every metaint which is not necessary, it can be sent only when changed or just from time to time, otherwise 1 single byte needs to be inserted). But, when LMS detects that metadata is present in the stream, it request a change with a delayed callback (look for setDelayedCallback and getStreamDelay) that should only happen once some of the player's internal buffers are emptied (it's a bit weird as there is hardcoded sample rate to measure time instead of using tracks' sample rate ...).

So I'm not sure, but I suspect something is happening here and the difference with just flac is that bitrate and other items used for evaluating the delay are not set the same way with oggflac vs flac. The callback might in fact never be called - eg, I don't know what EV::Timer does with a timer set to '0', maybe the EVent is just discarded

[edit]: as the server is still replying "a bit" (not streaming any data), I think I was able to get a better information. In fact, I suspect the bitrate indicated in the HTTP headers is wrong and is set to a ridiculously low ~1Kbps. So the "delayed timer" is in fact called but the delay (I've logged that) is a ridiculous 2700s or more ... so it never happens.

Set the loglevel database.info to info and scan.scanner at debug to track all that, but I would not be surprised if you find our this is the issue

Many thanks Philippe.
The 1kbps in the http header is coming from the server software - I'm not setting it anywhere - so I shall report it to the devlopers.

[philippe_44]

Many thanks Philippe.
The 1kbps in the http header is coming from the server software - I'm not setting it anywhere - so I shall report it to the devlopers.

Have you been able to trace that the timer is set but to very long valued? And there is also a bug in LMS because the bitrate should be adjusted a bit later

[d6jg]

Have you been able to trace that the timer is set but to very long valued? And there is also a bug in LMS because the bitrate should be adjusted a bit later

The server developer has responded with an update that should have fixed the reported bitrate. He says the apparently excessive icy-metaint is to support 24bit and 96kHz streams.