On Sun, Oct 3, 2010 at 2:10 PM, VDR User user.vdr@gmail.com wrote:

On Sun, Oct 3, 2010 at 12:23 PM, Luca Olivetti luca@ventoso.org wrote:

...

Hello,

this has been bugging me for a while, but since it happens on channels I don't usually watch, I didn't ask before. There are some channels that are completely unwatchable: even with a perfect signal (at least according to femon) I can only see blocking artefacts and chirping sound.

That sounds like the symptoms of a bad signal.  Are you sure the driver you're using is reporting the correct statistics to femon? Several drivers don't.

Forgot to mention that a dying lnb can cause that also.

On Sun, Oct 3, 2010 at 3:06 PM, Luca Olivetti luca@ventoso.org wrote:

Yes, it seems like a bad signal, but femon is reporting a ber and unc of 0 (I really don't trust snr and strength, but ber and unc should be just about right).

The point I was trying to make is that you can't rely on femon to give you accurate statistics unless the dvb driver provides accurate statistics, which very many don't. Try plugging an analog signal meter into that cable and you'll likely see a different result then what you see in femon.

On 04.10.2010 00:36, Luca Olivetti wrote:

Al 04/10/10 00:20, En/na VDR User ha escrit:

...

On Sun, Oct 3, 2010 at 3:06 PM, Luca Olivettiluca@ventoso.org wrote:

...

Yes, it seems like a bad signal, but femon is reporting a ber and unc of 0 (I really don't trust snr and strength, but ber and unc should be just about right).

The point I was trying to make is that you can't rely on femon to give you accurate statistics unless the dvb driver provides accurate statistics, which very many don't. Try plugging an analog signal meter into that cable and you'll likely see a different result then what you see in femon.

Well, I'm pretty sure the ber and the unc are right: I tried to stream those channels with dvbstream and they play perfectly, so the signal is ok.

hi,

to see if unc and ber are working you should provoke those errors by weakening the signal and only if you see a change you know that it is working, if you allway see a 0 you can'n be shure if its working the way you expect it imho there is no difference in femon between is not provided by driver and 0

Al 04/10/10 19:36, En/na Luca Olivetti ha escrit:

Now I tried with a clean vdr (1.7.16), no patches (though my patches didn't modify the signal path at all), only the vdr-xine plugin and the problem is still there. BTW, the same xine I'm using with the plugin, has no problem playing the stream from dvbstream.

If I start a recording and try to play the ts file with, say, mplayer, it has the same problems, with a lot of messages in the console:

mpeg2video @ 0x8902640]ac-tex damaged at 10 1 [mpeg2video @ 0x8902640]skipped MB in I frame at 28 6

[mpeg2video @ 0x8902640]ac-tex damaged at 10 9

[mpeg2video @ 0x8902640]ac-tex damaged at 23 17

[mpeg2video @ 0x8902640]ac-tex damaged at 24 18

[mpeg2video @ 0x8902640]Warning MVs not available

[mpeg2video @ 0x8902640]concealing 220 DC, 220 AC, 220 MV errors

[mpeg2video @ 0x8902640]concealing 220 DC, 220 AC, 220 MV errors

[mpeg2video @ 0x8902640]concealing 220 DC, 220 AC, 220 MV errors

[mpeg2video @ 0x8902640]mb incr damaged

[mpeg2video @ 0x8902640]ac-tex damaged at 0 32

[mpeg2video @ 0x8902640]mb incr damaged

[mpeg2video @ 0x8902640]invalid cbp at 23 4

[mpeg2video @ 0x8902640]ac-tex damaged at 10 5

[mpeg2video @ 0x8902640]slice mismatch

[mpeg2video @ 0x8902640]ac-tex damaged at 17 7

[mpeg2video @ 0x8902640]invalid mb type in P Frame at 4 9

[mpeg2video @ 0x8902640]slice mismatch

[mpeg2video @ 0x8902640]ac-tex damaged at 24 11

[mpeg2video @ 0x8902640]invalid cbp at 16 12

[mpeg2video @ 0x8902640]slice mismatch

[mpeg2video @ 0x8902640]ac-tex damaged at 9 14

[mpeg2video @ 0x8902640]ac-tex damaged at 9 15

[mpeg2video @ 0x8902640]ac-tex damaged at 4 16

[mpeg2video @ 0x8902640]mb incr damaged

[mpeg2video @ 0x8902640]ac-tex damaged at 16 18

[mpeg2video @ 0x8902640]ac-tex damaged at 9 19

[mpeg2video @ 0x8902640]mb incr damaged

[mpeg2video @ 0x8902640]ac-tex damaged at 4 21

[mpeg2video @ 0x8902640]ac-tex damaged at 16 22

[mpeg2video @ 0x8902640]slice mismatch

[mpeg2video @ 0x8902640]invalid mb type in P Frame at 7 24

[mpeg2video @ 0x8902640]invalid mb type in P Frame at 3 25

[mpeg2video @ 0x8902640]mb incr damaged

[mpeg2video @ 0x8902640]mb incr damaged

[mpeg2video @ 0x8902640]invalid cbp at 16 28

[mpeg2video @ 0x8902640]ac-tex damaged at 28 29

[mpeg2video @ 0x8902640]invalid mb type in P Frame at 13 30

[mpeg2video @ 0x8902640]ac-tex damaged at 12 31

[mpeg2video @ 0x8902640]slice mismatch

[mpeg2video @ 0x8902640]invalid cbp at 24 33

[mpeg2video @ 0x8902640]ac-tex damaged at 37 34

[mpeg2video @ 0x8902640]invalid cbp at 3 35

[mpeg2video @ 0x8902640]Warning MVs not available

etc.

Bye

Al 04/10/10 20:55, En/na Luca Olivetti ha escrit:

Al 04/10/10 20:10, En/na Luca Olivetti ha escrit:

...

Al 04/10/10 19:36, En/na Luca Olivetti ha escrit:

...

Now I tried with a clean vdr (1.7.16), no patches (though my patches didn't modify the signal path at all), only the vdr-xine plugin and the problem is still there. BTW, the same xine I'm using with the plugin, has no problem playing the stream from dvbstream.

If I start a recording and try to play the ts file with, say, mplayer, it has the same problems, with a lot of messages in the console:

FWIW, if I set the audio pid to 0, the video is perfect.

With all output plugins (vdr-xine, dxr3 and streamdev, the latter only if NOT streaming in TS, which pulls the audio anyway and breaks the picture).

Bye.

On Mon, Oct 4, 2010 at 12:41 PM, Reinhard Nissl rnissl@gmx.de wrote:

Please have a look at http://sourceforge.net/mailarchive/forum.php?thread_name=4C93BD03.80702%40gm... and try changing buffer sizes. Just a guess.

I was wondering about those buffers. Is there any reason they can't be dynamic and adjusted on-the-fly to suit the needs of the stream? It seems a lot of people have problems with the "correct" settings and automating would resolve the problem once and for all if it's feasible to do so.

Al 04/10/10 22:21, En/na Luca Olivetti ha escrit:

Besides, the same xine with the same configuration had no problem playing the stream from dvbstream, and the fact that all output plugins are doing the same points to a lower level problem. The dxr3 plugin still uses pes video, so I first suspected cTsToPes, but the recording test made me think of something else.

I took a look at the log and I see a lot of TS continuity errors:

Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] receiver on device 1 thread started (pid=8337, tid=8404) Oct 4 22:30:21 vdr.ventoso.local vdr: [8405] TS buffer on device 1 thread started (pid=8337, tid=8405) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (1) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (12) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (3) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (13) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (0) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (3) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (7) .... Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (8) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (15) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] cVideoRepacker: switching to MPEG1/2 mode Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] cVideoRepacker: operating in MPEG1/2 mode Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (1) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (5) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] PES packet shortened to 798 bytes (expected: 1166 bytes) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] cAudioRepacker(0xC0): skipped 104 bytes to sync on next audio frame Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (11) Oct 4 22:30:21 vdr.ventoso.local vdr: [8404] TS continuity error (4) ..... Oct 4 22:30:22 vdr.ventoso.local vdr: [8404] TS continuity error (6) Oct 4 22:30:22 vdr.ventoso.local vdr: [8404] PES packet shortened to 1104 bytes (expected: 1166 bytes) Oct 4 22:30:22 vdr.ventoso.local vdr: [8404] TS continuity error (12) .....Oct 4 22:30:22 vdr.ventoso.local vdr: [8404] TS continuity error (9) Oct 4 22:30:22 vdr.ventoso.local vdr: [8404] PES packet shortened to 982 bytes (expected: 1166 bytes) Oct 4 22:30:22 vdr.ventoso.local vdr: [8404] TS continuity error (15)

