diff mbox

VDR+DXR3 - stability problems (possible patch)

Message ID 4284FE2D.2050702@uklinux.net
State New
Headers

Commit Message

Jon Burgess May 13, 2005, 7:21 p.m. UTC 
  Ville Skyttä wrote:
> On Fri, 2005-05-13 at 14:56 +0200, Mikolaj Tutak wrote:
> 
> 
>>But the only solution is to stop VDR (sometimes it requires kill -9) and
>>load it again. Dou you know any solution/workaround for this? Maybe other
>>combination of DXR3 plugin/driver versions?
> 
> 
> http://sf.net/mailarchive/forum.php?thread_id=7212515&forum_id=7173
> 
> Someone reported on em8300-devel that removing pthread_setschedparam()
> calls from both VDR and the DXR3 plugin helped with similar problems in
> his setup.
> 

Removing the pthread_setschedparam() helps to prevent a complete lockup 
in my setup. Unfortunately the soft lockups which require the "kill -9" 
still occur. The patch attached seems to help, but hasn't had much testing.

The patch attached also seems to help the plugin recover more gracefully 
  when it gets some bad data. It still needs some more work because 
sometimes the stream still needs to be manually stopped and restarted to 
resume playback (but at least it does stop instead, rather than locking 
up vdr).

I think the problem that this patch helps address is that the dvbplayer 
thread gets stuck waiting for the flush to finish and the main VDR 
thread cancels it. Unfortunately the thread sometimes holds a lock on 
the dxr3syncbuffer and this stops the video output thread. With the 
patch applied, the flush returns and thread exits before the 3 second 
thread cancel timeout.

	Jon

Comments

Mikolaj Tutak May 14, 2005, 5 p.m. UTC | #1 
Jon Burgess napisa?(a):

>
> Removing the pthread_setschedparam() helps to prevent a complete 
> lockup in my setup. Unfortunately the soft lockups which require the 
> "kill -9" still occur. The patch attached seems to help, but hasn't 
> had much testing.

As in mine, removing pthread_setschedparam() helps a little but not 
completly.

> The patch attached also seems to help the plugin recover more 
> gracefully when it gets some bad data. It still needs some more work 
> because sometimes the stream still needs to be manually stopped and 
> restarted to resume playback (but at least it does stop instead, 
> rather than locking up vdr).

This sounds better than manual vdr restart.

> I think the problem that this patch helps address is that the 
> dvbplayer thread gets stuck waiting for the flush to finish and the 
> main VDR thread cancels it. Unfortunately the thread sometimes holds a 
> lock on the dxr3syncbuffer and this stops the video output thread. 
> With the patch applied, the flush returns and thread exits before the 
> 3 second thread cancel timeout.

Now I'm tesing your patch, after while I return some feedback :-)
Seppo Ingalsuo May 15, 2005, 8:27 p.m. UTC | #2 
Hi,

I've noticed that dxr3 cvs has become more unstable than so time ago 
(about that time when yellow OSD garbage in e.g. STTNG skin was fixed in 
dxr3 plugin) so I gave this a try.

Jon Burgess wrote:

>
> The patch attached also seems to help the plugin recover more 
> gracefully  when it gets some bad data. It still needs some more work 
> because sometimes the stream still needs to be manually stopped and 
> restarted to resume playback (but at least it does stop instead, 
> rather than locking up vdr).
>
> I think the problem that this patch helps address is that the 
> dvbplayer thread gets stuck waiting for the flush to finish and the 
> main VDR thread cancels it. Unfortunately the thread sometimes holds a 
> lock on the dxr3syncbuffer and this stops the video output thread. 
> With the patch applied, the flush returns and thread exits before the 
> 3 second thread cancel timeout.

I think have seen these lockups when switching to non-active satellite 
channales or to satellite channels with corrupted data (there are many 
on Hotbird). Now the watchdog doesn't kill VDR as often and it is 
possible to manage interactively satellite channel list. This patch is 
an improvement to current plugin state.

However the problem where OSD graphics start to jump and flicker for a 
while and VDR gets stuck for quite long time is still present. It 
happens repeatably also in mp3 plugin or muggle plugin usage where 
playback of a song gets interrupted every now and then for a couple of 
seconds which is pretty annoying. Mp3 plugin worked better due to more 
stable OSD with the earlier dxr3 plugin version I mentioned. Have other 
dxr3 users seen this?

