[vdr] replay audio record, fastrewind, play: firmware hangs

Dr. Werner Fink werner at suse.de
Thu Jun 16 12:11:59 CEST 2005


On Thu, Jun 16, 2005 at 12:49:18AM +0200, Wolfgang Rohdewald wrote:
> On Mittwoch 15 Juni 2005 17:15, Dr. Werner Fink wrote:
> > IMHO the firmware status is not that what the driver belive it is.
> > Maybe a VIDEO_CLEAR_BUFFER and/or AUDIO_CLEAR_BUFFER send to
> > the firmware with COMTYPE_REC_PLAY+__Play was not stopped afterwards
> > because there is no thread/process which can be woken up for this
> > or the playing state is gone in the driver without sending
> > COMTYPE_REC_PLAY+__Stop?  If this really happen the firmware will
> > ask the driver for getting data to be played and this will slow
> > down the BMP upload and all OSD commands.
> 
> more debug output: If I repeatedly fastrewind/play, __Stop is never
> called in between. Do you mean it should?
> 
> OTOH could the reason for the problems be that audio AND video is replayed
> for a recording that has no video? What does AUDIO_SET_AV_SYNC do then?

Nothing I guess ;)

> Jun 16 00:08:14 mm vdr[24123]: replay /var/lib/video/ARD-Nachtkonzert/2005-04-15.02.04.50.50.rec
> Jun 16 00:08:14 mm vdr[24123]: playing '/var/lib/video/ARD-Nachtkonzert/2005-04-15.02.04.50.50.rec/001.vdr'

One problem I see is stopping a running replay.  After
receiving and executing the __Stop request the firmware
goes two steps: first it waits on a free TX slot, if it
get one it performs an empty TX request
(debitype = DATA_MPEG_PLAY and debilen = 0 -> gpioirq()).
Note if the command and OSD queue is filled there is a
delay between receiving and executing commands.

Now you can slow down this two steps by Bitmap uploads
and if the firmware is receiving a __Play or __Stop
and executing this within those two steps the __Play
or __Stop commands are simply lost (which maybe leads
t oa wrong state in the driver).  Also the execution
of any other command, e.g. COMTYPE_REC_PLAY can be
slowed down by Bitmap uploads and other OSD commands.

IMHO there should be used a wait queue or similar which
could be used to sleep on after sending a
COMTYPE_REC_PLAY+__Stop to be waken if in the gpioirq()
the debilen == 0 for DATA_MPEG_PLAY is seen.

Timeout should be in the same region as used for checking
the ARM state ... clearly if the ARM is crashed, then all
sleepers should be also waken.  Also within a threaded
environment all other threads/programs calling
a COMTYPE_REC_PLAY afterwords have to sleep together with
the first caller.

> Jun 16 00:08:14 mm kernel: dvb-ttpci: dvb_audio_ioctl(): AUDIO_PLAY
> Jun 16 00:08:14 mm kernel: dvb-ttpci: av7110_av_start_play(): av7110_av_start_play:COMTYPE_REC_PLAY __Stop
> Jun 16 00:08:14 mm kernel: dvb-ttpci: av7110_av_start_play(): av7110_av_start_play:RP_AUDIO:COMTYPE_REC_PLAY __Play
> Jun 16 00:08:14 mm kernel: dvb-ttpci: dvb_audio_ioctl(): dvb_audio_ioctl returns 2
> Jun 16 00:08:14 mm kernel: dvb-ttpci: dvb_video_ioctl(): av7110:cbcd8000, cmd=28441
> Jun 16 00:08:14 mm kernel: dvb-ttpci: dvb_video_ioctl(): av7110:cbcd8000, cmd=28438
> Jun 16 00:08:14 mm kernel: dvb-ttpci: av7110_av_start_play(): av7110_av_start_play:COMTYPE_REC_PLAY __Stop
> Jun 16 00:08:14 mm kernel: dvb-ttpci: av7110_av_start_play(): av7110_av_start_play:RP_AV:COMTYPE_REC_PLAY __Play


