[Tuxwork]

from which this fault ?
VNSI plugin ?
iptv plugin ?
or VDR(2.0.2) ?

vdr-plugin-vnsiserver/demuxer.c (line: 527)

Code:

#if APIVERSNUM >= 10715
      if (channel->Atype(index) == 0x0F)
        newStream.type = stAACADTS;
      else if (channel->Atype(index) == 0x11)
        newStream.type = stAACLATM;
#endif

the prblem is not from here ?

Code:

cat vdr-2.0.2/include/vdr/config.h  |grep -i VDRVERSION
#define VDRVERSION  "2.0.2"

Thanks.

[FernetMenta]

The pat/pmt of the recording was correct. I don't know if the iptv plugin changes this or the source of the stream is wrong.
Nevertheless here is a fix/work-around: https://github.com/FernetMenta/xbmc-pvr-...ca06dfed8e

[Tuxwork]

Yes is work after i aply the patch

VDR debug log:

Code:

vdr: [719] VNSI: Client with ID 1 connected: 127.0.0.1:59432
vdr: [949] VNSI: Welcome client 'XBMC Media Center' with protocol version '5'
vdr: [949] VNSI: LiveStreamer::Close - close
tvheadend[647]: IPTV: Starting RTSP Streaming with rtsp://mafreebox.freebox.fr/fbxtv_pub/stream?namespace=1&service=211&flavour=ld
tvheadend[647]: subscription: "HTTP" subscribing on "AB 1", weight: 100, adapter: "rtsp://mafreebox.freebox.fr/fbxtv_pub/stream?namespace=1&service=211&flavour=ld", network: "<N/A>", mux: "::", provider: "<N/A>", service: "<N/A>", qual
vdr: [952] receiver on device 9 thread started (pid=678, tid=952, prio=high)
vdr: [949] VNSI: Successfully switched to channel 16 - AB1
vdr: [949] VNSI: Started streaming of channel AB1 (timeout 10 seconds)
vdr: [954] cLiveStreamer stream processor thread started (pid=678, tid=954, prio=high)
vdr: [955] IPTV streamer thread started (pid=678, tid=955, prio=high)
vdr: [719] VNSI: Recordings state changed (165)
vdr: [719] VNSI: Requesting clients to reload recordings list
vdr: [712] VNSI: Video Input - new pmt, attaching receiver
vdr: [954] VNSI: Created stream for pid=217 and type=8
vdr: [954] VNSI: Created stream for pid=317 and type=5
vdr: [954] VNSI: cParserAAC::FindHeaders - detected ADTS muxing mode
kernel: crystalhd 0000:02:00.0: Opening new user[0] handle
kernel: start_capture: pause_th:14, resume_th:3

(with crystalhd enabled or disabled) the video not work smoothly like mpeg channels
unlike (XBMC) vtp or VLC, that works very well. (over streamdev server)
XBMC DEBUG VNSI playing AB1 : http://xbmclogs.com/show.php?id=105204

Thanks.

[FernetMenta]

Please elaborate on "smooth", audio drop-outs?
The log looks ok, please post a full debug log after having played this channel for 3-4 minutes.

[Tuxwork]

3 minutes of DEBUG log crystalhd disabled:
http://xbmclogs.com/show.php?id=105287

4 minutes of DEBUG log crystalhd enabled:
http://xbmclogs.com/show.php?id=105290

this is SD channel, is should work fine without hardware decoder. (like vtp)
for info, when i try to play using vtp, i disable crystalhd. otherwise is play choppy

[Tuxwork]

screen playback crystalhd disabled (cpu and fps... usage)
http://www.youtube.com/watch?v=ty8dGWSZnkM

[FernetMenta]

I played your sample through vnsi with sw decoding: http://xbmclogs.com/show.php?id=105314

It played smooth with clean timestamps and no stuttering:
CPullupCorrection: detected pattern of length 1: 20000.00,

[Tuxwork]

I played your sample through vnsi with sw decoding
It played smooth with clean timestamps and no stuttering:

Yeah sure. like here, i played recording (from same channel through VNSI) and work like silk!

I don't think is hardware (cpu...) problem. because 1080 HD channels (with dolby 2.0 sound) play very smoothly than this channels. (with crystalHD enabled)

Is it possible to add trace lines in the source code to find where coming this bug ?

I am ready to do any to fix this bug

[FernetMenta]

Yeah sure. like here, i played recording (from same channel through VNSI) and work like silk!

I think this is a misunderstanding. I played your sample through vnsi test harness which results in virtually the same as a live stream.

I am confused, what exactly do we chase here? A Chrystal HD issue when playing those channels?

[Tuxwork]

I am confused, what exactly do we chase here? A Chrystal HD issue when playing those channels?

no, is not ChrystalHD related. because the HD 1080 live channels (through VNSI) work fine.
and playing recording from those channels (h264/AAC DTS) through VNSI work fine too.

The problem is only when (VNSI) Live playing from those channels (h264/AAC DTS).
there to there a way to debug/discover where it's coming ?

please note, Live playing those channels through vtp://127.0.0.1:2004/... work fine.

Thanks

[FernetMenta]

Please post a FULL debug log for (and FULL is important, not truncated)

1)
Live playing those channels through vtp://127.0.0.1:2004/

2)
same channel live via vnsi

[Tuxwork]

1) vtp DEBUG log (The video and audio work fine)
http://xbmclogs.com/show.php?id=105859
vtp vdr messages: http://pastebin.com/raw.php?i=8Mxjmkyc

2) same channel live via VNSI (audio OK, playing video not smooth)
http://xbmclogs.com/show.php?id=105863
VNSI vdr messages: http://pastebin.com/raw.php?i=yrMBwV62

3) playing recording via VNSI (h264/AAC DTS) (The video and audio work fine)
http://xbmclogs.com/show.php?id=105869
recorded vdr file : https://drive.google.com/file/d/0B40c_0M...GNEa1R3ZlE

[FernetMenta]

what exactly don't you understand of the term: FULL DEBUG LOG, NOT TRUNCATED?

[FernetMenta]

what deinterlacing settings do you have for the various sources? (those are stored per channel / file)

[Tuxwork]

deinterlacing = off --> in all channels