This is a bit off-topic, not related to this patch: I also tried to 
activate mp3 background image display but that seems to fail. According 
to logs my cover.jpg's get converted to mpg format but nothing is shown. 
Playback doesn't start without pressing jump keys.
  
Seppo

>
>     Jon
Martin Cap May 16, 2005, 8:35 a.m. UTC | #3 
Seppo Ingalsuo wrote:
> Hi,
Hi !
> 
> I've noticed that dxr3 cvs has become more unstable than so time ago 
> (about that time when yellow OSD garbage in e.g. STTNG skin was fixed in 
> dxr3 plugin) so I gave this a try.

> I think have seen these lockups when switching to non-active satellite 
> channales or to satellite channels with corrupted data (there are many 
> on Hotbird). Now the watchdog doesn't kill VDR as often and it is 
> possible to manage interactively satellite channel list. This patch is 
> an improvement to current plugin state.
> 

The plugin still cannot manage broken datastreams gracefully. This is 
surely the case here.

> However the problem where OSD graphics start to jump and flicker for a 
> while and VDR gets stuck for quite long time is still present. It 
> happens repeatably also in mp3 plugin or muggle plugin usage where 
> playback of a song gets interrupted every now and then for a couple of 
> seconds which is pretty annoying. Mp3 plugin worked better due to more 
> stable OSD with the earlier dxr3 plugin version I mentioned. Have other 
> dxr3 users seen this?
> 

Sure. But concerning the OSD going beserk, you can try playing around 
with the value
DEFINES+=-DFLUSHRATE=40 in the Makefile. I might help a little. But this is
still an open issue.

> This is a bit off-topic, not related to this patch: I also tried to 
> activate mp3 background image display but that seems to fail. According 
> to logs my cover.jpg's get converted to mpg format but nothing is shown. 
> Playback doesn't start without pressing jump keys.
>  

AFAIR there's a stillpicture generated, which is not supported and 
should make the plugin crash.
Luca Olivetti May 16, 2005, 9:13 a.m. UTC | #4 
Martin Cap wrote:

> Sure. But concerning the OSD going beserk, you can try playing around 
> with the value
> DEFINES+=-DFLUSHRATE=40 in the Makefile. I might help a little. But this is
> still an open issue.

This only helps if vdr is refreshing the osd too often (like when 
displaying the channel info with the sttng skin), in all other normal 
cases it does nothing. I think we're  simply asking the dxr3 too much.

Bye
Martin Cap May 16, 2005, 9:25 a.m. UTC | #5 
Luca Olivetti wrote:
> Martin Cap wrote:
> 
>> Sure. But concerning the OSD going beserk, you can try playing around 
>> with the value
>> DEFINES+=-DFLUSHRATE=40 in the Makefile. I might help a little. But 
>> this is
>> still an open issue.
> 
> 
> This only helps if vdr is refreshing the osd too often (like when 
> displaying the channel info with the sttng skin), in all other normal 
> cases it does nothing. I think we're  simply asking the dxr3 too much.
> 
> Bye
> 
> 

Hi,

hm, it used to help me... Beserking OSD is still there, but less.
Mikolaj Tutak May 16, 2005, 5:59 p.m. UTC | #6 
Seppo Ingalsuo napisa?(a):

>
> I think have seen these lockups when switching to non-active satellite 
> channales or to satellite channels with corrupted data (there are many 
> on Hotbird). Now the watchdog doesn't kill VDR as often and it is 
> possible to manage interactively satellite channel list. This patch is 
> an improvement to current plugin state.

OK, I when I unconnect Sat plug (no valid sat data) DXR3 plugin hangs 
very often during OSD display. Probably problem is displaying OSD 
without valid primary picture stream. Maybe sending "no signal" screen 
every second between valid data streems is a solution?!

> However the problem where OSD graphics start to jump and flicker for a 
> while and VDR gets stuck for quite long time is still present. It 
> happens repeatably also in mp3 plugin or muggle plugin usage where 
> playback of a song gets interrupted every now and then for a couple of 
> seconds which is pretty annoying. Mp3 plugin worked better due to more 
> stable OSD with the earlier dxr3 plugin version I mentioned. Have 
> other dxr3 users seen this?

