I use vdr-xine and I get stuttering and video freeze on mainly on one channel, the local NBC. Happens on others but not as much. video/audio goes into a stutter and you need to change channels to fix it. Even just reentering the same channel works. Other times the video will totally freeze with no audio and only a restarting vdr fixes it. Can't tell on that if it's a problem with xine or vdr. Kind of looks like a vdr problem as cpu usage drops for vdr while a xine crash which peaves me with a black screen with a prompt line in the upper left and a xorg "X" mouse pointer in the middle causes no change in vdr cpu and it continues to record shows, etc. Still needs a restart since my script restart vdr, xorg and xine at the same time.

On 1/21/2011 11:54 AM, Rob Davis wrote:

(Un?)fortunately, this issue doesn't occur in xineliboutput, as the source is actually HD Mpeg2 720p with AC3, but the issue I have is only with XBMC and vnsiserver. I am wondering if there's a clock set wrong on their ATSC muxer or something like that which xine and every set top box out there ignores, but XBMC looks at.

On 21/01/11 12:34, Timothy D. Lenz wrote:

...

There was a patch posted a day or two in the in the xine list that had to do with pts. From freenode #xine:

[11:43] <rnissl> in case of a video freeze, I assume you had a clock error [11:44] <rnissl> hotwings suffers them too for h264

[11:54] <hotwings> btw, you fixed the pts error rnissl. but when it occurs the video glitches/freezes briefly. however other players go smooth right through it (like coreavc+mpc in windows). i think thats due to bugs in the frame stuff though and not how the pts error is handled right? [11:54] <rnissl> yes, acutally, the pts error is just a pts wrap and shouldn't be handled like that. [11:55] <rnissl> my plans are to release a patch this week which makes the handling configureable [11:56] <rnissl> although I think that this kind of handling is not necessary or wrong, there may be situations where removing the code causes other trouble [11:57] <rnissl> so a config option should suit both interests

On 1/21/2011 8:58 AM, Rob Davis wrote:

...

Using VDR 1.7.16 and the vnsi plugin, xbmc seems to be struggling to play one particular channel. Unfortunetly, it's the channel I'm doing a temporary admin contract for, so I kind of need to see it. vdr-sxfe plays it OK, but I get too much video stuttering on it, and all other channels play ok on xbmc/vdr.

Working at the station, if the problem is there, I have a hope of getting it fixed. Their sister station using the same equipment but on a different frequency and antenna (transmitter) is fine.

I get the same symptoms using both OTA (8vsb) and via Comcast QAM256, so am fairly sure the problem is specific to something at the station.

The code from demuxer.c (in vnsi plugin) that's being triggered is this:

else if(checkTimestamp) { int d = dts + m_epochDTS - m_LastDTS;

if (d< 0 || d> 90000) {

if (d< -PTS_MASK || d> -PTS_MASK + 180000) { m_badDTS++;

if (m_badDTS< 5) { dsyslog("VNSI-Error: DTS discontinuity. DTS = %10lu, last = %10lu", dts, m_LastDTS); } } else { /* DTS wrapped, increase upper bits */ m_epochDTS += PTS_MASK + 1; m_badDTS = 0; } }

I get my logs filled with the VNSI-Error, DTS discontinuity. The audio stutters. It appears to be AC-3 Stereo, but may be labelled 5.1? I have audio passthrough to my amp. On another laptop with analog output it seems to stutter in a different way..

I'm fairly happy putting some kind of checking in VDR or VNSI and recompiling if it'll help. I have two ATSC tuners, it happens to both tuners.

Thanks Rob

---

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

---

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