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. I tried vdr-xine, the dxr3 or vlc/mplayer through streamdev, the result is always the same. Here are some of the channels where this is happening right now:
Mirabelle TV;EUTELSAT:10972:VC78M2O0S0:S5.0W:29950:1061=2:1062=@3:0:0:4134:1375:20600:0 Normandie TV;EUTELSAT:11096:VC78M2O0S0:S5.0W:29950:851=2:852=fra@3:0:0:405:1375:20400:0 TV8 MONT BLANC;EUTELSAT:11096:VC78M2O0S0:S5.0W:29950:881=2:882=fra@3,883=ita@3:0:0:408:1375:20400:0
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
and many more.
Any idea?
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.
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.
Al 03/10/10 23:10, En/na VDR User ha escrit:
On Sun, Oct 3, 2010 at 12:23 PM, Luca Olivettiluca@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.
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).
Bye
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.
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.
Bye
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 18:40, En/na Lars Bläser ha escrit:
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
Hey, I know the signal is ok: dvbstream streams those channels perfectly, no artefacts, no strange sound, no jumps, and that would be impossible if the signal were not good.
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.
Bye
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: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.
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.
Hi,
Am 04.10.2010 21:07, schrieb Luca Olivetti:
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).
Please have a look at http://sourceforge.net/mailarchive/forum.php?thread_name=4C93BD03.80702%40gm... and try changing buffer sizes. Just a guess.
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 21:41, En/na Reinhard Nissl ha escrit:
Hi,
Am 04.10.2010 21:07, schrieb Luca Olivetti:
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).
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 tried setting video buffers to 5000 and audio buffers to 500, but it didn't change anything. Unsurprising, since with the default settings I have no problem with HD and these channels are SD and at a fairly low bitrate. 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.
Bye
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
Al 04/10/10 22:38, En/na Luca Olivetti ha escrit:
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:
I see that those "TS continuity" messages are generated in vdr-xine...
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
..as those are generated in the dxr3. Somehow both of them (and streamdev too) are getting the data wrong.
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)
Al 04/10/10 22:35, En/na Lars Bläser ha escrit:
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 :-/
Bye
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 08/10/10 00:37, En/na Mika Laitio ha escrit:
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?
No need, I already determined that the problem is due to my skystar2: it only has 6 hw pid filters, and when userspace needs more it switches to full-ts streaming, however those transponders exceed the capacity of the skystar2.
Bye
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
Hi,
Am 05.10.2010 19:36, schrieb Luca Olivetti:
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?
Do you use this patch with vdr-xine?
http://www.mail-archive.com/vdr@linuxtv.org/msg11991.html
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?
Yes.
Bye
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?
Yes.
Does this happen with 1.7.15 too? I'm still at 1.7.15 -- didn't find time to update yet.
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?
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
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
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 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.
Bye
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
Al 06/10/10 10:11, En/na Luca Olivetti ha escrit:
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).
...
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.
That's it: I temporarily removed from device.c the extra filters and I can see those channels perfectly. Is there a workaround (apart from removing the eit/pat/nit scan or changing the card)?
Bye
Hi,
Am 03.10.2010 21:23, schrieb Luca Olivetti:
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. I tried vdr-xine, the dxr3 or vlc/mplayer through streamdev, the result is always the same. Here are some of the channels where this is happening right now:
Mirabelle TV;EUTELSAT:10972:VC78M2O0S0:S5.0W:29950:1061=2:1062=@3:0:0:4134:1375:20600:0
Normandie TV;EUTELSAT:11096:VC78M2O0S0:S5.0W:29950:851=2:852=fra@3:0:0:405:1375:20400:0
TV8 MONT BLANC;EUTELSAT:11096:VC78M2O0S0:S5.0W:29950:881=2:882=fra@3,883=ita@3:0:0:408:1375:20400:0
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
and many more.
Any idea?
I've just tried the mentioned S13.0E channels. They work flawlessly here.
Bye.
Al 03/10/10 23:46, En/na Reinhard Nissl ha escrit:
I've just tried the mentioned S13.0E channels. They work flawlessly here.
Thank you for checking. Any other idea? I have a dect base that affects others channels (e.g. arte on 13E at 11623V, it clearly shows in the ber), but it makes no change on these channels.
Bye
-
Lars Bläser -
Luca Olivetti -
Mika Laitio -
Newsy Paper -
Reinhard Nissl -
VDR User