At the end I thought the bug was resolved. But now I am again working on the internet radio project and I encounter the same problem. I want to read from an mp3 stream and send the response bytes the music module. My hardware is the FEZ Hydra with the latest GHI package and firmware 4.3.6.0. ENC28 is connected to port 3.
Here is my code, I have reduced them to a minimum in order to isolate the bug:
HttpWebRequest webRequest;
HttpWebResponse webResponse;
Stream responseStream;
String url = "http://mp3ad.egofm.c.nmdn.net/ps-egofm_192/livestream.mp3";
webRequest = (HttpWebRequest)WebRequest.Create(url);
webRequest.Method = "GET";
// http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
//webRequest.Accept = "audio/basic";//"audio/*; q=0.8, audio/basic";
webRequest.ProtocolVersion = HttpVersion.Version10;
webRequest.KeepAlive = true; // Very important, keeps the mp3 stream alive.
webRequest.ReadWriteTimeout = int.MaxValue;
try
{
webResponse = (HttpWebResponse)webRequest.GetResponse();
responseStream = webResponse.GetResponseStream();
responseStream.ReadTimeout = 1000; // int.MaxValue; // Very important, keeps the mp3 stream alive.
byte[] buffer = new byte[10000];
int bytesFromOneStreamRead = 0;
AutoResetEvent autoResetEventSlowDownFiller = new AutoResetEvent(false);
int BLOCK_SIZE_BUFFER = 2048;
if (responseStream != null)
{
Debug.Print("Radio.StartPlaying(): Reading stream.");
while (true)
{
if ((responseStream.Length == 0) || (responseStream.Length < (BLOCK_SIZE_BUFFER/5)))
{
Debug.Print(" Waiting... responseStream.Length=" + responseStream.Length);
autoResetEventSlowDownFiller.WaitOne(50, false);
continue;
}
else
{
bytesFromOneStreamRead = responseStream.Read(buffer, 0, BLOCK_SIZE_BUFFER);
if (bytesFromOneStreamRead > 0)
{
Debug.Print(" Received " + bytesFromOneStreamRead + " bytes.");
}
else
{
// no data received from stream
Debug.Print(" Received 0 bytes.");
}
}
}
}
else
{
ErrorHandler.DebugMessage("Radio.StartPlaying(): Response stream is null.");
}
}
catch (WebException ex)
{
if (ex.Status != WebExceptionStatus.RequestCanceled)
{
ErrorHandler.DebugMessage(" " + ex.Message);
}
}
}
So the code is working fine but after a while the responseStream.Read() is not called any more because the length of the stream stays 0. This happens after some time. I had it playing a hour already but then it suddenly gets no new data. The FEZ Hydra responds to pings even when there is no data from the stream. I think the rest of the netmf runtime is alive because my heartbeat LED keeps flashing.
Please help me out this one is a show stopper which frustrates mes :wall:
if this is a “show stopper” then get the source for the Gadgeteer web server and find out what is happening.
I needed a web server for a regular MF project. I got the source for the Gadgeteer web server and after a few minor changes, I had it running outside of Gadgeteer. There is not a lot of code, and it was easy to get going. I finished about 15 minutes ago.
Open source should never be an show stopper. Implicit, or maybe explicit, in the use of OS is that if there is a problem, you can debug and fix it yourself.
Mike you are right. Now I have the sources from codeplex and the System.Http is buildt from the sources. The test is running, hopefully the error is coming from the managed code and not from the firmware.
So… ???
Today I dig into the System.dll until Socket.cs and its Receive() method.
buffer, int offset, int size, SocketFlags socketFlags)
{
if (m_Handle == -1)
{
throw new ObjectDisposedException();
}
return NativeSocket.recv(this, buffer, offset, size, (int)socketFlags, m_recvTimeout);
}
In case of the network stream delivering no data any more I can see the following things(see attached image). For me there is nothing special just no data available… If I set a timeout of 5000ms I get no exception… In my opinion there should be an exception.
I think this is related to the native components of the firmware so I cannot go deeper. :’( One thing I have found out meanwhile is that the number of bytes I read from the network stream affects the error in a way that it occurs later. In the beginning I had 2048 bytes per read call later on I reduced to 1024 and the stream ran an hour without any issues.
The FEZ Hydra has connected a music module. So my thought was that the error comes from the shared SPI. But even without the music module the error was there. During the tests I also changed the SPI clock speed. Now I have reset them to the default 4MHz for ENC28 and 2MHz for the music module. Its now quite stable for 15 minutes, keep fingers crossed
In my first post there is a link to the old thread. There is already a wireshark trace. I think the situation is now the same. But nevertheless I will make a new trace tomorrow and post it here.
Here is my wireshark trace. I have screenshots attached from Wiresharks “Expert Infos” tabs.
So far no special errors in the trace. Even after my application is blocked by the empty stream I receive normal wireshark traces. This tells me that ENC28J60 is working so far but cannot handover the data to the managed C# world any more… ???
@ GHI
I can send you the wireshark traces by mail if you like.
So the only left difference between our test environments is the internet connection. I am connected to an ADSL 2+ line with 16MB which has a point to point radio link inbetween. A high ping latency of 30 to 72ms is the result of this. When hearing internet radio from my squeezebox there were also breaks in the audio stream
What is your connection? I will try the LTE tethering from my smartphone.
Can anybody image an TCP/IP flag or similar which may have influence on such a stream? I am not sure whether my small ISP is doing the best for me i. Perhaps something disturbs the traffic. Maybe he has too many of the small little (router) boxes inside his netrok towards the handover point to the internet…
Yes there are other modules but even in tests without them the problem occurred. Now I was trying the variant with android LTE tethering to have a comparison to another internet connection. I must say it it is running much more stable but failed also with another error: CLR_E_FAILED. I cannot classify this error:think:
It was a overnight run so I cannot say how long it was running, in the morning I saw the crash. According to the transferred data two hours of playing are realistic.
Now I do another run, hopefully with good results. ???
