Hi!
I use Creative DXR3 decoder and SkyStar2, a have folowing software versions:
VDR 1.3.24/1.3.23 DXR3 Plugin (snapshot 0.2.3-cvs20050501, latest CVS does not support OSD) DXR3 Driver (latest CVS) Linux 2.6.11 SkyStar2 - b2c2_flexcop_pci (latest drivers from CVS linuxtv.org)
sometimes VDR output hangs, and syslog comes like this:
vdr[9688]: playing '/home/.other/video/....vdr' kernel: Fifo still full, trying stop cd9343e0 kernel: em8300.o: FIFO sync timeout during blocking write, n = 3414, copy_size = 0, total = 2048, free slots = 0 kernel: Fifo still full, trying stop cd9343e0 vdr[9688]: cDxr3Interface::Resuscitation Device failure detected kernel: em8300.o: FIFO sync timeout during blocking write, n = 5462, copy_size = 0, total = 0, free slots = 0 kernel: bt865.o: Configuring for PAL kernel: em8300_audio.o: Analog audio enabled vdr[9688]: cDxr3Interface::Resuscitation Microcode upload successful vdr[9688]: cDxr3Interface::Resuscitation Reopening devices took 1 kernel: em8300: Microcode version 0x29 loaded kernel: bt865.o: Configuring for PAL
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?
On Fri, 2005-05-13 at 14:56 +0200, Mikolaj Tutak wrote:
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.
Ville Skyttä wrote:
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
Ville Skyttä napisał(a):
Thanks, fot this link, it looks similar to mine issue. However removing pthread_setschedparam() calls (from vdr and plugin) only helps a little - hangs become less frequent (it's hard to say exactly). I try 2.6.11.8 kernel with disabled preemtion it does not help vdr/dxr3 in any way.
Maybe I try vdr+xine with dxr3 output? Xine seems to be more stable with dxr3 than vdr direct plugin...
This vdr plugin hangs are platform/hardware specific or this is pure plugin/software problem (race condition etc.)?
Jon Burgess napisał(a):
As in mine, removing pthread_setschedparam() helps a little but not completly.
This sounds better than manual vdr restart.
Now I'm tesing your patch, after while I return some feedback :-)
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:
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
Seppo Ingalsuo wrote:
Hi,
Hi !
The plugin still cannot manage broken datastreams gracefully. This is surely the case here.
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.
AFAIR there's a stillpicture generated, which is not supported and should make the plugin crash.
Martin Cap wrote:
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
Seppo Ingalsuo napisał(a):
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?!
Yes, I have this. Menu shows mixed trashes (swaped lines etc.) and VDR hangs for long time. Maybe I take snapshot some time.
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.
Mikolaj Tutak wrote:
Where did you get it?
Bye
On Mon, 2005-05-16 at 10:35 +0200, Martin Cap wrote:
Seppo Ingalsuo wrote:
Yep. Try -DFLUSHRATE=50, with that I don't remember ever seeing the flicker effect, but on the other hand 50ms is also just about where the delay starts to be somewhat annoying for example when quickly switching between entries in the OSD menus.
Something in addition to that; attached is a patch that backports the DXR3 hardware SPU decoder functionality from CVS HEAD to the vdr- dxr3-0-2 branch. It improves things somewhat here (in particular it fixes colors of DVD subtitles), but also triggers another "feature".
The palette seems to be changed slightly too early at times, for example when repeatedly opening/closing the channel info OSD, the info turns momentarily all green here before disappearing (or white if there are DVB subtitles in the current channel showing immediately after the channel info closes).
If someone tries this out, let me know how it works for you.
Luca Olivetti napisał(a):
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?
Mikolaj Tutak wrote:
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
Seppo Ingalsuo wrote:
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
Luca Olivetti wrote:
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
Mikolaj Tutak wrote:
Yes, I have this. Menu shows mixed trashes (swaped lines etc.) and VDR hangs for long time. Maybe I take snapshot some time.
Yes this occasional freeze with garbled OSD happens from time to time and seems to be much more frequent when there is no Video data (e.g. with the mp3 plugin). I don't know any way of fixing these problems.
I've been working on the problems that occur with occasional bursts of interference which can occasionally cause the output to lockup. I've made a few changes which seem to help a lot with getting the dxr3plugin to recover when this occurs.
Can you try adding this patch to the dxr3plugin and see if it helps?
Jon
Jon,
I built the plugin last night with two of your patches:
1. The pthread_setschedparam idea suggested on em8300-devel 2. The timeout patch posted on this list a few days ago
This looks like a replacement to them both with some additional changes to dxr3demuxdevice. Have I read this correctly?
I also notice that there is no change to VDR's thread.c in this patch. Do you think that this is un-necessary? I am keen to maintain a single VDR tree and was worried that the change to thread.c might have a negative effect on slower machines using the Xine plugin (I have a couple of these).
Sorry for all the questions. I really appreciate all your posts and patches for the DXR3 plugin, as well as those of Luca, Ville, Martin and others. For the first time yesterday (as I hadn't updated the plugin in a month or so), I was able to play Tetris using the OSD ;)
I will try the updated patch in the next couple of days and post back any findings.
Best wishes,
Allan
On Tue, 2005-05-17 at 23:44 +0100, Jon Burgess wrote:
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...
Allan Guild wrote:
This looks like a replacement to them both with some additional changes to dxr3demuxdevice. Have I read this correctly?
Mostly correct, but there is an additonal "return NULL" in the push timeout path. The changes in the dxr3demuxdevice code make it abort if the push() code returns NULL.
I didn't want to send a patch over the top other changes, so I packaged all the related changes together and generated the diff vs the vanilla dxr3plugin code.
I also notice that there is no change to VDR's thread.c in this patch.
The removal of realtime scheduling in thread.c was to help identify and debug the errant code which was hogging the CPU and making it appear like the machine had locked up. I don't think this change is useful in the normal use unless your machine still keeps locking up.
Jon
Jon Burgess napisał(a):
Probably sending "prepared" empty frame with/before OSD will help (when there is no real data). Similar to "NoSignal.pes" in vdr-xine. I'm afraid that DXR3 do not like OSD data without valid primary stream.
Can you try adding this patch to the dxr3plugin and see if it helps?
I tested your patch with my DXR3 setup (newest microdode 0x2e) I have two "fifo full" issues (without valid signal): 1. vdr exits, so I have to start it again 2. OSD garbaged (I can send you screenshot), "fifo full" message appeard in syslog, but vdr didn't exit. I recovers by pressing "menu"->4 (recordings)->green (rewind), but the stream plays jerky, but replaying sequence stop->menu->4->green helps and the strem looked OK.
-
Allan Guild -
Jon Burgess -
Luca Olivetti -
Martin Cap -
Mikolaj Tutak -
Seppo Ingalsuo -
Ville Skyttä