[vdr] Re: VDR developer version 1.3.14

[Laz <laz@club-burniston.co.uk>]

On Tuesday 26 Oct 2004 17:53, Jouni Karvo wrote:
> hello,
>
> Laurence Abbott writes:
>  > Had a go last night and it seemed fine for a few hours for both live TV
>  > and recordings but then I lost live TV again, as I did with 1.3.13. This
>
> Me too.  The dvb-drivers are probably not a problem (rather new from
> CVS), but 1.3.14 has something weird on tuning that has not been there
> earlier (I had to go back to 1.3.13 since 1.3.14 did not work).

I'm also getting a lot of UPT errors now that I'm pretty sure I've never seen 
before with 1.3.12 and previous. I seem to get about two or three of them in 
quick succession. I also see quite a few "no GOP header" errors too:
.................
Oct 24 18:35:15 vdr vdr[8112]: SetBrokenLink: no GOP header found in video 
packet
Oct 24 18:35:17 vdr vdr[8112]: SetBrokenLink: no GOP header found in video 
packet
Oct 24 18:46:49 vdr vdr[8112]: ERROR: unknown picture type '7'
Oct 24 18:49:03 vdr vdr[8112]: ERROR: unknown picture type '6'
Oct 24 18:53:55 vdr vdr[8112]: ERROR: unknown picture type '4'
Oct 24 19:08:41 vdr vdr[8112]: ERROR: unknown picture type '6'
Oct 24 19:14:40 vdr vdr[8112]: channel 6 (ITV 2;ITV) event 19:15 'Ant And 
Dec's Saturday Night...' status 4
Oct 24 19:17:49 vdr vdr[8112]: ERROR: unknown picture type '7'
...............

Just been watching a recording from a few days back and a 2h program is split 
into about 45 files, presumably from restarting due to lots of UPT errors! I 
believe 10 now causes a restart. I don't have logs bag that far, 
unfortunately (just changed how many it keeps when they are rotated!).

> In addition to this problem where no TV is available after watching a
> recording, there was another problem: for some reason one mux (YLE)
> stopped working properly at some point: I could tune to one of the
> channels but another channel on the same mux did not work.

Can't remember whether I tried channels on another MUX or not but will do 
when / if I lose it again!

> I did not test properly, and as it is a "production system", I just
> reverted back to 1.3.13.  It might have been also problem in the
> transmission, anyway, but since you have similar problems I thought
> better to tell.

I'm still persevering to see if I can get any more info on this problem. 
Looking at my log from last night, after a timed recording had finished, the 
ring buffer kept filling up and cleared itself ca. 60 times! This was 
happening during shutdown! Not sure whether this was due to it losing its 
tuning as above or something else:

Oct 26 22:35:01 vdr vdr[6233]: next timer event at Wed Oct 27 02:03:00 2004
Oct 26 22:35:01 vdr vdr[6233]: confirm: Press any key to cancel shutdown
Oct 26 22:35:05 vdr vdr[6233]: buffer usage: 70% (tid=1250548656)
Oct 26 22:35:05 vdr vdr[6233]: buffer usage: 80% (tid=1250548656)
Oct 26 22:35:06 vdr vdr[6233]: buffer usage: 90% (tid=1250548656)
Oct 26 22:35:06 vdr vdr[6233]: buffer usage: 100% (tid=1250548656)
Oct 26 22:35:06 vdr vdr[6233]: ERROR: 1 ring buffer overflow (177 bytes 
dropped)
Oct 26 22:35:06 vdr vdr[6233]: clearing transfer buffer to avoid overflows
Oct 26 22:35:06 vdr vdr[6233]: buffer usage: 0% (tid=1250548656)
Oct 26 22:35:09 vdr vdr[6233]: buffer usage: 70% (tid=1250548656)
Oct 26 22:35:10 vdr vdr[6233]: buffer usage: 80% (tid=1250548656)
Oct 26 22:35:10 vdr vdr[6233]: buffer usage: 90% (tid=1250548656)
Oct 26 22:35:10 vdr vdr[6233]: buffer usage: 100% (tid=1250548656)
Oct 26 22:35:11 vdr vdr[6233]: clearing transfer buffer to avoid overflows
Oct 26 22:35:11 vdr vdr[6233]: buffer usage: 0% (tid=1250548656)
Oct 26 22:35:14 vdr vdr[6233]: buffer usage: 70% (tid=1250548656)
Oct 26 22:35:14 vdr vdr[6233]: buffer usage: 60% (tid=1250548656)
Oct 26 22:35:14 vdr vdr[6233]: buffer usage: 70% (tid=1250548656)
Oct 26 22:35:15 vdr vdr[6233]: buffer usage: 80% (tid=1250548656)
Oct 26 22:35:15 vdr vdr[6233]: buffer usage: 90% (tid=1250548656)
Oct 26 22:35:15 vdr vdr[6233]: clearing transfer buffer to avoid overflows

etc.!

@Klaus: any ideas on what I can check? Looking back at the mailing list, (Feb 
this year) you posted a patch which gave a 5 s delay in dvbdevice.c to wait 
for a lock but looking at the current version, this delay is there already!

Cheers,

Laz