OScam "pid not found" Error: Causes & Fixes

If you're diving into the world of OScam and found yourself staring at the dreaded "pid not found" error, you're not alone. I’ve been there. This message usually pops up when OScam encounters a channel change but can’t map an ECM PID to a known CAID or provider for that service. It’s frustrating, especially when your channel remains scrambled and you can't decrypt the stream. In this guide, I'll share what I've learned about troubleshooting this issue, specifically focusing on OScam: pid not found решение.

What "pid not found" Actually Means in OScam

The "pid not found" message is emitted by the DVB demuxer layer, known as dvbapi, when OScam recognizes a channel change but fails to find an associated ECM PID. To understand this, we need to clarify the different types of identifiers involved: the transport stream PID, the ECM PID (which is carried in the CAT/PMT), and the CAID.

The exact log line and where it appears

You might see a log entry like this:

[dvbapi] pid not found

This message typically appears in your oscam.log file when the ECM request is sent, but OScam can’t find the necessary PID to decode the channel.

PID vs ECM PID vs CAID: what OScam is looking for

Think of the transport stream PID as the address for a specific channel, while the ECM PID is what OScam needs to unlock that channel. The CAID represents the provider. So, if OScam sees the channel but can’t find the right ECM PID, it usually means there's a problem with how dvbapi is filtering or parsing the PMT.

Why it is a demux/mapping issue, not always a card issue

This error often indicates that OScam has detected the channel, but the necessary ECM PID isn’t available for the configured CAIDs. It’s not necessarily a sign that your card is expired. Instead, it reflects a problem with the mapping or filtering configuration within dvbapi.

Diagnosing the Error From oscam.log and dvbapi

Diagnosing the issue involves diving into your log files and making some adjustments. Start by setting the right log levels in your `oscam.conf` file.

Raising the log level and enabling debug flags

To capture detailed information, adjust the `loglevel` to 2 or 3 and set `debug` to 1:

loglevel = 2debug = 1

Your log file path is typically found at `/etc/tuxbox/config/oscam/oscam.log` or `/var/tuxbox/config/oscam.log`. This will help you gather more information about the ECM requests.

Reading the PMT / CAT parse output

Next, check the output of the PMT and CAT to see which CAIDs and ECM PIDs are being broadcasted for the channel. This can guide you in understanding what your OScam setup is dealing with.

Confirming dvbapi is enabled and which mode is active

Ensure that the `[dvbapi]` section in your configuration has `enabled` set to 1. Also, check the `boxtype`, `au`, `pmt_mode`, and `request_mode`. Each of these settings can affect how OScam interacts with the DVB stream.

Using the OScam web interface status and log tabs

If you haven't already, access the OScam web interface, typically at http://your-server-ip:8888 or http://your-server-ip:16002. The Status page will show you if the ECM request is reaching a reader.

Fixing CAID, Provider and ECM PID Mapping

Now that you have a better understanding of the issue, it’s time to implement some fixes. Often, the problem stems from OScam trying to access a CAID that your reader isn't authorized for.

Matching channel CAID to the reader's caid/ident

To fix this, add the correct `caid` and `ident` lines to the reader configuration in `oscam.server`. For example:

[reader]label = myreaderprotocol = smartcarddevice = /dev/sci0caid = 1234,5678ident = 1234:000000,5678:000000

oscam.dvbapi priority, ignore and map entries

The `oscam.dvbapi` rules can enforce OScam to request the CAID that the card can decode. Use priority (P), ignore (I), and map (M) entries wisely. For example:

P: 1234M: 1234:000000I: 5678:000000

Handling multiple CAIDs on one transponder

If a transponder carries several CAIDs, you may need to be explicit about which ones you want OScam to request. Mapping can help in these cases.

pmt_mode and request_mode adjustments

Adjusting the `pmt_mode` can also make a difference, especially if your STB doesn’t push PMT updates properly. Try setting `pmt_mode` to 1 or 2, depending on your setup. Similarly, `request_mode` can be switched between 0 and 1 to see which retrieves the ECM PIDs correctly.

Reader, Protocol and Connection Checks

Even with the right mapping, the ECM request could fail if no reader is serving that CAID. Here’s what to check:

Local smartcard readers vs network (cccam/newcamd) readers

For local readers, verify the device path, like `/dev/sci0` or `/dev/ttyUSB0`. Make sure the `protocol` and `detect` settings are correct. For network readers, check that they are configured to use the correct protocol (e.g., cccam on port 12000, newcamd on 15000).

Confirming the reader is ONLINE, not CONNECTED-only

Sometimes, a reader shows as CONNECTED but isn't actually ONLINE. Ensure that the reader offers the necessary CAIDs by checking its log output.

Group and label matching between reader and client

Check that the group numbers link the reader and account correctly in `oscam.user`. Mismatched groups can lead to failed ECM requests, even when everything else seems fine.

Firewall and port checks for network protocols

Network configurations can also be a headache. Ensure that your firewall settings allow traffic on the necessary ports. Port forwarding might be required for network readers, especially if you’re behind NAT.

Verifying the Fix and Preventing Recurrence

Once you’ve implemented fixes, it’s crucial to verify that everything is working as expected. A successful decode will show up in the logs with an entry like:

found → ECM OK (decode time: xx ms)

Confirming a clean ECM OK response

Look for this log message to confirm that OScam is correctly processing the ECM request. If you still see "pid not found," it often points to authorization issues rather than configuration problems.

Watching ECM time and cache behaviour

Keep an eye on the ECM response times. You should expect them to be under 200 ms for a good performance. If they’re consistently higher, revisit your reader setup or consider your connection’s quality.

Config hygiene: backups and version notes

Before making any changes, always back up your `oscam.server`, `oscam.dvbapi`, and `oscam.conf` files. Take notes of your OScam version and any changes made, since options can differ across builds. After making adjustments, restart OScam cleanly to ensure it reads the PMT again.