Car gateway

[simoncn]

(07-01-2016 17:50)Michel Lopez Wrote:  I restarted my testing with a basic configuration, storing 2 mp3 files and this updated playlist directly to the root folder of the shared folder. Then I manually forced a re-scan, and shut down the device, before moving to the garage to restart everything, in the car environment.

This time all the entries are properly detected and displayed. Since the car player does auto start playing, it always start playing one of the music file as soon the UPnP server is properly detected & enabled. I then have been able to navigate to the other entries and of course tried to get to the radio stream. The radio does not work and the entry become grayed out, and not available. Of course when the radio stream has failed, the player automatically goes back to playing music.

Just in case I also retried after setting some value to delayHLS, but with no change. Both trace files are attached.

Thanks.

-Michel

This trace log is very helpful. Some interesting points from the first log:

1) The first request to play the radio stream is at 07:08:09. Contacting the remote stream takes 12 seconds (a very long time).

2) The second request to play the radio stream is at 07:09:07. Contacting the remote stream takes 36 seconds (an extremely long time).

3) The third request to play the radio stream is at 07:09:43.133, while the second request is still being processed and before MinimServer has sent a response to the second request.

4) The renderer cancels the third request at 07:09:43.773. The trace log shows that a timing bug in MinimStreamer caused the output stream for the second request to be corrupted when the third request was cancelled. I don't think it is safe to draw any conclusions from what happens after this corruption has occurred. This bug willl be fixed in the next release of MinimStreamer.

5) While 1) to 4) above are happening, there is continuous activity related to streaming the file "Axel Bauer - Cargo.mp3"

The second log is simpler. There is only one request for the radio stream and it takes 8 seconds to contact the remote stream. The radio stream data is streamed successfully for about 1 second before the renderer closes the connection. There is no corruption of the radio stream and it isn't clear why the renderer closed the connection. The delayHLS change that you made for this test run doesn't have any effect on the non-HLS radio station that you are using for testing.

I don't think it is useful to transcode AAC to MP3. The log for this shows some AAC errors from avconv and these might be related to the subsequent problems. I don't see any problems in this log related to the timeout=2000 setting. I would like to focus on the simplest case of getting an MP3 radio stream to play without any transcoding.

I have installed Audi MMI Connect on my Android tablet. The MMI Connect UPnP server seems to stay active for only about a minute after I launch MMI Connect for the first time. By capturing some debug information during this short window, I see that the following DIDL-Lite metadata values for radio streams in MMI Connect are different from what MinimStreamer is producing:

size="500000000" duration="05:00:00.000" bitrate="the-stream-bitrate"

MinimServer/MinimStreamer doesn't have any way to get the bitrate and I don't think this value is important for playing the stream.

It would be possible for MinimServer/MinimStreamer to send the above values for size and duration. These values might be important for playing the radio stream. I will produce a test build that does this and send you a PM with instructions on how to install it.