Yes, I have this. Menu shows mixed trashes (swaped lines etc.) and VDR 
hangs for long time. Maybe I take snapshot some time.

> This is a bit off-topic, not related to this patch: I also tried to 
> activate mp3 background image display but that seems to fail. 
> According to logs my cover.jpg's get converted to mpg format but 
> nothing is shown. Playback doesn't start without pressing jump keys.

Yes, I have the same issue - no background with mp3 plugin :-(

I try vdr DXR3 plugin and Xine-VDR+fbxine -V dxr3, and with booth 
options there is issue "fifo full". Yesterday I changed microcode 
(em8300.uc) shipped with linux driver (version 0x29) to newest one 
(version 0x2e) and the playback seems far more stable - I have no hangs 
up till now during playback. But I have random lockups during displaying 
"black screen" (no valid tv stream) with visible OSD - short after VDR 
starts.
Luca Olivetti May 16, 2005, 6:27 p.m. UTC | #7 
Mikolaj Tutak wrote:

> I try vdr DXR3 plugin and Xine-VDR+fbxine -V dxr3, and with booth 
> options there is issue "fifo full". Yesterday I changed microcode 
> (em8300.uc) shipped with linux driver (version 0x29) to newest one 
> (version 0x2e) and the playback seems far more stable - I have no hangs 

Where did you get it?

Bye
Mikolaj Tutak May 16, 2005, 6:52 p.m. UTC | #8 
Luca Olivetti napisa?(a):

>> I try vdr DXR3 plugin and Xine-VDR+fbxine -V dxr3, and with booth 
>> options there is issue "fifo full". Yesterday I changed microcode 
>> (em8300.uc) shipped with linux driver (version 0x29) to newest one 
>> (version 0x2e) and the playback seems far more stable - I have no hangs 
>
>
> Where did you get it?

Sorry I mistyped version. I have 0x2d from newest Sigma Designs drivers, 
please try attached file.

And small question, when extracting microcodes from original driver I 
get 3 different files. 1st and 3rd works good and have the same version 
id, 2nd does not load. Anyone knows difference between 1st and 3rd, and 
with one is better?
Seppo Ingalsuo May 17, 2005, 3:17 p.m. UTC | #9 
Mikolaj Tutak wrote:

>
> OK, I when I unconnect Sat plug (no valid sat data) DXR3 plugin hangs 
> very often during OSD display. Probably problem is displaying OSD 
> without valid primary picture stream. Maybe sending "no signal" screen 
> every second between valid data streems is a solution?!

Vdr-xine does this. I was wondering this too when trying to play with 
mp3 plugin background image feature.

I tried yesterday to adjust FLUSHRATE to higher value (60ms) as 
suggested by Jon and Ville but it didn't work better than default 40 ms 
with berserking OSD. I'll try soon the new microcode and Ville's HW SPU 
decoder patch as well.

BR,
Seppo
Luca Olivetti May 17, 2005, 4:30 p.m. UTC | #10 
Seppo Ingalsuo wrote:

> I tried yesterday to adjust FLUSHRATE to higher value (60ms) as 
> suggested by Jon and Ville but it didn't work better than default 40 ms 
> with berserking OSD. I'll try soon the new microcode and Ville's HW SPU 
> decoder patch as well.

That patch doesn't do anything to address the stability problem[*].
I just think we're asking too much to the poor spu unit of the dxr3 and 
there's not much that can be done about it :-( (maybe the new microcode 
but I cannot tell yet).


[*] a dvd uses "subpictures" for the menus and subtitles. A dvd player 
normally has a hardware (or firmware) subpicture unit (spu) to decode 
and show subpictures. A full featured dvb card doesn't have one, but it 
has an osd unit, so vdr decodes subpictures in software to show them 
through the osd.
OTOH a dxr3 doesn't have an osd unit but it has an spu that the plugin 
(ab)uses to provide an osd. So, with a dxr3 this is the processing that 
goes on for dvd subpictures:

dvd subpicture -> software decoder -> osd -> spu encoder -> dxr3 spu

which is rather silly.

What the patch does is transform that into:

dvd subpicture -> dxr3 spu

Bye
Martin Cap May 17, 2005, 5:37 p.m. UTC | #11 
Mikolaj Tutak wrote:
> Luca Olivetti napisa?(a):
> 
>>
>> Where did you get it?
> 
> 
> Sorry I mistyped version. I have 0x2d from newest Sigma Designs drivers, 
> please try attached file.
> 

