9 replies to this topic

[bluewing]

I use zapstream with VLC to watch live tv, and it occasionally stops for 2-3 secs then resumes. I have a DM600s box, and on the PC side there is a Marvell Yukon Gigabit Ethernet controller. Windows Vista shows that the connection is 100Mbps. Please take a look at the attached zapstream.log file. I have noticed that in evey read sample it says todo=1KB, but the "todo" for written bytes varies. I'm thinking about increasing the so_sndbuf parameter, but I don't know how to find out the ideal value. Also in the config file it says "on dm500 higher values gives more pixelation, other boxes may benefit". Although my box is DM600, I'm concerned about this, I don't understand how increasing the socket send buffer size could result in pixelation.

Attached Files

•  zapstream_1.log   50.38KB   8 downloads

[Sjaaky]

The correlation between so_sndbuf and pixelation is an observation on my dm500. It will probably have to do with the kernel spending too much time at once sending packets over the network that it 'forgets' about reading the demux.

The DM600 has a better network driver than the DM500. You can try to increase so_sndbuf until you get pixelation. Multiples of 2 are preferred , start with the smallest values (4096, 8192, 16384, 32768).

I don't know why it stops, the logfile doesn't shows signs of it. There should be "buffer overflow" messages when you get hickups. When you don't get those in zapstream.log and only get 'skipping late picture' in the vlc messagewindow, you can try giving vlc a higher priority.

I guess the 'read ... todo=1KB' is a bit artificial, don't know why it doesn't work that well. The 'write ... todo' does work I assume . When it doesn't reach the buffersize everything is fine.

[bluewing]

I increased so_sndbuf to 8192, but no change. I don't have any "buffer overflow" messages in zapstream.log so this might not be the problem of stopping. Although there are some strange things going on in the VLC messages window:

main warning: output date isn't PTS date, requesting resampling (49379)
main warning: buffer is 49379 late, triggering upsampling
main warning: resampling stopped after 10670000 usec (drift: 205)
main warning: output date isn't PTS date, requesting resampling (-41000)
main warning: buffer is 41038 in advance, triggering downsampling
main warning: resampling stopped after 9766000 usec (drift: -649)

but this doesn't cause a stop. When it stops, I see these messages:

ts warning: invalid header [0x41:70:46:b] (pid: 328)
ts warning: invalid header [0xa:8d:25:c4] (pid: 328)
ts warning: invalid header [0x84:cf:37:67] (pid: 228)
mpeg_audio debug: emulated startcode (no startcode on following frame)
ts warning: invalid header [0xe0:34:43:5a] (pid: 328)
ts warning: invalid header [0x11:2:61:39] (pid: 328)
ts warning: invalid header [0xfc:5a:d1:92] (pid: 228)
ts warning: invalid header [0x55:71:d7:a4] (pid: 328)
ts warning: invalid header [0xa5:1a:2a:13] (pid: 228)
ts warning: invalid header [0x7e:98:ae:a4] (pid: 328)
ts warning: invalid header [0x22:ff:85:61] (pid: 328)
ts warning: invalid header [0x55:af:5b:c6] (pid: 328)
ts warning: invalid header [0x69:ab:5b:4] (pid: 228)
ts warning: invalid header [0x1c:29:e3:17] (pid: 328)
... lots of it repeating ...
main warning: backward_pts != dts (13320000)
main warning: backward_pts != current_pts (-80000)
main warning: backward_pts != current_pts (-13320000)
main warning: late picture skipped (12101656)
main warning: late picture skipped (11981656)
main warning: computed PTS is out of range (12573251), clearing out
main warning: output PTS is out of range (12609688), clearing out
main debug: audio output is starving (383621), playing silence

So it seems that VLC gets some invalid headers, I have no idea why. If you can help me pinpoint the source of this problem I will do some testing tomorrow. Thanks for your help.

[Sjaaky]

The invalid header usually means your stream is not being decrypted.
Do you notice the stops on tv too? With zapstream streaming to your pc? Without zapstream streaming to your pc?

[bluewing]

I use CCcam 2.0.5 with my NDS card. On 'TV' (usb tv tuner) there are no stops, but I notice a few bad frames. If I use zapstream at the same time, then tv stops also. Maybe I should look in the CCcam log, but I don't know how to do that. Is it possible to have CCcam writing logs to a file or only through the serial port?

[dAF2000]

Is it possible to have CCcam writing logs to a file or only through the serial port?

Yes, first manually stop CCcam: "killall CCcam". Then start it with debugging "CCcam -d" and you will see all the debugging in the telnet window.

[Sjaaky]

From what I heard NDS decoding is quite heavy. Probably the zapstream takes away processing power so CCcam can't do its work. Modify the next setting:

streamingpriority=0

[bluewing]

zapstream does not seem to need that much processing power. I ran top in a separate session and I saw zapstream using between 7% and 15% CPU, CCcam using 1.5% or even less. I ran CCcam -dv in the other session it was fine, no errors. To rule out CCcam, I killed it and watched a FTA channel. There were no 'invalid header' messages this time, but rather strange error messages:

ts warning: lost synchro
ts debug: skipping 16 bytes of garbage
ts warning: discontinuity received 0x3 instead of 0xe (pid=848)
ts warning: discontinuity received 0x3 instead of 0x9 (pid=849)
mpeg_audio debug: emulated startcode (no startcode on following frame)

I have attached the full messages output in a file.

Attached Files

•  messages.log   7.98KB   0 downloads

[Sjaaky]

I know, it happens from time to time. I don't know whether it is a real error in zapstream or caused by something else. The latter can be ruled out if someone with a dm70x0 experiences the same discontinuities with zapstream and doesn't experience them using streamts.

[bluewing]

Hmm very strange problem. I have received the bill recently from my provider, and I know that they also send some kind of mail at the same time. Directly to the receiver. When I was using their receiver I was able to read it. No idea how that works, it obviously isn't POP3. Since I use the dreambox, I'm missing those mails. I can do without them, but I was wondering if they send some extra data mixed into the stream? The original receiver is a Coship CDVB5668, it's a proprietary bull****, one can not find any relevant info about it on the net:( Unfortunately I can't ask my provider about how they are sending those mails, they don't support other receivers, furthermore sustain that it is not possible to even use something other than that Coship.