Threaded Mode | Linear Mode

Carefant · 31-03-2020, 21:34

(31-03-2020 09:52)simoncn Wrote: I have an idea about what might be causing this. To confirm, I would need to see a debug log. Please do the following:

1) Browse to the playlist containing the BBC stations
2) From the MinimWatch minim icon, select 'Show log'
3) In the log window, change the logging level to Debug
4) Leave the log window open
5) Play one of the BBC stations until it stops. Do not restart it.
6) In the log window, click 'Save as' and save the log to a file
7) Zip the log file and attach the zipped file to a post here as a file attachment
8) Set the logging level back its default setting of Info

Hi Simon. See zipped debug log attached. Just to note, I didn't restart the station, but it did restart itself, so there might be two sets of data here. I'm sure you'll know what you are looking at. Thanks. Steve

simoncn · (This post was last modified: 31-03-2020 22:21 by simoncn.)

Thanks for this log. It confirms what I was suspecting. Your renderer (which identifies iself as LUMIN??) starts by making a normal streaming request and reads a small amount of audio data. It then closes the connection and makes a byte-range request to MinimServer (start streaming from byte offset 917504). This is valid for a disk file where the byte offsets are always the same but is not valid for a radio stream where the byte offsets are changing all the time.

MinimServer cannot handle this and sends an error response to the renderer. The renderer keeps trying and eventually gives up. The two seconds of audio that you heard is what the renderer received before it sent its first byte-range request.

The only solution is for the renderer not to send byte-range requests. You could try transcoding the stream into other formats such as L16 or WAV to see if that makes any difference.

Carefant · 01-04-2020, 12:39

(31-03-2020 22:20)simoncn Wrote: Thanks for this log. It confirms what I was suspecting. Your renderer (which identifies iself as LUMIN??) starts by making a normal streaming request and reads a small amount of audio data. It then closes the connection and makes a byte-range request to MinimServer (start streaming from byte offset 917504). This is valid for a disk file where the byte offsets are always the same but is not valid for a radio stream where the byte offsets are changing all the time.

MinimServer cannot handle this and sends an error response to the renderer. The renderer keeps trying and eventually gives up. The two seconds of audio that you heard is what the renderer received before it sent its first byte-range request.

The only solution is for the renderer not to send byte-range requests. You could try transcoding the stream into other formats such as L16 or WAV to see if that makes any difference.

Okay thanks Simon. Yes LUMIN is the system on my iPad that I use to control the streaming and NAS playback. Funnily enough I was looking at the transcoding instructions the other night and was struggling to even know where to start. Could you give me some tips on getting that done, or point me to a thread where you have already provided that advice? Thanks.

simoncn · 01-04-2020, 13:09

I would not expect the LUMIN app on the iPad to be requesting the audio stream from the server. It would be worth double-checking this. The streaming request was received from the device with IP address 192.168.1.228. Is this the iPad or the TEAC?

For transcoding, you need to have MinimStreamer installed. The instructions for configuring transcoding are on this page. In the stream.transcode property, you should enter either aac:L16 or aac:wav and then restart MinimServer and reload the MinimServer library into the LUMIN app.

Carefant · 02-04-2020, 00:19

(01-04-2020 13:09)simoncn Wrote: I would not expect the LUMIN app on the iPad to be requesting the audio stream from the server. It would be worth double-checking this. The streaming request was received from the device with IP address 192.168.1.228. Is this the iPad or the TEAC?

For transcoding, you need to have MinimStreamer installed. The instructions for configuring transcoding are on this page. In the stream.transcode property, you should enter either aac:L16 or aac:wav and then restart MinimServer and reload the MinimServer library into the LUMIN app.

Hi Simon. Thank you for this. I've tried various combinations of transcoding and got silence every time. Reverting back to leaving the transcode property blank gave me the 2 seconds of radio play as before. I have attached a new debug log, taken when trying aac:wav. I would be very grateful for further suggestions.
Thanks

Carefant · 02-04-2020, 00:29

(02-04-2020 00:19)Carefant Wrote:
(01-04-2020 13:09)simoncn Wrote: I would not expect the LUMIN app on the iPad to be requesting the audio stream from the server. It would be worth double-checking this. The streaming request was received from the device with IP address 192.168.1.228. Is this the iPad or the TEAC?

For transcoding, you need to have MinimStreamer installed. The instructions for configuring transcoding are on this page. In the stream.transcode property, you should enter either aac:L16 or aac:wav and then restart MinimServer and reload the MinimServer library into the LUMIN app.

Hi Simon. Thank you for this. I've tried various combinations of transcoding and got silence every time. Reverting back to leaving the transcode property blank gave me the 2 seconds of radio play as before. I have attached a new debug log, taken when trying aac:wav. I would be very grateful for further suggestions.
Thanks

Log att

simoncn · 02-04-2020, 21:20

Thanks for this log. It does not include any byte-range requests. Instead, the device at 192.168.1.228 reads a small amount of WAV data before closing the connection. Please confirm whether this device is the iPad running the LUMIN app or the TEAC streamer.

Carefant · 02-04-2020, 22:26

(02-04-2020 21:20)simoncn Wrote: Thanks for this log. It does not include any byte-range requests. Instead, the device at 192.168.1.228 reads a small amount of WAV data before closing the connection. Please confirm whether this device is the iPad running the LUMIN app or the TEAC streamer.

Hi. iPad IP address is 192.168.1.186, so I guess it must be the Teac, though I don’t know where to look to confirm that. 192.168.1.229 is the NAS. Thanks.

simoncn · 02-04-2020, 22:57

Thanks for confirming this. It is what I would have expected, apart from the streamer identifying itself as LUMIN

I don't think there is much more that I can do to help with this. For some reason, the TEAC seems to be unable to play UPnP streams (in any format) that don't have a defined length. Ths is unusual as most UPnP streamers can do this.

Carefant · 04-04-2020, 09:56

(02-04-2020 22:57)simoncn Wrote: Thanks for confirming this. It is what I would have expected, apart from the streamer identifying itself as LUMIN

I don't think there is much more that I can do to help with this. For some reason, the TEAC seems to be unable to play UPnP streams (in any format) that don't have a defined length. Ths is unusual as most UPnP streamers can do this.

Hi Simon. Thanks for your help with this. Seems like it can’t be resolved with my current set up. I have a few more radical options:

1) I could add a second, cheap and cheerful, streamer to my existing set up and control it separately. For example, I have SONOS in other rooms and could re-purpose that. This would not require MinimStreamer because BBC stations are still available via Tune-In on this platform in UK (for now).

2) I could swap my Teac NT-505 streamer for one that is known to work with MinimStreamer. I like the Teac/LUMIN controller combo very much, so could only contemplate this if I also achieved some worthwhile improvements in sound quality. For example, the Teac decodes Tidal MQA, which many ‘high end’ streamers seem not to. MQA versions of same tracks in CD quality sound clearly better to me, so I can’t lose that.

Do you or other Forum members have any suggestions for either of the above, or another idea that means I can get radio streams on my hifi?

Many thanks