Change the way of handling client/server connections.

[manio]

Hello Alex, I am now using your channelchange branch with the dvbapi plugin. All works well, but it seems there is need one another change in the xvdr.

Let's start from beginning: Your channelchange code is listening for a VDR's 'ChannelChange' event. Then it restart the stream properly.

I was contacting Klaus about the new CAM interface which I am using in my dvbapi plugin - and I had to change it to done properly. I am providing encrypted stream until it can be decoded. This way if the CAM from my plugin is unable to decrypt the stream, it is switched to another registered CAM, eg. the hardware CAM - and it allows decrypting a channel. So as a result of this change - the stream is crypted for some time. This in turn leads (in some circumstances, after fresh VDR start) that the channel is encrypted for more then 3 seconds. VDR has a check for this and it is detaching receivers:

device.c:
  if (Scrambled) {
    if (t > TS_SCRAMBLING_TIMEOUT)
      DetachReceivers = true;
  }

I was asking Klaus to increase this timeout, but he look at the XVDR code and replied that this should be done differently. I am quoting the email from him: Looks like the server completely severs the connection to the client when its cReceiver gets detached from the device. I don't think this is the right way to handle this. The client has requested a particular channel, and the server should do everything necessary to provide that channel. If it gets detached from a device, it should not sever the connection to the client, but rather try to reattach to a suitable device. Increasing any timeouts would only be a workaround. What if VDR starts a recording on the device that is currently used for streaming? It detaches all receivers (assuming the recorded channel is on a different transponder) and I'm pretty sure the client side would go dark (you might want to test this, could be interesting). IMHO this is a fundamental flaw in XVDR's handling of client/server connections and should be fixed there. Greetings Klaus

---

I replied to his question and tell about recording priority and a LiveView priority, which can be set in your addon options:

I think it would depends on priority - recordings has a priority and I also can set default priority for LiveTV watching in XVDR Maybe, but there sure are cases where the streamed live channel would go dark on the client side, even if there would be a device that can provide the live channel. Just assume you're streaming channel 1 from device 1, and a recording is started that wants to record channel 2 (which is on a different transponder than channel 1). For some reason (for instance only device 1 has a CAM for channel 2) channel 2 can only be received by device 1, while channel 1 can be received by both devices. When the recording starts, the stream is detached from device 1 and the client goes dark. If the XVDR server side would keep the client connection alive and try to reattach itself to device 2, it could continue streaming the live channel with only a very small interruption.

Klaus is asking you to correct him if his assumptions are wrong.

As it can be hard to you to know what is it really about: I am providing a sample log: http://skyboo.net/xvdr-channelchange.log. I added the following change to have more complete logs:

void cLiveStreamer::ChannelChange(const cChannel* channel) {
  cMutexLock lock(&m_FilterMutex);
  dsyslog("cLiveStreamer::ChannelChange %08X %08X %p", CreateChannelUID(channel), m_uid, m_Device);
  ...

If you look at it you can see that first two zaps just stopped when vdr detach receivers, instead it should wait longer (eg to be able to get a ChannelChanged notice). The third zap is done correctly (the VDR provided required data in 3 seconds time and the scrambled timeout doesn't occur).

All the above problems are only after fresh VDR start (when it doesn't yet collected CA descriptors for the channels).

[pipelka]

Really amazing. I've been thinking about something like that recently ;-)

Ok. I suggest 2 steps:

• Do not kill the client on detach. Just try to reattach to any available device. This should be pretty easy to achieve.
• Do not kill the streamer on channel switch. Just swich the channel and reuse the currently running streamer

I'll try to add step 1 to the "channelchange" branch. I think it will take a couple of days, ..

[pipelka]

I couldn't resist. Just commited the "attach" branch which should basically do what you want.

Beware - Quick and Dirty, ...

[manio]

hehe :) I'll give it a try asap

[manio]

Sorry - forget...

[pipelka]

Well, I think there is still some locking issue. It's working flawlessly on my development system (unencrypted channels) and on my production system with vdr 2.0.1.

Nevertheless i think there is a possible dead-lock in cLiveStreamer::ChannelChange()

Investigating, ...

[manio]

Sorry - my previous report was bad because I have wrongly patched vdr (I added a patch for informing when VDR is detaching receiver). This time it was applied ok. On your code I only added a debug and deleted information about 'scrambled packets'. Here is the log: http://skyboo.net/attach.log

At the end it crashed (if you want I can try to provide you a backtrace if i would be able to reproduce it). But generally it sometimes zaps without a problems.

[pipelka]

Sounds better :-) Please check if you got the latest HEAD of the branch. I did some commits in the meantime. Am 04.02.2014 20:19 schrieb "Mariusz Białończyk" <notifications@github.com

:

Sorry - my previous report was bad because I have wrongly patched vdr (I added a patch for informing when VDR is detaching receiver). This time it was applied ok. On your code I only added a debug and deleted information about 'scrambled packets'. Here is the log: http://skyboo.net/attach.log

At the end it crashed (if you want I can try to provide you a backtrace if i would be able to reproduce it). But generally it sometimes zaps without a problems.

— Reply to this email directly or view it on GitHubhttps://github.com/pipelka/vdr-plugin-xvdr/issues/117#issuecomment-34096084 .

[manio]

Thanks, I tested it four times. Three times I've got 100% cpu usage of 'section handler' thread and no picture, one time it worked ok (but the receiver was not detached by VDR in this case).

All logs in: http://skyboo.net/attach_dbg.tar.gz

[pipelka]

It seems i have to install 2.1.4 on my main server.

BTW, do i need some special oscam version for the latest dvbapi ?

[manio]

Use my master branch and OSCam rev >= 9095.

[manio]

I just have a reply from Klaus (I also ask about today 100% cpu usage):

The only thing I can imagine here is the handling of the m_PatFilter.
Maybe it isn't detached correctly or at the right time?
In cLiveStreamer::ChannelChange() there is an asymmetry:
  Detach();
  if(m_PatFilter != NULL) {
    m_Device->Detach(m_PatFilter);
  }
vs.
  Attach();
  if(m_PatFilter != NULL) {
    m_Device->AttachFilter(m_PatFilter);
  }
Maybe it should be
  if(m_PatFilter != NULL) {
    m_Device->Detach(m_PatFilter);
  }
  Detach();
  ...
  Attach();
  if(m_PatFilter != NULL) {
    m_Device->AttachFilter(m_PatFilter);
  }
This is just a wild guess, though.
What does cLiveStreamer need a PAT filter for, anyway?
Can you try without the line
  m_PatFilter = new cLivePatFilter(this, channel);
in cLiveStreamer::StreamChannel(), just to see if this is what's causing
the 100% load in the section handler?

[pipelka]

These snippets are from an older version (not the current "attach" branch). I do not see these problems on my development system (with vdr 2.1.4). But I do not have encrypted channels to test.

There is one reason for the PAT filter: The language type property of the audio stream isn't extracted by VDR (the language type is needed to order audio-streams properly for XBMC). Actually also historical reasons, ...

You could try to remove the PAT filter (if your XVDR channel cache is still warm) and see if that's the problem. But XVDR will be unable to react on stream changes.

[manio]

FTA channels will surely works without any problem. The thing here is the ChannelChange() and detaching receiver after 3 sec to change CAM.

I will try to remove this PAT filter to make sure that the 100% cpu will not occur.

[pipelka]

I will start testing with dvbapi in the evening, ... BTW, ChannelChange() messages are also happening on unencrypted channels (when stream information changes).

[manio]

Thank you :) And about my testing: I did this changes: http://pastebin.com/dwWM5s1s

