I am using vdr-1.3.44 with xine-0.7.8 and everything works fine under normal operations. But, If I start using intensive CPU load applications, such as "VDRConvert" to create a dvd, vdr starts giving me ring buffer overflow messages.
Mar 21 03:29:43 sid vdr: [19350] buffer usage: 0% (tid=19349) Mar 21 03:31:02 sid vdr: [19350] ERROR: 1 ring buffer overflow (177 bytes dropped) Mar 21 03:30:45 sid vdr: [19350] buffer usage: 70% (tid=19349) Mar 21 03:30:46 sid vdr: [19350] buffer usage: 50% (tid=19349) Mar 21 03:30:52 sid vdr: [19350] buffer usage: 70% (tid=19349) Mar 21 03:30:53 sid vdr: [19350] buffer usage: 60% (tid=19349) Mar 21 03:30:59 sid vdr: [19350] buffer usage: 70% (tid=19349) Mar 21 03:31:00 sid vdr: [19350] buffer usage: 80% (tid=19349) Mar 21 03:31:01 sid vdr: [19350] buffer usage: 90% (tid=19349) Mar 21 03:31:02 sid vdr: [19350] buffer usage: 100% (tid=19349) Mar 21 03:31:03 sid vdr: [19349] clearing transfer buffer to avoid overflows Mar 21 03:31:31 sid vdr: [19350] ERROR: 2682 ring buffer overflows (504205 bytes dropped)
Is this a known issue?
Best Regards,
C.Y.M wrote:
I am using vdr-1.3.44 with xine-0.7.8 and everything works fine under normal operations. But, If I start using intensive CPU load applications, such as "VDRConvert" to create a dvd, vdr starts giving me ring buffer overflow messages.
I had serious disk throughput issues that were IMHO caused by the file system driver (reiser) being too CPU-intensive. This also leads to buffer overruns, since the writer cant keep up with the incoming data. Things were better on kernel 2.4 and definitely improved on 2.6 after re-formatting the file system. (fragmentation)
In light cases, playback is jerky while cutting, in severe cases, even two parallel recordings caused an CPU overload of my C3-600.
Cheers,
Udo
Udo Richter wrote:
C.Y.M wrote:
I am using vdr-1.3.44 with xine-0.7.8 and everything works fine under normal operations. But, If I start using intensive CPU load applications, such as "VDRConvert" to create a dvd, vdr starts giving me ring buffer overflow messages.
I had serious disk throughput issues that were IMHO caused by the file system driver (reiser) being too CPU-intensive. This also leads to buffer overruns, since the writer cant keep up with the incoming data. Things were better on kernel 2.4 and definitely improved on 2.6 after re-formatting the file system. (fragmentation)
In light cases, playback is jerky while cutting, in severe cases, even two parallel recordings caused an CPU overload of my C3-600.
I wonder if running xine with some type of priority would help. Also, perhaps a networked version of xine my solve this. This is not a problem if I use my full featured card as the primary DVB.
Best Regards,
Hi,
C.Y.M wrote:
I am using vdr-1.3.44 with xine-0.7.8 and everything works fine under normal operations. But, If I start using intensive CPU load applications, such as "VDRConvert" to create a dvd, vdr starts giving me ring buffer overflow messages.
I had serious disk throughput issues that were IMHO caused by the file system driver (reiser) being too CPU-intensive. This also leads to buffer overruns, since the writer cant keep up with the incoming data. Things were better on kernel 2.4 and definitely improved on 2.6 after re-formatting the file system. (fragmentation)
In light cases, playback is jerky while cutting, in severe cases, even two parallel recordings caused an CPU overload of my C3-600.
I wonder if running xine with some type of priority would help. Also, perhaps a networked version of xine my solve this. This is not a problem if I use my full featured card as the primary DVB.
What are your buffer settings in vdr-xine?
With the update from 0.7.6 to 0.7.7 you had to reduce the prebuffer as it is now exactly measured. And with 0.7.8 you should reduce the prebuffer further as it is increased indirectly by hysteresis.
If you buffer too much, then VDR will report a buffer overflow (especially under high CPU load), as the buffer is provided by VDR (#define TRANSFERBUFSIZE MEGABYTE(2)).
As the satellite streams at a constant rate, VDR puts as much data into the buffer as xine takes out of it. So the buffer should never run full and the average buffer usage depends on the above settings. But if the average is to high, a burst write may cause an overflow, especially when xine doesn't get enough CPU time to read the buffer immediately.
On my EPIA system with a 600 MHz C3 CPU, I run vdr with nice -n 19 and xine with nice -n -20. I run VDR that nice, because background tasks like EPG scan had an impact on fluent replay with xine. But meanwhile, the most recent VDR versions schedule those threads a lower priority anyway. So I'm not sure whether it is still a good idea to run VDR that nice, especially when there are other tools like VDRConvert which run at normal priority. Maybe, xine should have the highest priority and VDR should be above the other processes.
Bye.
What are your buffer settings in vdr-xine?
I had xine on the default settings. The buffer set to 8 and hystersis set to 4 frames. Perhaps with the hysteresis, I should lower the buffer to 6 and hysteresis to 3? What is your recommended setting? This is an athlon 2000 with 756MB RAM.
With the update from 0.7.6 to 0.7.7 you had to reduce the prebuffer as it is now exactly measured. And with 0.7.8 you should reduce the prebuffer further as it is increased indirectly by hysteresis.
If you buffer too much, then VDR will report a buffer overflow (especially under high CPU load), as the buffer is provided by VDR (#define TRANSFERBUFSIZE MEGABYTE(2)).
As the satellite streams at a constant rate, VDR puts as much data into the buffer as xine takes out of it. So the buffer should never run full and the average buffer usage depends on the above settings. But if the average is to high, a burst write may cause an overflow, especially when xine doesn't get enough CPU time to read the buffer immediately.
Yes, this seems to be what is happening with the DVD plugin. Too much buffer and its getting overflowed, causing it to skip frames.
On my EPIA system with a 600 MHz C3 CPU, I run vdr with nice -n 19 and xine with nice -n -20. I run VDR that nice, because background tasks like EPG scan had an impact on fluent replay with xine. But meanwhile, the most recent VDR versions schedule those threads a lower priority anyway. So I'm not sure whether it is still a good idea to run VDR that nice, especially when there are other tools like VDRConvert which run at normal priority. Maybe, xine should have the highest priority and VDR should be above the other processes.
Thanks.
C.Y.M wrote:
What are your buffer settings in vdr-xine?
I had xine on the default settings. The buffer set to 8 and hystersis set to 4 frames. Perhaps with the hysteresis, I should lower the buffer to 6 and hysteresis to 3? What is your recommended setting? This is an athlon 2000 with 756MB RAM.
From the Manual, I can see the default settings are Buffer=4 and Hysteresis=4. I
think I just had the buffer set way too high. Thanks again for your help.
Best Regards.
Hi,
C.Y.M wrote:
What are your buffer settings in vdr-xine?
I had xine on the default settings. The buffer set to 8 and hystersis set to 4 frames. Perhaps with the hysteresis, I should lower the buffer to 6 and hysteresis to 3? What is your recommended setting? This is an athlon 2000 with 756MB RAM.
I've just tried 32 and 4 (= a total of 36 frames) and didn't get any overflow.
What's your buffer usage which VDR reports in syslog?
E. g. for the above settings, I get the following report when switching away from channel ZDF after vdr-xine has reported it's final buffer size:
Mar 26 13:07:12 video vdr: [10254] transfer thread ended (pid=9307, tid=10254) Mar 26 13:07:12 video vdr: [9307] buffer stats: 209432 (9%) used Mar 26 13:07:12 video vdr: [10257] TS buffer on device 2 thread ended (pid=9307, tid=10257) Mar 26 13:07:12 video vdr: [10255] buffer stats: 123892 (5%) used Mar 26 13:07:12 video vdr: [10255] receiver on device 2 thread ended (pid=9307, tid=10255)
With the update from 0.7.6 to 0.7.7 you had to reduce the prebuffer as it is now exactly measured. And with 0.7.8 you should reduce the prebuffer further as it is increased indirectly by hysteresis.
If you buffer too much, then VDR will report a buffer overflow (especially under high CPU load), as the buffer is provided by VDR (#define TRANSFERBUFSIZE MEGABYTE(2)).
As the satellite streams at a constant rate, VDR puts as much data into the buffer as xine takes out of it. So the buffer should never run full and the average buffer usage depends on the above settings. But if the average is to high, a burst write may cause an overflow, especially when xine doesn't get enough CPU time to read the buffer immediately.
Yes, this seems to be what is happening with the DVD plugin. Too much buffer and its getting overflowed, causing it to skip frames.
This cannot be the cause, as buffering is only active when viewing Live TV. The buffer is only necessary as the satellite streams at constant rate, but xine wants to read the data on demand.
When playing DVDs, no extra buffers are allocated at VDR side by vdr-xine, as the DVD drive can typically supply data at a speed higher than 1x and therefore can fulfill xine's on demand requests.
On my EPIA system with a 600 MHz C3 CPU, I run vdr with nice -n 19 and xine with nice -n -20. I run VDR that nice, because background tasks like EPG scan had an impact on fluent replay with xine. But meanwhile, the most recent VDR versions schedule those threads a lower priority anyway. So I'm not sure whether it is still a good idea to run VDR that nice, especially when there are other tools like VDRConvert which run at normal priority. Maybe, xine should have the highest priority and VDR should be above the other processes.
Bye.
-
C.Y.M -
Reinhard Nissl -
Udo Richter