Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] 'unknown picture type´' while in live-view



Am Dienstag, 9. September 2003 20:29 schrieben Sie:
> Hi
>
> as I had the mentioned error always only when a recording starts on my
> second device, i could live with a restart of vdr. But now i got the same
> error in live-mode. Scenario:
>
> - recording WDR on the first device
> - watching Pro7 in transfer mode
>
> I saw, that some frames where dropped while watching Pro7. But this was not
> so disturbing. Then I switched to RTL and I got block artefacts. Switching
> back to Pro7: block artefacts. Switching to the recording channel WDR:
> perfect picture. Every channel other than WDR have block artefacts.
>
> In my Syslog I got the bothersome error message "unknown picture type 6".
> But I got no Buffer overflow or something like that.
>
> I use plain vanilla VDR 1.2.5pre2 (no patches, no plugins), DVB from
> 08.09., Hauppauge DVB-S Rev. 1.3 as primary device, Nexus Rev. 2.1 as
> secondary device, Kernel 2.4.21, no IRQ-Sharing, no power-saving-settings
>
> I noticed, that most of the people with this error has a Rev 2.1 in their
> system. Perhaps the problem is there... Can the people on this ML confirm
> that?
>
> And before I forget it: sometimes the problem occurs when a new recording
> starts on secondary device. But then it is no problem to restart vdr and
> everything is ok. But when the problem occurs as described above ... :-(
>
> With VDR 1.2.26 I've never had that problem.
>
> Martin

Well, I think, that there are only some lonely guys, which had this problem. I 
have it too (see 
http://www.linuxtv.org/mailinglists/vdr/2003/09-2003/msg00099.html).
I don't think, it's a problem of the Nexus card (I have 2 Rev 1.3 Cards and 
the same problem) or with the (former working) hardware.

Maybe it's a problem with the transfer mode / dvb-driver. In my above posting 
I forced the error by doing 2 recordings and heavily channel zapping.

I think, the problem has the same cause as that with the recordings. Maybe we 
find some common things, if we look to our configuration and when the errors 
happen.

Here my configuration and "error-history" (I use 2 systems with same timers so 
I minimise the risk of losing something):

1-card system: 
- plain Suse 8.2 (kernel 2.4.20.Suse) , driver linux-dvb.2003-08-01, plain vdr 
1.2.5pre1, rev 1.6 card
- today recording (6 0957-1112 'Dr. Stefan Frank - Der Arzt, dem die Frauen 
vertrauen') on RTL ok (while switched on RTL2)
- today recording  (10 2011-2222 '24') on RTL2 lost with "unknown picture 
type" (this was the first time since 5 days I got this error and I didn't 
apply the EmergencyExit patch);


2-card system: 
- per online-update patched Suse 8.2 (kernel 2.4.20.Suse) , driver 
linux-dvb.2003-09-05, plain vdr 1.2.5pre2, only patched with the 
EmergencyExit routine if there are "unknown picture type" errors, two rev 1.3 
cards 
- today recording (6 0957-1112 'Dr. Stefan Frank - Der Arzt, dem die Frauen 
vertrauen') on RTL "ERROR: video data stream broken", after vdr-restart the 
recording works;
- today recording  (10 2011-2222 '24') on RTL2 "unknown picture type" errors 
after 1 minute; after vdr-restart the recording works;
- on this system, I had more "unknown picture type" errors with the driver 
from 2003-09-05 than with driver 2003-08-01
- on this system 90% of the "first" recordings of the day cause a vdr-restart 
because of "ERROR: video data stream broken" or "unknown picture type" errors 
(restart with patch). With the "first" recordings, I mean those who start 
after some time of inactivity (> 6 hours), maybe the epg-scan in background 
cause problems. I'll test tomorror's recordings with deactivated epg-scan


Harald



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



Home | Main Index | Thread Index