I have to confirm it but from my quick tests it seems that it doesn't eat 100% cpu anymore :)

[pipelka]

That narrows down the code i have to look at. Thanks.

[manio]

You may also consider applying this patch to VDR: http://pastebin.com/hr8VcYJv you would be able to easier reproduce this (I decreased the timeout) and also be sure that the TS_SCRAMBLING_TIMEOUT ocured (info in the log)

[pipelka]

Please recheck with the updated branch. A quick test didn't show deadlocks anymore.

[manio]

Great Job, Alex! :) After intensive zapping I also did not notice any problems :)

Thank you very much :)

[pipelka]

Very good ;-) Could you please check if there's a problem with channels that can't be decrypted by the CAM ? piotrasd mentioned such a problem.

Thanks

[pipelka]

@piotrasd @manio

I found some weird bugs in the last commit (how could this ever work?). Please test this one: 742de090e82929e338b4de41608dda28b1081502

[manio]

Thanks, I'll try to test it later.

and about the PAT filter Klaus tell me: VDR does parse the language code of the audio tracks. They are accessible via cChannel::Alang().

He is asking why it needs to be ordered :) I assume it is some XBMC thing ...

[pipelka]

I know what's available in VDR, I wouldn't do this if it's not needed. I would love to rip off the PAT/PMT scanner.

It's the audio type that is needed:

if (ld->languageLoop.getNext(first, it)) {
  type = first.getAudioType();
}

It's used for sorting the audio stream in a unique way for XBMC.

[manio]

The audio type is available through cChannel::Atype(i).

[pipelka]

F**k. I checked the VDR PAT scanner and didn't find any code for parsing the audio type. Where does this value come from ?

[manio]

Check in sources or ask Klaus ;)

[pipelka]

Just verified. The Atype() returns the stream type (MP2, AAC, LATM, ...). I need the audio type, like "Visually Impaired Commentary", ...

[manio]

I see, I'll Klaus about it...

[manio]

Klaus: Ah, I see. Well, if you would like to get rid of that code in your plugin, you could provide a patch for VDR that implements this. If it isn't too invasive, I might adopt it.

[pipelka]

I feared that answer ;-) Maybe I can arrange some development time. Depends on my family ;-)

[manio]

Sure :)

[manio]

I tested the branch. For me it works ok, but I am wondering about one thing:

cLiveStreamer::ChannelChange 23047054 08292397 0x1526da0 name=KUCHNIA+ HD
cLiveStreamer::ChannelChange 0F568775 08292397 0x1526da0 name=CANAL+ FILM2 HD
cLiveStreamer::ChannelChange 4D0A1178 08292397 0x1526da0 name=teleTOON+ HD
cLiveStreamer::ChannelChange 6F910E90 08292397 0x1526da0 name=ALE KINO+ HD
cLiveStreamer::ChannelChange 540340C2 08292397 0x1526da0 name=PLANETE+ HD
cLiveStreamer::ChannelChange 08292397 08292397 0x1526da0 name=KUCHNIA+ HD
XVDR: ChannelChange()
cLiveStreamer::ChannelChange - MATCHES, DOING A SWITCH!

As you can see there was two ChannelChange for the same channel (KUCHNIA+ HD), but in first case the CreateChannelUID(channel) return a different value and it doesn't do a switch (It could be a second earlier). Is that an intentional?

[pipelka]

These channels have the same name but different channel id's. The second channelchange matches the current channel.

[piotrasd]

@pipelka with satelite you use and provider ?