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)
Change History (6)
by , 12 years ago
Attachment: | example.log added |
---|
comment:1 by , 12 years ago
Owner: | set to |
---|
comment:3 by , 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 , 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 , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
try latest version. there were a few fixes for request mode.
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?