As soon as I set the audio pid to 0 there are no errors at all.

I also don't get those messages with the dxr3 plugin, but it gets confused by spurious and continuous audio parameters change:

Oct 4 22:36:51 vdr.ventoso.local vdr: [8412] dxr3: audiodecoder: sample rate=44100 Oct 4 22:36:51 vdr.ventoso.local vdr: [8412] dxr3: audiodecoder: unexpected parameter change Oct 4 22:36:51 vdr.ventoso.local vdr: [8412] dxr3: audiodecoder: skipping 288 broken data bytes Oct 4 22:36:51 vdr.ventoso.local vdr: [8412] dxr3: audiodecoder: sample rate=48000 Oct 4 22:36:51 vdr.ventoso.local vdr: [8412] dxr3: audiodecoder: channels=1

Bye

On 04.10.2010 21:07, Luca Olivetti wrote:

Al 04/10/10 20:55, En/na Luca Olivetti ha escrit:

...

Al 04/10/10 20:10, En/na Luca Olivetti ha escrit:

...

Al 04/10/10 19:36, En/na Luca Olivetti ha escrit:

...

Now I tried with a clean vdr (1.7.16), no patches (though my patches didn't modify the signal path at all), only the vdr-xine plugin and the problem is still there. BTW, the same xine I'm using with the plugin, has no problem playing the stream from dvbstream.

If I start a recording and try to play the ts file with, say, mplayer, it has the same problems, with a lot of messages in the console:

FWIW, if I set the audio pid to 0, the video is perfect.

With all output plugins (vdr-xine, dxr3 and streamdev, the latter only if NOT streaming in TS, which pulls the audio anyway and breaks the picture).

hi,

TVN Warszawa;TVN:11508:VC56M2O0S0:S13.0E:27500:512=2:650=pol@4:572:0:15801:318:1600:0 TVP Kultura;CYFRA +:11488:HC56M2O0S0:S13.0E:27500:172=2:128=pol@4:513:0:5113:318:1500:0 PULS;CYFRA +:11488:HC56M2O0S0:S13.0E:27500:171=2:124=pol@4:0:0:5112:318:1500:0 TRACE TV;CYFRA +:11488:HC56M2O0S0:S13.0E:27500:164=2:96=eng@4,97=fra@4:0:0:5105:318:1500:0 (in fact all polish channels on this transponder do the same) RTV;Harmonic:11471:VM2O0S0:S13.0E:27500:611=2:612=@3:0:0:10622:318:1400:0

with vdr 1.7.16 and reelbox plugin (eHD) this channels are ok in live tv (even with some BER with my dish, Warszawa seemed to be weaker, i also got UNC's there but no real problems, only a small picture distortion some times)

...

with vdr 1.7.16 and reelbox plugin (eHD) this channels are ok in live tv (even with some BER with my dish, Warszawa seemed to be weaker, i also got UNC's there but no real problems, only a small picture distortion some times)

And Reinhard also sees them ok with vdr-xine, while I still have problems both with vdr-xine and the dxr3 :-/

I have used to have problems for watching some "pretty weak signal" DVB-T channels also which seemed always lost the log after 5 minute usage, until vdr killed and restarted itself. The problem went away for me after I changed from the vdr settings the EPG scan mode to "newer" or something like that. (I am not near to my vdr at the moment, so I can not check the exact location and text for this menu in the vdr.)

Can you test, whether the same thing could help also you?

I am running 2 card system - hauppauge hvr-1300 dvb-t connected - hauppauge hvr-4000 dvb-s connected dvb-t not connected because vdr does not support using both the dvb-s and t from the hvr-4000.

Mika

Al 04/10/10 21:07, En/na Luca Olivetti ha escrit:

Al 04/10/10 20:55, En/na Luca Olivetti ha escrit:

...

Al 04/10/10 20:10, En/na Luca Olivetti ha escrit:

...

Al 04/10/10 19:36, En/na Luca Olivetti ha escrit:

...

Now I tried with a clean vdr (1.7.16), no patches (though my patches didn't modify the signal path at all), only the vdr-xine plugin and the problem is still there. BTW, the same xine I'm using with the plugin, has no problem playing the stream from dvbstream.

If I start a recording and try to play the ts file with, say, mplayer, it has the same problems, with a lot of messages in the console:

FWIW, if I set the audio pid to 0, the video is perfect.

With all output plugins (vdr-xine, dxr3 and streamdev, the latter only if NOT streaming in TS, which pulls the audio anyway and breaks the picture).

The reverse is also true: if I set the video pid to 0, the audio is fine. Any hint on how to debug this?

Bye

Al 05/10/10 20:49, En/na Reinhard Nissl ha escrit:

...

...

...

FWIW, if I set the audio pid to 0, the video is perfect.

With all output plugins (vdr-xine, dxr3 and streamdev, the latter only if NOT streaming in TS, which pulls the audio anyway and breaks the picture).

The reverse is also true: if I set the video pid to 0, the audio is fine. Any hint on how to debug this?

Do you use this patch with vdr-xine?

http://www.mail-archive.com/vdr@linuxtv.org/msg11991.html

Yes.

Bye

Al 05/10/10 21:27, En/na Reinhard Nissl ha escrit:

Hi,

Am 05.10.2010 21:00, schrieb Luca Olivetti:

...

Al 05/10/10 20:49, En/na Reinhard Nissl ha escrit:

...

...

...

...

FWIW, if I set the audio pid to 0, the video is perfect.

With all output plugins (vdr-xine, dxr3 and streamdev, the latter only if NOT streaming in TS, which pulls the audio anyway and breaks the picture).

The reverse is also true: if I set the video pid to 0, the audio is fine. Any hint on how to debug this?

Do you use this patch with vdr-xine?

http://www.mail-archive.com/vdr@linuxtv.org/msg11991.html

Yes.

Does this happen with 1.7.15 too? I'm still at 1.7.15 -- didn't find time to update yet.

Yes, I just tried 1.7.16 to see if if was automagically solved. I also tried with vdr-1.7.9 (a random version I used since I had the tarball around) and it does the same.

Bye

which DVB card and which driver version do you use? I also had those problems with an old skystar 2. Nr of pid filters was too low and datarate of the stream was to high to transport it completely I was told.

Later I bought a TT s2-3200 and problems were gone on these transponder but there were new transponders in dvb-s2 on Thor 1°W SR 30000 8psk which showed the same problem which noone was able to fix. By chance several month later Andreas Regel increased the size of the ringbuffer for my card and problems are gone with s2-liplianin driver.

kind regards

Newsy

--- Luca Olivetti luca@ventoso.org schrieb am Di, 5.10.2010:

Von: Luca Olivetti luca@ventoso.org Betreff: Re: [vdr] Unwatchable channels (vdr-xine, dxr3, vlc, mplayer) An: "VDR Mailing List" vdr@linuxtv.org Datum: Dienstag, 5. Oktober, 2010 22:41 Uhr Al 05/10/10 21:50, En/na Luca Olivetti ha escrit:

...

...

Does this happen with 1.7.15 too? I'm still at

1.7.15 -- didn't

...

...

find time to update yet.

Yes, I just tried 1.7.16 to see if if was

automagically solved.

...

I also tried with vdr-1.7.9 (a random version I used

since I had the

...

tarball around) and it does the same.

I tried vdr 1.6.0 and it does the same *but* setting the video pid and/or the audio pids to 0 doesn't seem to fix it.

Bye -- Luca

---

vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

En/na Luca Olivetti ha escrit:

En/na Newsy Paper ha escrit:

...

which DVB card and which driver version do you use? I also had those problems with an old skystar 2. Nr of pid filters was too low and datarate of the stream was to high to transport it completely I was told.

The card is indeed a skystar 2, but these are fairly low bitrate channels, and dvbstream has no problem with them (hence excluding an issue with the card or the signal). It's true that dvbstream is only streaming the audio and video pids, while vdr is also using filters for eit/pmt/sdt, but I don't really think that's a problem, otherwise I'd see it with other, more demanding, channels, that actually work fine. I have no problem with various hd channels and also have no problem recording/watching several channels at once (on the same transponder), so that also should exclude a problem with the available amount of pid filters.

Ah, I see, you refer to the global bandwidth of the transponder and that it could exceed the capacity of the skystar2 if more than 6 pid filters are needed and it switches to full ts streaming. That could indeed be the case, I'll check when I'm at home.

Bye