> Jun 16 00:08:14 mm kernel: dvb-ttpci: dvb_video_ioctl(): dvb_video_ioctl returns 3
> Jun 16 00:13:57 mm kernel: dvb-ttpci: dvb_video_ioctl(): av7110:cbcd8000, cmd=28450
> Jun 16 00:13:57 mm kernel: dvb-ttpci: dvb_video_ioctl(): dvb_video_ioctl:VIDEO_CLEAR_BUFFER:COMTYPE_REC_PLAY,__Play,2,AV_PES
> Jun 16 00:13:57 mm kernel: dvb-ttpci: dvb_audio_ioctl(): av7110:cbcd8000, cmd=28428
> Jun 16 00:13:57 mm kernel: dvb-ttpci: dvb_audio_ioctl(): AUDIO_CLEAR_BUFFER
> Jun 16 00:13:57 mm kernel: dvb-ttpci: dvb_audio_ioctl(): dvb_audio_ioctl:AUDIO_CLEAR_BUFFER:COMTYPE_REC_PLAY,__Play,2,AV_PES
> Jun 16 00:13:57 mm kernel: dvb-ttpci: dvb_audio_ioctl(): av7110:cbcd8000, cmd=28423
> Jun 16 00:13:57 mm kernel: dvb-ttpci: dvb_audio_ioctl(): AUDIO_SET_AV_SYNC
> Jun 16 00:13:57 mm kernel: dvb-ttpci: dvb_audio_ioctl(): av7110:cbcd8000, cmd=28422
> Jun 16 00:13:57 mm kernel: dvb-ttpci: dvb_audio_ioctl(): AUDIO_SET_MUTE
> Jun 16 00:13:57 mm kernel: dvb-ttpci: dvb_video_ioctl(): av7110:cbcd8000, cmd=28448

> Jun 16 00:14:09 mm kernel: dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1
> Jun 16 00:14:09 mm kernel: dvb-ttpci: OSDSetBlock(): returns -110
> Jun 16 00:14:09 mm kernel: dvb-ttpci: av7110_osd_cmd(): av7110_osd_cmd(13) returns with -110
> Jun 16 00:14:19 mm kernel: dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1
> Jun 16 00:14:19 mm kernel: dvb-ttpci: OSDSetBlock(): returns -110
> Jun 16 00:14:19 mm kernel: dvb-ttpci: av7110_osd_cmd(): av7110_osd_cmd(13) returns with -110
> Jun 16 00:14:29 mm kernel: dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1
> Jun 16 00:14:29 mm kernel: dvb-ttpci: OSDSetBlock(): returns -110
> Jun 16 00:14:29 mm kernel: dvb-ttpci: av7110_osd_cmd(): av7110_osd_cmd(13) returns with -110
> Jun 16 00:14:39 mm kernel: dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1
> Jun 16 00:14:39 mm kernel: dvb-ttpci: OSDSetBlock(): returns -110
> Jun 16 00:14:39 mm kernel: dvb-ttpci: av7110_osd_cmd(): av7110_osd_cmd(13) returns with -110
> Jun 16 00:14:39 mm kernel: dvb-ttpci: dvb_video_ioctl(): av7110:cbcd8000, cmd=28450
> Jun 16 00:14:39 mm kernel: dvb-ttpci: dvb_video_ioctl(): dvb_video_ioctl:VIDEO_CLEAR_BUFFER:COMTYPE_REC_PLAY,__Play,2,AV_PES
> Jun 16 00:14:39 mm kernel: dvb-ttpci: dvb_video_ioctl(): dvb_video_ioctl:VIDEO_CLEAR_BUFFER:COMTYPE_REC_PLAY,__Slow,2,0
> Jun 16 00:14:39 mm kernel: dvb-ttpci: dvb_audio_ioctl(): av7110:cbcd8000, cmd=28428
> Jun 16 00:14:39 mm kernel: dvb-ttpci: dvb_audio_ioctl(): AUDIO_CLEAR_BUFFER
> Jun 16 00:14:39 mm kernel: dvb-ttpci: dvb_audio_ioctl(): dvb_audio_ioctl:AUDIO_CLEAR_BUFFER:COMTYPE_REC_PLAY,__Play,2,AV_PES
> Jun 16 00:14:39 mm kernel: dvb-ttpci: dvb_audio_ioctl(): av7110:cbcd8000, cmd=28423
> Jun 16 00:14:39 mm kernel: dvb-ttpci: dvb_audio_ioctl(): AUDIO_SET_AV_SYNC
> Jun 16 00:14:39 mm kernel: dvb-ttpci: dvb_video_ioctl(): av7110:cbcd8000, cmd=28440
> Jun 16 00:14:49 mm kernel: dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1
> Jun 16 00:14:49 mm kernel: dvb-ttpci: OSDSetBlock(): returns -110
> Jun 16 00:14:49 mm kernel: dvb-ttpci: av7110_osd_cmd(): av7110_osd_cmd(13) returns with -110



       Werner

-- 
AC3 loop through sound card http://bitstreamout.sourceforge.net/
Howto http://www.vdr-portal.de/board/thread.php?threadid=1958
------------------------------------------------------------------
 "Having a smoking section in a restaurant is like having
         a  peeing section in a swimming pool." -- Edward Burr



More information about the vdr mailing list