BLFReader with incosistent data sizes

[max3-2]

Describe the bug

Two bugs seem to occur with reading data from a blf log file (CAN FD).

1. Using log = BLFReader(file), the returned data seems to skip error frames. I have used another software to analyze messages and identified n_error error messages. Analyzing log.object_count vs len(list(log)), I can see that log.object_count = len(list(log)) + n_error. This is odd since the documentation states that error frames are validly returned.

2. Some message seem to end prematurely. That is I do know the length from other software and my dbc-File but the lenth in the raw messages from BLFReader() is less, e.g.

messages = [(msg.arbitration_id, msg.timestamp, msg.data) for msg in log]

for msg in messages:
    arbitration_id, timestamp, data = msg
    try:
        ret = dbc_db.decode_message(arbitration_id, data)
    except KeyError:
        ...

where dbc_db is a cantools.Database(). This raises the exception during unpacking that the data is missing 8 bytes, which is indeed the case looking at the core message data. Any other software correctly identifies the data at the given arbitration ID to be 8 bytes longer, thus allowing the unpack: Error: unpack requires at least 256 bits to unpack (got 192) The bytearray looks a bit strange with some \x seemingly translated(?) bytearray(b'\x0c[\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x00\x00\x00\x00\x00SS\x00\xd8G')

To Reproduce

Im sorry but I cant share the file

Expected behavior

consistent messages in length and data content

Additional context

OS and version: Win10 Python version: 3.10.10 python-can version: 4.1.0