On Wed, Jun 15, 2005 at 04:56:05PM +0200, Wolfgang Rohdewald wrote:
> On Mittwoch 15 Juni 2005 14:49, Dr. Werner Fink wrote:
> > On Wed, Jun 15, 2005 at 02:28:16PM +0200, Wolfgang Rohdewald wrote:
> > > On Mittwoch 15 Juni 2005 11:41, Dr. Werner Fink wrote:
> > > > > The SubStreamType found varies. The record is not pre 1.3.19.
> > > > >
> > > > > This happens _only_ after fastrewind/play, fastforward/play works correctly.
> > > >
> > > > Does this also happen with 261d ?
> > >
> > > yes.
> > >
> > > If you try to reproduce it, don't do it near the beginning of the recording.
> >
> > And really both firmware hang and will be reseted by the driver
> > after 5 seconds? Or do they only stop replaying in other words
> > do waiting for new commands or data (aka no ARM crash)?
>
> you are right in that the firmware does not reset. However the behaviour is
> rather unpredictable afterwards. Especially if OSDSetBlock times out it will
> sometimes not recover: (this example was with 261e)
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.
But this is only a guess.
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
