[vdr] Re: unknwon picture type / error in data stream

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Tilo Renkl wrote:
> 
> > > Hi,
> > >
> > > On Wednesday 30 July 2003 12:46, Christian Jacobsen wrote:
> > > > Hallo,
> > > >
> > > > >No patches to the drivers, only submitted "hw_sections=1" to the
> > > > >modprobe,
> > > > >so it's for all cards.
> > > >
> > > > with what DVB Driver / VDR Version (maybe it matters) ?
> > >
> > > Broken recordings with all recent versions I tried.
> > > The above mentioned test was done with 2003-07-09.
> >
> > Don´t understand why hw_sections=1 should solve this problem.
> > When I found
> > this bug on my system I was told on this list that it is
> > driver independent.
> > My idea was that there is a bug concerning switching between
> > live and transfer
> > mode introduced with the drivers available e.g. when VDR
> > 1.1.26 was released
> > (the next version I tried was VDR 1.1.30 and this sometimes had this
> > 'unknown picture type' bug).
> >
> 
> As I allways said: Bug was introduced round 1.1.29.
> Btw. I have tested the 1.0.0 drivers and I can definitely say that this
> problem is NOT solved with that driver !!
> 
> hw_sections=1 may work, but then I have frequent restarts and frequently
> destroyed colers of my OSD.
> 
> Again, the most ridicular thing is that this problem disapperas as soon
> as using sc-0.1.9 (even without keys, so that this plugin is only running,
> but not used)
> 
> This is a never ending story and I think we will never find a good solution.
> Maybe that bug disappers like it came. *hope*

Following is a copy of what I posted on 2003-07-27, 11:12.
Strangely this message is not listed in the archive at linuxtv.org,
but it _is_ contained in the VDR ML mirror at news://ltv.boerde.de/boerde.lists.vdr.
So maybe for some reason you didn't receive that messages.

------------ reposted message -----------------------
Klaus Schmidinger wrote:
> 
> Tilo Renkl wrote:
> >
> > Hi Jörg,
> >
> > first I thougt this is a driver problem too, but then I did a few
> > tests. I ALWAYS used the same driver and can reproduce that up to
> > VDR 1.1.28 everything was just fine and beginning with VDR 1.1.30
> > that bug was introduced. And it does NOT depend on how much Cards
> > you have installed. And it is not relevant what driver you use !!!
> 
> That's interesting - I'll take another close look at what has changed
> between VDR 1.1.28 and 1.1.30.
> 
> Just one question: is there a reason why you left out 1.1.29 in your tests?
> The closer we can narrow this down, the better...

From all the changes in versions 1.1.29 and 1.1.30 the only ones that
I could think of cuaing the effects you report are these:

2003-04-27: Version 1.1.29

- The PCR PID can now be set separately from the video PID. The syntax in the
  'channels.conf' file is, for example, ...:164+17:..., where 164 is the video PID
  and 17 is the PCR PID. The separator is a '+' sign, not a comma or semicolon as
  with the audio PIDs, because this is not an alternate PID, but rather an
  additional, necessary PID. In order to use this feature you need a driver version
  dated 2003-04-27 or higher (setting the PCR PID didn't work in earlier versions).
- Now setting the "broken link" flag for GOPs at the beginning of a new video
  sequence, which avoids artefacts when cutting (thanks to Stefan Huelswitt).
- Fixed faulty calculation of section length in eit.c (thanks to Teemu Rantanen).

2003-05-04: Version 1.1.30

- Fixed setting the PCR-PID in case it is equal to one of the other PIDs (thanks
  to Oliver Endriss for reporting this one).


(See VDR/HISTORY for the rest of the changes, but I believe these are the only
ones that even have a chance to be causing the problems).

Since the majority of these are in version 1.1.29, it might be a good idea if you
explicitly did a test with that version, just to be sure.

Once you have 100% established that version 1.1.28 _really_ works and version 1.1.29
(or 1.1.30) doesn't, you should step by step introduce the changes from the faulty
version into version 1.1.28, to see which change actually introduced the problem.

Sorry that I can't help with doing tests of my own, but I don't have this problem
here with the latest VDR version (as a matter of fact I didn't have it with any
version - maybe it is hardware dependent).

Oh, one more thing: as always, please do all tests with plain vanilla VDR.

Klaus


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.