Closed CReimer closed 9 years ago
Here's a set of logs (VDR+OSCAM). Now with loglevel on 3 https://gist.github.com/CReimer/762f03eb7c11e4a2b803
At the moment it looks like this overflow happens in a 30 minutes interval
I can see that the PMT data is very big (sending len=1366). This could be the problem, because the buffer in the OSCam is smaller. There could be various reasons - maybe the data parser is wrong. I have to analyze it. On what channels you have it? Is it working despite this error?
Checkout SkinDesigner, this revison (or newer) and your Problems are gone: --> http://projects.vdr-developer.org/git/vdr-plugin-skindesigner.git/commit/?id=f9f68cae8d64f5c60ffaa34118b66f5ebab28506
This has nothing to do with skindesigner as this plugin wasn't even loaded at that time.
@manio: I think it only happens while two channels are decrypted. It's happening with all encrypted channels I tried.
@CReimer 3PO was probably talking about issue https://github.com/manio/vdr-plugin-dvbapi/issues/77 which you've suffer...
and about this issue: besides this PMT error, are channels decrypted correctly or freezes?
Everything works as expected. No visible problems at all. Also softhddevice doesn't complain about broken frames or anything.
@CReimer Can I close this ticket now? Or you still have such problems?
No. I think, whatever it was, is gone.
Ok, thanks :)
It's back... My ORF cards somehow stopped working in Cryptoworks mode. So I switched it into Irdeto Mode.
It's exactly the same as before:
socket_fd=7 len=1213 wrote=1213
and
Unknown socket command received: 0xC6EBD78A
***** WARNING: PMT BUFFER OVERFLOW, PLEASE REPORT! ******
in the oscam log
This is not a Problem of the dvbapi plugin.
My ORF Card is working in ICE Mode as expected:
server01 ~ # log o |grep -i orf
2015/04/25 19:23:07 973D20 c (dvbapi) Demuxer 0 new program number: 132F (ORF eins HD) [pmt_list_management 3]
2015/04/25 19:23:08 973D20 c (ecm) vdr_dvbapi (0648&000000/0001/132F/44:E06946BCD5462D66158DF234E6E31D22): found (86 ms) by orf (L/1/4/4) - ORF eins HD
2015/04/25 19:23:15 973D20 c (reader) orf [irdeto] vdr_dvbapi emmtype=global, len=36, cnt=2: skipped (0 ms)
2015/04/25 19:23:15 973D20 c (ecm) vdr_dvbapi (0648&000000/0001/132F/44:A69EA65C0174875F536DD872BCE7B3BB): found (87 ms) by orf (L/1/4/4) - ORF eins HD
2015/04/25 19:23:20 973D20 c (reader) orf [irdeto] vdr_dvbapi emmtype=global, len=36, cnt=2: skipped (0 ms)
2015/04/25 19:23:24 973D20 c (reader) orf [irdeto] vdr_dvbapi emmtype=global, len=36, cnt=2: skipped (0 ms)
2015/04/25 19:23:25 973D20 c (ecm) vdr_dvbapi (0648&000000/0001/132F/44:C9BB3CEB4BA2121D69C25421295588E2): found (88 ms) by orf (L/1/4/4) - ORF eins HD
2015/04/25 19:23:29 973D20 c (reader) orf [irdeto] vdr_dvbapi emmtype=global, len=36, cnt=2: skipped (0 ms)
I think it may be some temporary problems: it was working for fine for several months and now it appears again in your case. The unknown socket command sometimes appear because of "auto-sensing" of old OSCam version. Please contact @MegaV0lt, he is currently successfully testing my patches, this could help in your case. Anyway - closing the issue as I am unable to catch this problem in such a rare reveals.
Am I right with this here, or should I report that to oscam directly? I do not have more logs, because I don't had vdr-dvbapi's loglevel on 3 while this happened.