Very slow buffer fill

[nomego]

Anyone experiencing slow buffer fill?

Yesterday I tried running an mkv with DTS sound through mencoder and the buffer filled up quickly in the beginning, but halfway though the movie, it started stuttering and we had to pause to let it buffer.

I'm running 64-bit Ubuntu Linux on a Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz processor with 4GB of RAM.
The computer and PS3 is connected with gigabit ethernet and I've tried streaming the files from an external USB HDD or the internal SATA HDD.
The CPU-usage rarely goes over 30% (which really is 30% of one core).

I recently tried upgrading to Oneiric Beta 1 but nothing improved.

Anyone experienced anything similar?
Any setting in PMS that could case this?

[arrrghhh]

The router, it supports gigabit speeds?

Have you checked top or htop (my fave) to see perhaps "why" the buffer is filling slowly? iotop might be useful here as well. I would make sure you're not saturating anything. It takes many processor cycles in order to transcode on the fly, but I would think it's possible with your machine. You *might* need more cores, are you running a multi-threaded mencoder?

I got sick of MKV's not because just watching, but anytime I would try to fast forward or rewind, it would freak out. If you use mkv2vob (Windows app...) it will convert pretty much any mkv to MPG. The vast majority of the videos I convert don't even need to be transcoded... Obviously a few did .

[nomego]

Yeah everything supports gigabit speeds, if the network would be the problem I assume the buffer would fill up anyways?

I've been checking top and iotop, trying htop as well now.
In htop, peak levels of CPU are when both cores reach 30%. They're normally around 10-15-20%.

Disk write speeds are usually only around 500K/s in iotop, where tsMuxer takes between 75-95%.

Well in PMS I've entered that I want to use my both cores for transcoding, and I see 6 mencoder processes and 4 tsMuxer in htop.
Maybe I should only use one? It seems like they're threading by themselves?

[nomego]

Only using one core actually made everything slower.
Renice'ing all PMS, mencoder and tsMuxer processes to -6 didn't speed anything up or made any more use of the available CPU power.
Running something else with disk access (apt-get install) increased disk write to 5MB/s.

It just feels like PMS/mencoder/tsMuxer doesn't want to use any more resources?!

[nomego]

Ok, further tests.
Running the exact same mencoder command as PMS actually makes use of 100% of both cores (to a different output).
Even outputting to a named pipe will make use of as much CPU as possible (as long as I'm cat'ing the pipe to /dev/null).

HOWEVER, disabling "Keep DTS audio in stream" makes mencoder make use of all CPU it can until the buffer is filled up (which goes pretty fast - no need to pause to wait for it and it never falls below full).

What I noticed is also that when the above option is de-selected, mencoder handles the transcoding by itself.
When it's enabled, mencoder transcodes to two names pipes, which tsMuxer reads to mux them together.

This makes me believe that either tsMuxer or the 32-bit library (I'm running 64-bit) is the culprit and can't read fast enough from the named pipe buffer, which fills the buffer up and stalls mencoder.

[reaper829]

Try enabling "Keep DTS audio in stream", and on that same page, choose "Definitely disable subtitles". That solved the problem for me. Enabling subtitles was too much for my paltry Athlon II X2 260..

[djmwj]

Ok, further tests.
Running the exact same mencoder command as PMS actually makes use of 100% of both cores (to a different output).
Even outputting to a named pipe will make use of as much CPU as possible (as long as I'm cat'ing the pipe to /dev/null).

HOWEVER, disabling "Keep DTS audio in stream" makes mencoder make use of all CPU it can until the buffer is filled up (which goes pretty fast - no need to pause to wait for it and it never falls below full).

What I noticed is also that when the above option is de-selected, mencoder handles the transcoding by itself.
When it's enabled, mencoder transcodes to two names pipes, which tsMuxer reads to mux them together.

This makes me believe that either tsMuxer or the 32-bit library (I'm running 64-bit) is the culprit and can't read fast enough from the named pipe buffer, which fills the buffer up and stalls mencoder.

I too have experienced the same on ubuntu 11.10 (64bit) with athlon II x4. when i deactivate the "Keept DTS audio in stream" it will buffer properly. I wonder what libraries are causing this....