Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: MP3 Http Streams problem. (Read 2812 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

MP3 Http Streams problem.

FB RC11, RC14

Stops playing mp3 http stream every 5-10 minutes. I can test shoutcast streams only. No any messages about attempts to resync in console window. Just stops play that is it. If I try to start playing station over, everything fine until it happens again...

This behavior repeated with any station.

I have no Idea how to figure out that is going on. Is there any way to enable more detailed logging? Source code of foo_read_http.dll to be able to see in debugger what is going on? Anything. I love FB but it’s pretty annoying to hit play every five minutes.

MP3 Http Streams problem.

Reply #1 –
Ok. Nobody mentioned that sources of foo_read_http.dll available in SDK.

I found what happening, but now I’m not sure how to fix that.
Foo hanging inside Reader_http::fillbuf. Situation is simple it trying to fill buffer, calls JNL_HTTPGet::run() witch calls
m_con->run(); Inside that JNL_Connection::run :

Code: [Select]
if (m_send_pos>=m_send_buffer_len) 
...
int res=::recv(m_socket,m_recv_buffer+m_recv_pos,len,0);
if (res == 0 || (res < 0 && ERRNO != EWOULDBLOCK))
{        
m_state=STATE_CLOSED;
break;
}
if (res > 0)
{
bytes_allowed_to_recv-=res;
if (bytes_rcvd) *bytes_rcvd+=res;
m_recv_pos+=res;
m_recv_len+=res;
}

recv returns -1 and ERRNO is EWOULDBLOCK. That as I understand means nothing read from the socket if it in nonbocked mode. So that how it hangs fillbuff wait for something from connection but nothing appears to be read, JNL_Connection sate is CONNECTED. Nothing happens. Any ideas how to fix that in the good manners?
 

MP3 Http Streams problem.

Reply #2 –
RC15 has the same problem.

That situation happens when connection is overloaded. ::recv doesn't return that socket is closed, and ask to wait more, more and more... That is never ends.

There is some timeout handling have to be implemented. If there is no any data receved for some period of time, underlying http connection should be reopened. I've used 0.5 seconds, works fine, but that is not right since that value is function  from stream bitrate and buffer size.

I've beed managed to fix that. I know, it is dirty, but that works for me as temporarry solution.

Code: [Select]
void Reader_http::fillbuf(UINT max,bool shutup)
{
    if (max==0) max=1;
    if (length>0 && position+max>length) max=(int)(length-position);
    
    const DWORD timeout = 500;
    int last_bytes_read = -1;
    DWORD last_bytes_time = 0;

    while(!aborting) //stop prebuffering if we want to seek
    {

  if (get.run()) break;
        int bytes_available = get.bytes_available();
  if (aborting || bytes_available >= (int)max) break;

  if (last_bytes_read < bytes_available) {
      last_bytes_read = bytes_available;
      last_bytes_time = GetTickCount();
  } else if ((GetTickCount() - last_bytes_time) >= timeout) {
      http_init(); // reconnect
      b_starting = false;
      last_bytes_read = -1;
      last_bytes_time = 0;
  }
  SleepEx(1,TRUE);
    }
}


Songs titles are back in RC15, that is great!