[jspudich]

Hi,

I use OpenElec as a front-end and DVR as a back-end to receive and play DVB-S channels from the position S23E5. VNSI is used to integrate XBMC and VDR. I receive 36 channels of which some are FTA and some are not. Most of the channels work fine but two channels do not play in XBMC as they should. I checked threads in this forum but I could not find a solution of the problem so I am opening this thread hoping to find someone who can help resolving it.

Symptoms of the problem:
when switching over to some channels, XBMC shows a static (not moving) picture from that channel, produces few seconds of stuttering sound and starts reporting “VNSI: no signal”. While trying to investigate the problem, the following has been further observed:

• these 2 problematic channels can be recorded and played back afterwards without any problem
  
• when using the streamdev VDR plugin, these 2 problematic channels play only when using Packetized elementary stream. When using Elementary stream, the channel playback (which seems to be flawles) stops after 2-10 seconds.
  

Configuration
OpenElec: 2.99.2 (3.0 RC 2)
XBMC: 12.0-RC3 git aea93c3 (compiled on 25-Jan-2013)
VNSI XBMC addon: 1.6.4
VDR: 1.7.31
VNSI VDR plugin: 0.9.1 git clone https://github.com/opdenkamp/xbmc-pvr-addons.git (14-Feb-2013)

Logs
The two logs provided below reflect a scenario in which a working channel was selected (referred to as “CT2” in the log) and then a problematic channel was selected (referred to as “Nova Cinema” in the log)

• Syslog from the DVR machine
  
• XBMC log
  

Can anybody suggest a solution for the problem described above?

Cheers,
Jan

[FernetMenta]

Might be fixed by the redesigned version which is now in master:
https://github.com/opdenkamp/xbmc-pvr-addons/issues/160

[jspudich]

FernetMenta, thank you for reply as well as for integrating VDR and XBMC.

I compiled the VNSI plugin for VDR both from the opdenkamp repository master branch as well as from the FernetMenta repository vnsi branch. Unfortunately, in both cases the problem described in my initial post of this thread remains the same.

BTW, those problematic channels are not HD. HD channels work fine.

[FernetMenta]

Please post syslog with loglevel 3. A short recording of one of those channels would be great also.

[jspudich]

Here is a syslog with VDR loglevel 3 (defined using the vdr command line option -l). It reflects a scenario in which a working channel was selected (referred to as “CT2” in the log) and then a problematic channel was selected (referred to as “Nova Cinema” in the log).

I have also recorded few minutes of one of those two channels. The resulting recording (66MB in size) is available for download at uschovna.cz.

[martin.haager]

problem sounds familiar to me...
also searching for a solution

using vdr as backend atv2-xbmc 12 as frontend, vnsi plugin

streaming via vdr streamdevpluging (frontend either web or vlc) using PS works fine
if i use TS i get picture and sound for about 2 seconds befor it stops.

channel not working: ORF III
other channels on same transponder are working without Problems using TS

[FernetMenta]

can you look for this code in videobuffer.c

Code:

cVideoBufferSimple::cVideoBufferSimple()
{
  m_Buffer = new cRingBufferLinear(MEGABYTE(3), TS_SIZE * 2, false);
  m_Buffer->SetTimeouts(0, 100);
  m_BytesConsumed = 0;
}

and change the size of the ringbuffer and timeout to:

Code:

cVideoBufferSimple::cVideoBufferSimple()
{
  m_Buffer = new cRingBufferLinear(MEGABYTE(8), TS_SIZE * 2, false);
  m_Buffer->SetTimeouts(0, 10);
  m_BytesConsumed = 0;
}

[jspudich]

Requested changes made in the opdenkamp master branch (as downloaded on 14-Feb-2013). Unfortunately, the problems described previously remain the same: the playback stops shortly after it starts and XBMC reports "VNSI client: no signal". I could not notice any change from the user's perspective (with respect to how the system was behaving before changing the two parameters) .

Here is also a new syslog which corresponds to switching multiple channels. Names of the problematic channels are "Nova Cinema" and "Fanda".

[FernetMenta]

At least the buffer overflow is gone. I will look into this in more detail the next days.

[FernetMenta]

short update. I have to create a test harness in order to feed your sample through the parsers. My old one does not work anymore for the new version.
The test harness is actually the last step for timeshift: playback of recordings which are still recording.

[jspudich]

Thank you for your update as well as for working on resolving the issue. If there is anything I can do in the meantime, please let me know.

[FernetMenta]

I just tried to download the recorded sample but the link does not work anymore.

[jspudich]

I uploaded the same sample (as I uploaded before) and it will be available for download until 9-Mar.

[FernetMenta]

The recording works when loading from file and feeding the live parsers. Now we have to check whether vnsi gets anything from the device.

Could you place some logs into cVideoBufferSimple::Read() and post a new log?

Like this:

Code:

int cVideoBufferSimple::Read(uint8_t **buf, unsigned int size)
{
  int  readBytes;
  if (m_BytesConsumed)
  {
    m_Buffer->Del(m_BytesConsumed);
  }
  m_BytesConsumed = 0;
  *buf = m_Buffer->Get(readBytes);
  if (!(*buf) || readBytes < TS_SIZE)
  {
    usleep(100);
    return 0;
  }
  /* Make sure we are looking at a TS packet */
  while (readBytes > TS_SIZE)
  {
    if ((*buf)[0] == TS_SYNC_BYTE && (*buf)[TS_SIZE] == TS_SYNC_BYTE)
      break;
    m_BytesConsumed++;
    (*buf)++;
    readBytes--;
    ERRORLOG("------------- marker 1");
  }

  if ((*buf)[0] != TS_SYNC_BYTE)
  {
    m_Buffer->Del(m_BytesConsumed);
    m_BytesConsumed = 0;
    ERRORLOG("------------- marker 2");
    return 0;
  }

  ERRORLOG("------------- marker 3");
  m_BytesConsumed += TS_SIZE;
  return TS_SIZE;
}

[jspudich]

ERRORLOG logging added. Here are two logs which I captured. For some reason, neither of them contains information about a try to switch to the channel a name of which is FANDA. It is the problemtic channel and I certainly switched to the channel while capturing the log.

1. Syslog 1
   
2. Syslog 2
   

Edit:
The absence of any information about switching to the problematic channels in the log looked strange to me. Therefore I commented out those three ERRORLOG statements introduced previously and now the log contains the information about the problematic channels.