Opened 12 years ago

Closed 12 years ago

#2615 closed defect (fixed)

dvbapi request_mode=1 hickups

Reported by: spock Owned by: theparasol
Priority: minor Component: DVBApi
Severity: medium Keywords:
Cc: Sensitive: no

Description

Revision

#7131 and earlier

Issue Description

Some providers are not decoding properly with request_mode=1. request_mode=0 does not have these problems.

For example with Canal Digitaal NL and request_mode=1 the first ECM after zapping is retrieved properly, after this all requests are rejected for a minute or so, and then decoding continues normally. sid also ends up in "bad sids", even with loadbalancer disabled.

With request_mode=0, the above does not happen.

In the attached log you can see with request_mode=1 oscam tries to request 0100:00006C which doesn't exist on the reader. In request_mode=0 oscam does not do this and decoding continues properly (but zapping can be painfully slow).

request_mode=1 will however work fine if I block 0100:00006C in oscam.dvbapi (as it does not exist on proxy). I don't know if this is the intended solution, it certainly doesn't feel like it.

Perhaps this is not a bug but just my own ignorance about how oscam/dvbapi works. If so I apologize.

When the issue occurs

Whenever zapping to affected providers, seems to be a lot worse with simulcrypt channels with many PID's.

How the issue is reproducable

Zap to affected channels.

Attachments (1)

example.log (6.0 KB ) - added by spock 12 years ago.

Download all attachments as: .zip

Change History (6)

by spock, 12 years ago

Attachment: example.log added

comment:1 by mike28, 12 years ago

Owner: set to theparasol

comment:2 by spock, 12 years ago

If I were to make a guess, I'd say 0100:00006C get rejected because it doesn't exist on the proxy. It then ends up in "bad sids". After this 0100:00006A will also remain blocked for the duration of the block on 0100:00006C (60 seconds?). Does this make any sense?

Last edited 12 years ago by spock (previous) (diff)

comment:3 by theparasol, 12 years ago

Check again with 7171 or better (http://www.streamboard.tv:8001/changeset/7171#)

Cannot reproduce this, no share readers available which is needed to trigger this behaviour.

comment:4 by spock, 12 years ago

No luck with #7183.

Now it's even worse though, after the first rejected message, decoding stops indefinately (can't decode channel), only way to recover is waiting the 60+ seconds again, and then zap to another channel, and then back. Or restart oscam.

Still working fine with "I: 0100:00006C" in oscam.dvbapi.

comment:5 by Deas, 12 years ago

Resolution: fixed
Status: newclosed

try latest version. there were a few fixes for request mode.

Note: See TracTickets for help on using tickets.