Hi @catalinii ,
Can you explain why these errors:
> [16/11 05:21:59.5131434]: get_active_key: returning key 0 for pid 162, d/c errs 423/0, adapter pid errs 75343
> [16/11 05:21:59.5131434]: get_active_key: returning key 0 for pid 92, d/c errs 31/0, adapter pid errs 75343
> [16/11 05:21:59.5131434]: get_active_key: returning key 0 for pid 93, d/c errs 25/0, adapter pid errs 75343
> ...
> [16/11 05:23:45.5236485]: get_active_key: returning key 0 for pid 162, d/c errs 423/0, adapter pid errs 75343
> [16/11 05:23:45.5236485]: get_active_key: returning key 0 for pid 92, d/c errs 31/0, adapter pid errs 75343
> [16/11 05:23:45.5236485]: get_active_key: returning key 0 for pid 93, d/c errs 25/0, adapter pid errs 75343
I dont know why they appear.
#194: Adapter pid errs
Hi,
if you dont have c errors (whcih are counter continuity errors) everything is fine.
decrypt errors is how many packets have not been decrypted (most likely between tune and the first CW).
Adapter errors are the number of packets for which there is no filter, it happens mostly in the satipc case...
Anyway those are not getting to the satip clients.
if you dont have c errors (whcih are counter continuity errors) everything is fine.
decrypt errors is how many packets have not been decrypted (most likely between tune and the first CW).
Adapter errors are the number of packets for which there is no filter, it happens mostly in the satipc case...
Anyway those are not getting to the satip clients.
Hi @catalinii ,
Thank you for fast respond. My concern is related to adapter pid errs. Using one HTTP client when the image freezes or have some error, then these messages appear. If you say that this counter is related to pids not found in any filter, then I feel the tuner is receiving garbage. Its correct?
Thank you for fast respond. My concern is related to adapter pid errs. Using one HTTP client when the image freezes or have some error, then these messages appear. If you say that this counter is related to pids not found in any filter, then I feel the tuner is receiving garbage. Its correct?
Hi,
With LOG 5 I cant show now the problem... Im not sure if its related to the speed of the Oscam server... However, I fount another trouble related to blocking read/writes:
* I start the minisatip with -l -l -l -l -l in a SSH remote session (using screen) with PuTTY from my Windows computer.
* Then I start a SAT>IP client in the Windows machine (TransEdit) and I play an encrypted channel. All works right.
* After I close the SAT>IP client and I start VLC using HTTP client mode to play the same channel. All works right.
* Then I move the PuTTY window (click left mouse button) and I dont stoping to move the window... this blocks the output log of the minisatip, and as consecuence the video frezees after 2 seconds (aprox.). The annoying behaviour is that the stream only blocks when using an HTTP client, with the RTSP client the image dont freeze (only time to time).
Please, can you revise the functions for logging and HTTP streaming and try to make them non-blocking?
With LOG 5 I cant show now the problem... Im not sure if its related to the speed of the Oscam server... However, I fount another trouble related to blocking read/writes:
* I start the minisatip with -l -l -l -l -l in a SSH remote session (using screen) with PuTTY from my Windows computer.
* Then I start a SAT>IP client in the Windows machine (TransEdit) and I play an encrypted channel. All works right.
* After I close the SAT>IP client and I start VLC using HTTP client mode to play the same channel. All works right.
* Then I move the PuTTY window (click left mouse button) and I dont stoping to move the window... this blocks the output log of the minisatip, and as consecuence the video frezees after 2 seconds (aprox.). The annoying behaviour is that the stream only blocks when using an HTTP client, with the RTSP client the image dont freeze (only time to time).
Please, can you revise the functions for logging and HTTP streaming and try to make them non-blocking?