Hu, that's interesting. Surely something to try out soon :). Thanks....
Seppo Ingalsuo May 17, 2005, 8:18 p.m. UTC | #12 
Luca Olivetti wrote:

> Seppo Ingalsuo wrote:
>
>> I tried yesterday to adjust FLUSHRATE to higher value (60ms) as 
>> suggested by Jon and Ville but it didn't work better than default 40 
>> ms with berserking OSD. I'll try soon the new microcode and Ville's 
>> HW SPU decoder patch as well.
>
>
> That patch doesn't do anything to address the stability problem[*].

Yes, I noticed that. With new microcode and Ville's patch the behavior 
in mp3 plugin usage is even worse now. There were a couple of OSD 
crashes during one minute time mp3 playback when progress bar was visible.

In normal tv/recording viewing crazy going osd is fortunately rare.

Seppo
Martin Cap May 18, 2005, 4:03 p.m. UTC | #13 
Seppo Ingalsuo wrote:
> 
> Yes, I noticed that. With new microcode and Ville's patch the behavior 
> in mp3 plugin usage is even worse now. 

Hi,

Hm, I don't think this is related to this one new microcode. Most 
probably the latter case...
If you set the FLUSHRATE to 0ms again you surely have the same behavior 
as without the patch...
diff mbox

Patch

--- dxr3/dxr3syncbuffer.c.~1.1.2.8.~	2005-04-19 19:19:38.000000000 +0100
+++ dxr3/dxr3syncbuffer.c	2005-05-13 00:28:34.000000000 +0100
@@ -26,6 +26,7 @@ 
 */
 
 #include <unistd.h>
+#include <sys/time.h>
 #include "dxr3syncbuffer.h"
 #include "dxr3memcpy.h"
 
@@ -182,7 +183,9 @@ 
 {
     bool retVal = true;
     uint32_t currTime = m_dxr3Device.GetSysClock();
+    struct timeval tv_start, tv;
     m_bPollSync = true;
+    gettimeofday(&tv_start, NULL);
     if (m_demuxMode == DXR3_DEMUX_REPLAY_MODE)
     {
 	if (Available() >= Size() - (Size()*BUFFER_LIMIT/100))
@@ -192,10 +195,20 @@ 
 		   ((m_dxr3Device.GetSysClock() - currTime) <
 		    ((uint32_t)TimeoutMs * (uint32_t)45)))
 	    {
+		int d_s, d_us, ms;
 		m_bPutBlock = true;
 		EnableGet();
 		m_bWaitPts = false;
 		WaitForPut();
+ 		gettimeofday(&tv, NULL);
+		d_s  = tv.tv_sec  - tv_start.tv_sec;
+		d_us = tv.tv_usec - tv_start.tv_usec;
+		ms = d_s * 1000 + d_us / 1000;
+		if (ms > TimeoutMs * 2) {
+		    cLog::Instance() << "Secondary timeout\n";
+		    printf("Secondary timeout\n");
+		    break;
+		}
 	    }
 	    if (Available() >= Size() - (Size()*BUFFER_LIMIT_2)/100)
 	    {
@@ -211,6 +224,8 @@ 
 cFixedLengthFrame* cDxr3SyncBuffer::Push(const uint8_t* pStart, int length, uint32_t pts, eFrameType type)  throw (eSyncBufferException)
 {
     int lastIndex = 0;
+    struct timeval tv_start, tv;
+    gettimeofday(&tv_start, NULL);
 
     switch (m_demuxMode)
     {
@@ -223,10 +238,20 @@ 
 
 	while ((Available() >= Size() - (Size()*10)/100))
 	{
+	    int d_s, d_us, ms;
 	    m_bPutBlock = true;
 	    EnableGet();
 	    m_bWaitPts = false;
 	    WaitForPut();
+	    gettimeofday(&tv, NULL);
+	    d_s  = tv.tv_sec  - tv_start.tv_sec;
+	    d_us = tv.tv_usec - tv_start.tv_usec;
+	    ms = d_s * 1000 + d_us / 1000;
+	    if (ms > 2000) {
+		cLog::Instance() << "Push timeout\n";
+		printf("Push timeout\n");
+		break;
+	    }
 	}
 
 #if VDRVERSNUM < 10313