Main Site Documentation

Stream.Read() hangs after a while



I am working on a internet radio that use the common mp3 http streams. My platform is a FEZ Hydra with ENC28.
Software versions:

.NET MF version: .NET MF 4.3 RTM (QFE1)
Gadgeteer Pack: NETMF and Gadgeteer Package 2014 R3 (2014 R3, September 2014, NETMF 4.3 SDK)
FEZ Hydra FW:
FEZ Hydra Loader:
Visual Studio 2012

When I open an http stream for playing radio, everything works fine but after a few minutes the Stream.Read() method blocks and does not give me bytes any more.

 this.webRequest = (HttpWebRequest)WebRequest.Create(url);
            this.webRequest.Method = "GET";
            //this.webRequest.UserAgent = "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0";
            this.webRequest.ProtocolVersion = HttpVersion.Version11;
            this.webRequest.KeepAlive = true;    // Very important, keeps the mp3 stream alive.
            this.webRequest.ReadWriteTimeout = int.MaxValue;

                this.webResponse = (HttpWebResponse)webRequest.GetResponse();
                this.responseStream = this.webResponse.GetResponseStream();
                this.responseStream.ReadTimeout = int.MaxValue;

                if (this.responseStream != null)
                    // Read stream here..
                     stream.Read(...) // hangs after a while
                    // stream.length  is 0 here
            catch (WebException e)

                if (e.Status != WebExceptionStatus.RequestCanceled)
                    ErrorHandler.DebugMessage(" " + e.Message);

Any suggestions what I am missing? There are a lot of topics with networking issues on NETMF. Hopefully this is not another one?



@ tester56723 - Do you get any exceptions if you let it sit for awhile once it hangs? If you’re familiar with Wireshark, could you get a packet trace around when it stops?


Not sure about the stream.Read(). But the Socket.Read() method hangs forever if no data is available.
May be you should check if data is available before you actually read.


No there aren’t any exceptions but the stream length stays null. Hm I think the only chance is to reconfigure my switch port to mirroring to receive the data. Is there another chance to get the ENC28 data to development PC?

@ Reinhard Ostermeier
I do check this length so there is a chance to prevent this blocking call. But my problem is that I get no data any more. The stream length stays null


Well Wireshark becomes my friend I think :slight_smile:

The last message I see is an TCP error:

[Reassembly error, protocol TCP: New fragment overlaps old data (retransmission?)]

After that nothing appears in wireshark any more but the .NET MF board is still running. Ping is not possible any more.
Any appreciations? What does this error mean?


Another stream does not show any special whireshark errors. The stream nevertheless has also a length of 0. Thus blocks. A check to prevent this situation does not help because the length stays null…


I have an 200ms timer which counts the bytes I have read from the stream. All the time there are 200ms slot without any single received stream byte. For me this is very strange. There is a producer and a consumer thread. When I am running out of bytes for playing, the consumer thread halts with an AutoResetEvent. So then there is enough time to read the stream, but even here occur this empty 200ms.

The new stream address is currently still running without being always 0. So the time seems to be not constant between the errors. But as I said playing the stream is still very instable because of the different number of bytes per interval.

Another idea, may the shared FEZ Hydra SPI cause this issue? Both ENC28 and the music module use them… There is a bad feeling about that in my mind ::slight_smile:


Finally the blocking read occurs again. See the picture of the wireshark trace. Currently this issue is a show stopper for me, no way to get a workaround… :’(


Do you have some proto typing hardware around (like G120 HDR + ENC28 + Music Module) so you can test your software with separate SPI’s?


I am very sure that this happens only on my hydra. Nevertheless I have started to run a stream on my PC.


No unfortunately not but I think I should buy one. Is the G120HDR as fast as Hydra?


@ tester56723 - G120 was just an example. You should stay as close to your hardware as possible. But I never used Hydra, so I can’t help you selecting the right components.


Really? How can I use them?


I thought of the oberon ethernet board?

There are also some performance issues. I think these are related to the shared SPI, both receiving the bytes over ethernet and sending them to the VS1053b use the same SPI interface. Two independent one would be the best…


Except socket 3 and 4 share the same SPI peripheral pins (PA25, PA26, PA27)

Fundamentally, SPI is a shared bus and is meant to work that way. When comms to a device is needed, the appropriate CS line is asserted, and the CLK is toggled to communicate to the device.

I believe the framework locks the SPI bus to ensure you can’t have a SPI battle - although this is something that definitely could be something accidental that came from 4.3 ? (this is a new 4.3 install, right?)


What do you mean with “new 4.3 install”? These versions are used:
.NET MF version: .NET MF 4.3 RTM (QFE1)
Gadgeteer Pack: NETMF and Gadgeteer Package 2014 R3 (2014 R3, September 2014, NETMF 4.3 SDK)
FEZ Hydra FW:
FEZ Hydra Loader:

Meanwhile my code is running smoother. But there are still issue every few minutes when suddenly the playing stream stops for 3 seconds. I cannot explain this. On my PC the stream is plaing without any problems.

Long term stability is still a problem. After 10-15 hours there is a complete lock up of the stream as described before.

@ andre.m
You are right running the code without music module is my next try to isulate the error. A new board is something I try for sure.
What dou you recommend?

My favorite is the montaineer ethernet mainboard. But I think the RAM size is to small. My buffer uses currently already 64KB. The board has only 192KB. A small webserver is also planned in my project. This seems to exhaust the RAM…

Another option would be the G120HDR Module Rev2. There I miss some Gadgeteer Sockets. This could lead to a massive cabling chaos ;D


I meant - you’re trying to use 4.3, right, and you haven’t run this application in 4.2 (and had a different behaviour). That simply implies to me that it’s possible that you’ve hit something nobody else has put under the level of stress that your app does, that might have come into the changes 4.3 introduced. 4.2 I am sure has had many workouts similar to this and I’ve no recollection of similar issues being discussed that were issues identified in the framework


So after 4h of running without the music module the shows the same behaviour again. It blocks the running thread…
It seems like the issue has nothing to do with shared SPI but with the network stack or streaming code.

What should I do?

Do have seen any issues with stream reading in 4.3?


@ tester56723 -

We don’t see it but it doesn’t mean that bug does not exist. We are different router, network traffic, etc… :slight_smile:
while we are busy on some different thing before take a look on this issue, can you give us a try please,

Change your code to some like this:

if (this.responseStream != null)
                    // Read stream here..
                    if (stream.Lenght >0)
                            int received = 0;
                                   received  =  stream.Read(...) ;
                                   if (  received  ==0)

These for sure that we only read when data is available, and sure we read all them before next request.


Sorry for my late answer, time was running out the last days :frowning:

Now I have a minimum visual studio project which only reads the stream. There is no music module or IR module. Let’s see if this is running stable.

If not may I send you GHI people this project for reproducing the error?