Martin Cap macap20001@compuserve.de wrote:

Today I tried to set O_NONBLOCK to the open()-calls (the code does a "do{ r = read(...); }while(r!=-1 && r != EINTR);" at stream.c:271

shouldn't it be: while(r!=-1 && errno != EINTR); ?

best regards ... clemens

On 24 Jul 2005 Martin Cap macap20001@compuserve.de wrote:

Today I tried to set O_NONBLOCK to the open()-calls (the code does a "do{ r = read(...); }while(r!=-1 && r != EINTR);" at stream.c:271 so

I'll come back to the details later (rather busy lately).

The code actually is:

do { r=read(fd,buffer+fill,MP3FILE_BUFSIZE-fill); } while(r==-1 && errno==EINTR);

The return code for a unsatisfied read request in non-blocking mode is EAGAIN.

But normaly the plugin uses mmap() to read the file (if you haven't disabled this by intent), so that the code part you mentioned isn't used at all.

Regards.

Clemens Kirchgatterer wrote:

...

Martin Cap macap20001@compuserve.de wrote:

...

Today I tried to set O_NONBLOCK to the open()-calls (the code does a

"do{ r = read(...); }while(r!=-1 && r != EINTR);" at stream.c:271

shouldn't it be: while(r!=-1 && errno != EINTR); ?

when i think about it, i'd rather do { r = read(...); } while (r >= 0 || ((r < 0) && (errno == EINTR)));

b.t.w. doesn't that eat cpu like crazy when O_NONBLOCK is set?

Sure it does. The strange things is, it also does without O_NONBLOCK set. The call to read() blocks infinitely and puts CPU-usage to 99%. I don't know the cause for this, as I'm the only one with this strange behavior in combiantion with the mp3-plugin.

Stefan Huelswitt wrote:

On 24 Jul 2005 Martin Cap macap20001@compuserve.de wrote:

The code actually is:

do { r=read(fd,buffer+fill,MP3FILE_BUFSIZE-fill); } while(r==-1 && errno==EINTR);

The return code for a unsatisfied read request in non-blocking mode is EAGAIN.

Exactly.

But normaly the plugin uses mmap() to read the file (if you haven't disabled this by intent), so that the code part you mentioned isn't used at all.

Hu ! I haven't changed anything the first time I compiled and ran the plugin and it did not work then. How could this happen ? I will have to check this first. Thanks for your help so far and I'll get back to this later this evening.

Martin Cap wrote:

Stefan Huelswitt wrote:

...

But normaly the plugin uses mmap() to read the file (if you haven't disabled this by intent), so that the code part you mentioned isn't used at all.

Hu ! I haven't changed anything the first time I compiled and ran the plugin and it did not work then. How could this happen ? I will have to check this first. Thanks for your help so far and I'll get back to this later this evening.

Hu, Hu ! I reinstalled the plugin from sources and still don't have no such luck. I played with the code as I said in my initial mail, which made the backtrace wrong, here's the correct one. Sorry for the extra confusion !

#0 0xb7f446a1 in __read_nocancel () from /lib/tls/libpthread.so.0 #1 0xb7692e32 in cStream::Stream (this=0x92bab70, data=@0xb1385618, len=@0xb138561c, rest=0x7ff9 <Address 0x7ff9 out of bounds>) at stream.c:256 #2 0xb7699b66 in cScanID3::DoScan (this=0x92bac18) at decoder-mp3.c:38 #3 0xb76989ee in cMP3Decoder::Start (this=0x92baad0) at decoder-mp3.c:155 #4 0xb769165d in cMP3Player::Action (this=0x92829a0) at player-mp3.c:1798 #5 0x080ef2a2 in cThread::StartThread () #6 0xb7f3fb63 in start_thread () from /lib/tls/libpthread.so.0 #7 0xb7df418a in clone () from /lib/tls/libc.so.6

So the dead-lock happens at line 256. Strange, obviously. (I can output what r + errno give me when returning from read() and post it here.)

Darren Salt wrote:

That looks wrong too.

while (r != -1 || errno == EINTR);

:), I should have copy&pasted the code correctly in my initial mail.

Stefan Huelswitt wrote:

Without loocking at the details, I still cannot understand why this code part is reached.

For me there are only 3 ways for this: 1.) You have disabled USE_MMAP at the beginning of stream.c 2.) The file is bigger than MAX_MMAP_SIZE (currently 32mb) 3.) mmap() failed for some reason (should give syslog entry if run in debug loglevel)

Hi,

when running the plugin (actually vdr) in debug-mode, I get the following messages on the console (the plugin-thread again locks the computer with 99% CPU-usage):

"mgr: background scan thread started (pid=3868) mgr: scanning (id3) somemp3-file.mp3 mad: id3-scan, lost sync 4952594c 45425343 SOME_COMMENTS_TAG mad: id3-scan, lost sync 00000000 07000000 mgr: waiting for bgr release ... (pass2=0 nono=(nil) scan=0x8299b30)"

Maybe this helps a little ?!