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